2026 年 1 月 26 日週、私たちは ラバ祭り を祝いました。これは、旧正月まで残りわずかであることを告げる中国暦の伝統的な祝日です。ラバ祭りは、中国の多くの人々にとって振り返りと準備にまつわる祝日であり、今年の出来事をまとめ上げ、未来に目を向けます。 2026 年 2 月 9 日週は、春の始まりであり、二十四節気最初の節季である 立春 です。中国の伝統では、春は成長が始まり、新しい節目がやってくる季節として捉えられることがよくあります。「一年の計は春にあり」ということわざもあり、春が自分の方向を定め、新たなスタートを切るときだという考え方を反映しています。 2026 年 1 月 26 日週のリリース 2026 年 2 月 2 日週私が注目したリリースをご紹介します。 Amazon Bedrock がサーバーサイドツールと拡張されたプロンプトキャッシュでエージェントワークフローのサポートを強化 – Amazon Bedrock に、開発者が AI エージェントを構築して運用する方法を改善する 2 つのアップデートが導入されました。 Responses API がサーバーサイドツールの使用をサポート するようになりました。このため、エージェントは AWS のセキュリティ境界内でウェブ検索、コード実行、データベース更新などのアクションを実行できます。 Bedrock には、プロンプトキャッシュのための 1 時間有効期限 (TTL) オプションも追加されました 。この延長は、長時間にわたるマルチターンエージェントワークフローのパフォーマンス向上とコスト削減に役立ちます。Amazon Bedrock では、OpenAI GPT OSS 20B および 120B モデルで サーバーサイドツールを利用でき、1 時間のプロンプトキャッシュ TTL は 一部の Anthropic Claude モデルに一般提供されています。 Amazon SageMaker Unified Studio が AWS PrivateLink を用いたプライベート VPC 接続を追加 – Amazon SageMaker Unified Studio が AWS PrivateLink のサポートを開始しました。このサポートにより、VPC と SageMaker Unified Studio 間のプライベート接続が提供されるため、カスタマーデータをパブリックインターネット経由でルーティングする必要はありません。VPC にオンボードされた SageMaker サービスエンドポイントを使用すると、データトラフィックが AWS ネットワーク内に留まり、IAM ポリシーによって制御されるため、より厳格なセキュリティとコンプライアンス要件をサポートできます。 Amazon S3 がデータ移動を必要としないオブジェクト暗号化の変更をサポート – Amazon S3 では、データを移動または再アップロードしなくても、既存の暗号化されたオブジェクトのサーバー側暗号化タイプを変更できるようになりました。 UpdateObjectEncryption API を使用することで、オブジェクトプロパティとライフサイクル適合性を維持しながら、SSE-S3 から SSE-KMS への切り替え、お客様管理の AWS Key Management Service (AWS KMS) キーのローテーション、または S3 バッチオペレーションによるバケット全体での暗号化の大規模な標準化を行うことができます。 Amazon Keyspaces が予測可能な高スループットワークロードのためのテーブルの事前ウォーミングを導入 – Amazon Keyspaces (Apache Cassandra 向け) がテーブルの事前ウォーミングをサポートするようになりました。これは、ウォームスループットのレベルを事前に設定して、テーブルが大量の読み取りおよび書き込みトラフィックを瞬時に処理できるようにするため、コールドスタートによる遅延が発生しません。事前ウォーミングは、製品のリリースやセールスイベントなど、トラフィックが急激に増加するときのスロットリングの軽減に役立ち、マルチリージョンテーブルを含めたオンデマンドキャパシティモードとプロビジョニングキャパシティーモードの両方で動作します。この機能は、一貫的な低レイテンシーパフォーマンスをサポートしながら、スループットの準備状態をより細かく制御できるようにします。 Amazon DynamoDB MRSC グローバルテーブルが AWS Fault Injection Service と統合 – Amazon DynamoDB マルチリージョン強整合性 (MRSC) グローバルテーブルが AWS Fault Injection Service に統合されました。この統合を利用することで、強力な整合性を備えたマルチリージョンワークロードのためにリージョン障害をシミュレートし、レプリケーション動作をテストして、アプリケーションのレジリエンシーを検証できます。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 AWS Verified Access を使用したマルチアカウント AWS 環境でのゼロトラストアクセスの構築 – この記事では、一元化された共有サービスアーキテクチャに AWS Verified Access を実装する方法を詳しく説明します。AWS IAM アイデンティティセンターおよび AWS Resource Access Manager (AWS RAM) と統合して、アプリケーション層にゼロトラストアクセスコントロールを適用し、マルチアカウント AWS 環境全体で運用オーバーヘッドを削減する方法を紹介します。 Amazon EventBridge がイベントのペイロードサイズを 1 MB に増加 – Amazon EventBridge が 最大 1 MB のイベントペイロードをサポートするようになりました。これは、以前の 256 KB 上限からの増加となります。この更新は、イベント駆動型アーキテクチャが、ペイロードを分割したり外部ストレージに依存したりすることなく、単一のイベント内でより充実したコンテキスト (複雑な JSON 構造、テレメトリデータ、機械学習出力、生成 AI 出力など) を確保できるようにします。 AWS MCP サーバーがデプロイエージェント SOP を追加 (プレビュー) – AWS がデプロイ SOP (Standard Operating Procedure) を導入しました。この SOP では、AI エージェントが Kiro、Cursor、Claude Code といった MCP 互換の統合開発環境 (IDE) やコマンドラインインターフェイス (CLI) での単一の自然言語プロンプトから AWS にウェブアプリケーションをデプロイできます。エージェントは、AWS Cloud Development Kit (AWS CDK) インフラストラクチャを生成し、AWS CloudFormation スタックをデプロイして、AWS ベストプラクティスに従った継続的インテグレーションと継続的デリバリー (CI/CD) ワークフローを設定します。プレビューでは、React、Vue.js、Angular、Next.js などのフレームワークがサポートされています。 AWS Network Firewall がウェブカテゴリフィルタリングによる生成 AI トラフィック可視性を追加 – AWS Network Firewall が、定義済みのウェブカテゴリを通じて生成 AI アプリケーショントラフィックの可視性を提供するようになりました。ファイアウォールルール内でこれらのカテゴリを直接使用することで、生成 AI ツールやその他ウェブサービスへのアクセスを制御できます。TLS インスペクションと組み合わせると、カテゴリベースのフィルタリングを完全な URL レベルで適用できます。 AWS Lambda が Kafka イベントソースマッピングのオブザーバビリティを強化 – AWS Lambda に、Kafka イベントソースマッピングのための強化されたオブザーバビリティが導入されました。これは、イベントポーリング設定、スケーリング動作、イベント処理状態を監視するための Amazon CloudWatch Logs とメトリクスを提供します。この更新により、Kafka ベースの Lambda ワークロードの可視性が向上し、チームが設定上の問題、許可エラー、および関数の失敗をより効率的に診断できるようになります。この機能は、Amazon Managed Streaming for Apache Kafka (Amazon MSK) イベントソースとセルフマネージド Apache Kafka イベントソースの両方をサポートします。 AWS CloudFormation 2025 年の振り返り – 1 年を振り返るこの記事では、2025 年に行われた CloudFormation 更新が紹介されており、早期検証、より安全なデプロイ、改善された開発者ワークフローに焦点を当てています。改善されたトラブルシューティング、ドリフト認識変更セット、スタックリファクタリング、StackSets 更新、および CloudFormation 言語サーバーや Infrastructure as Code (IaC) MCP サーバーを含めた新しい IDE と AI 支援ツールなどの機能強化が取り上げられています。 今後の AWS イベント カレンダーを確認して、近日開催予定のイベントにサインアップしましょう。 AWS Community Day Romania (2026 年 4 月 23～24 日) – このコミュニティ主導の AWS イベントでは、AWS ヒーロー、ソリューションアーキテクト、および業界エキスパートによる 10 を超えるプロフェッショナルセッションのために、開発者、アーキテクト、起業家、学生が一堂に会します。参加者は、エキスパートによるテクニカルトーク、世界的なカンファレンスで経験を積んだ講演者からのインサイト、参加者だけのネットワーキングブレイクでつながる機会を期待できます。これらはすべて、コラボレーションとコミュニティエンゲージメントをサポートするために設計されたハイクラスな会場で行われます。 このイベント外でもつながりを維持する方法をお探しの場合は、 AWS Builder Center に参加して、AWS コミュニティのビルダーとともに学び、構築し、つながりましょう。 2026 年 2 月 9 日週の Weekly Roundup もお楽しみに! – Betty 原文は こちら です。

はじめに こんにちは、リテールハブ開発部の杉森です。 近年、AIを活用した開発ツールが急速に普及しています。私たちのチームでも積極的にAIツールを導入し、要件定義でのユーザーストーリー作成、設計ドキュメントの生成、コードの自動補完、テストコードの生成など、各開発フェーズの作業効率化を図ってきました。 しかし、個々の作業は確かに早くなっているのに、プロダクト開発フロー全体を見ると期待したほどの生産性向上を実感できないという課題に直面しました。 本記事では、この課題に対するアプローチとして導入を検討しているAI-DLC（AI-Driven Development Lifecycle）について紹介します。 AI-DLCとは AI-DLCは、AWSが提唱するAIネイティブな開発方法論です。方法論のホワイトペーパーで理論的な枠組みが定義されており、これを実装するためのワークフローがaidlc-workflowsとしてGitHub上で公開されています。 AWSの公式ブログでは、現在のAI活用における2つのアンチパターンが指摘されています。 AI-Assisted: 人間が設計を主導し、AIはコード補完など狭い範囲の支援にとどまる。生産性向上は限定的で、AIの能力を十分に引き出せない AI-Managed: 複雑な問題をAIに丸投げし、自律的にすべてを解決することを期待する。出発点が曖昧なためAIが多くの仮定を立て、プロトタイプ以外ではほぼ機能しない AI-DLCは、これらのアンチパターンに対するアプローチとして設計されています。AIが作業計画の作成やタスク分解を主導し、人間がその内容を検証・承認し、AIが承認された計画に基づいて実行するというサイクルで、開発ライフサイクル全体を進めます。 AI駆動開発ライフサイクル（AWS公式ブログ） aidlc-workflows（GitHub） 従来の開発手法との違い AI-DLCは、既存の開発手法にAIを後付けするのではなく、AIを前提とした開発プロセスをゼロから設計しています。ホワイトペーパーでは、以下の設計思想が示されています。 AIが会話を主導する: 従来は人間がAIに指示を出していたが、AI-DLCではAIがタスク分解や提案を行い、人間は承認・判断に集中する Intent / Unit / Bolt: ビジネス目標（Intent）を作業単位（Unit）に分解し、数時間〜数日の短いサイクル（Bolt）で実装を回す。ScrumのSprintに近いが、サイクルが短い 各ステップで人間がチェックする: AIの出力を段階ごとに検証し、誤りを早期に検出する。ホワイトペーパーでは「損失関数のように機能する」と表現されている 設計技法を方法論に組み込む: ScrumやKanbanがチームに委ねていたDDD等の設計技法を、方法論の一部として標準化する aidlc-workflowsの設計原則 aidlc-workflowsは、上記の設計思想を実装するにあたり、以下の5つの設計原則に基づいています。 原則 説明 No Duplication 設定やルールを一箇所で管理し、重複を排除する Methodology First 特定のツールに縛られず、方法論そのものを軸にする Reproducible ルールを明文化し、使うAIモデルが変わっても結果がぶれないようにする Agnostic IDE・エージェント・モデルを問わず動作する Human in the Loop 重要な判断には必ず人間の承認を挟む 3フェーズ構成 AI-DLCは、以下の3つのフェーズで構成されています。 INCEPTION PHASE: WHATとWHYの決定 CONSTRUCTION PHASE: HOWの実装 OPERATIONS PHASE: デプロイと監視（aidlc-workflows上は未実装） INCEPTION PHASE 「何を作るか（WHAT）」「なぜ作るか（WHY）」を決定するフェーズです。方法論のホワイトペーパーでは「Mob Elaboration」というプラクティスとして定義されており、共有画面を使ってチーム全体でAIの質問と提案を検証します。AIがビジネス意図（Intent）を明確化する質問を投げかけ、ユーザーストーリー、非機能要件、リスク記述を生成し、凝集度の高い作業単位（Unit）へ分割します。 aidlc-workflowsでは、このフェーズが以下のステージに細分化されています。 ステージ 説明 Workspace Detection プロジェクトの状態を分析（新規/既存の判定） Reverse Engineering 既存コードベースの理解（Brownfieldの場合） Requirements Analysis 要件の収集と整理 User Stories ユーザーストーリーの作成 Workflow Planning 実行計画の策定 Application Design アプリケーション設計 Units Generation 作業単位への分割 CONSTRUCTION PHASE 「どう作るか（HOW）」を決定し、実際にコードを生成するフェーズです。方法論のホワイトペーパーでは、Domain Design（ビジネスロジックのドメインモデリング）→ Logical Design（非機能要件を含むアーキテクチャ設計）→ Code & Unit Tests（コードとテストの生成）→ Deployment Units（デプロイ可能な成果物の構築）という流れで進みます。「Mob Construction」でチームがリアルタイムで技術的決定とアーキテクチャの選択を行います。 aidlc-workflowsでは、このフェーズが以下のステージに細分化されています。 ステージ 説明 Functional Design 機能設計（ユニットごと） NFR Requirements/Design 非機能要件の設計 Infrastructure Design インフラ設計 Code Generation コード生成 Build and Test ビルドとテスト OPERATIONS PHASE デプロイと監視を担当するフェーズです。方法論としては定義されていますが、aidlc-workflowsには含まれておらず、将来的にワークフローが追加される予定です。 対応プラットフォーム 公式では以下のプラットフォームがサポートされています。 Kiro CLI Amazon Q Developer IDE plugin Kiro IDE（Coming Soon） 試してみる 導入の背景 私たちのチームの課題は、まさにAI-Assistedパターンに該当します。AIを個々の作業の効率化には活用できているものの、生産性向上は限定的にとどまっていました。 私たちのチームでは、Kiro CLIをすぐに使える環境ではなかったため、Claude Code向けにカスタマイズして使用しました。AI-DLCはツールに依存しない設計を謳っているため、ルールファイルを調整すれば他のAIツールでも問題なく適用できると考えています。 Claude Code向けのカスタマイズ 以下のようにClaude Code向けにカスタマイズしました。 1. カスタムコマンド（スキル）の作成 .claude/commands/aidlc.md にワークフロー定義を配置し、 /aidlc コマンドで起動できるようにしました。 .claude/ ├── commands/ │ ├── aidlc.md # メインワークフロー │ ├── aidlc-pr.md # PR作成用 │ └── aidlc-archive.md # アーカイブ用 └── aidlc-rule-details/ ├── common/ # 共通ルール ├── inception/ # INCEPTIONフェーズ ├── construction/ # CONSTRUCTIONフェーズ └── operations/ # OPERATIONSフェーズ 2. ルールファイルの分割 各ステージの詳細指示を .claude/aidlc-rule-details/ 以下に分割配置しています。これにより、AIが必要なタイミングで必要なルールのみを読み込み、コンテキストを効率的に使用できます。 クーポン機能を題材にした検証 AI-DLCの有効性を検証するため、小売向けアプリのクーポン機能開発を題材に検証を実施しました。 検証概要 対象システム: Flutter + Laravel + Vue.js + Goで構成されたマルチプラットフォームアプリ 題材: ポイント後付けクーポンと即時値引きクーポンの2種類 検証範囲: モバイルアプリ、管理画面、バックエンドAPI、バッチ処理 チーム構成: PdM1人+エンジニア2人 検証の進め方 「クーポン機能を追加したい」というビジネス意図（Intent）を起点に、AI-DLCのフェーズに沿って進めました。 INCEPTION PHASE（3人で実施）: AIが要件を深掘りする質問を投げかけ、ユーザーストーリーや非機能要件を生成。PdMとエンジニアがその内容を検証・修正し、作業単位（Unit）に分割 CONSTRUCTION PHASE（1人で実施）: Unitごとにドメイン設計、コード生成、テスト生成を実施。各ステージでAIの出力を確認し、承認・修正を繰り返した 今回は検証目的だったこともあり、各フェーズ半日ずつの計1日で実際に動くものまで作成できました。Inceptionフェーズの要件・設計をより作り込み、Constructionフェーズではガードレールの整備やAIが自律的に改善できる体制を組むことで、さらに短縮できる余地があると感じています。 実際の様子 AIからの深掘り質問（Inceptionフェーズ） Requirements Analysisでは、AIが要件の曖昧な部分を選択肢付きで質問してきます。以下はその一例です。 AI : クーポン利用状態の管理について確認させてください。ユーザーがクーポンを「利用」した後の状態管理はどうなりますか？ A) 1回利用したら即座に使用済みになる（再利用不可） B) 有効期限内であれば何度でも利用可能 C) クーポンごとに利用回数を設定可能（1回、3回、無制限など） AI : クーポンの種類と適用範囲について確認させてください。 A) 全ての種類が両方のクーポンタイプで使用可能 B) クーポンタイプごとに使用可能な種類が決まっている このように、AIが仕様の選択肢を提示し、人間が判断するというサイクルでRequirements Analysisが進みます。初回の質問10問、追加の深掘り質問6問を経て、要件定義ドキュメントが生成されました。 人間による設計修正（Inceptionフェーズ） Application Designでは、AIが設計の選択肢を提示し、人間が判断するケースがありました。 人間 : アクティブユーザーではないユーザーにもレコードが作成されてしまいませんか？ AI : 2つの選択肢があります。 A) クーポン公開時に全ユーザー分のuser_couponsレコードを作成 B) クーポン利用開始時にのみuser_couponsレコードを作成 人間 : B 生成されたユーザーストーリー（Inceptionフェーズ） User Storiesでは、管理者向け6件、会員ユーザー向け6件、システム向け1件の計13件が生成されました。以下はその一部です。 US-01: クーポン新規作成 As a 管理者 I want to 管理画面から新しいクーポンを作成したい So that 会員ユーザーに対してキャンペーンを提供できる Acceptance Criteria: クーポンタイプ（ポイント後付け/即時値引き）を選択できる クーポン名と説明文を入力できる 有効期限（開始日・終了日）を設定できる 対象店舗を選択できる 生成されたコード（Constructionフェーズ） Constructionフェーズでは、Unitごとにドメイン設計 → コード生成 → テスト生成が進みます。最終的に以下の規模のコードが生成されました。 Unit 対象 生成ファイル数 主な成果物 Backend Laravel 51ファイル Enum, Model, Migration, Service, Controller, Test Dashboard Vue.js 16ファイル Composable, Component, Schema, Page Mobile Flutter 38ファイル Entity, Repository, Provider, Widget, Page わかったこと / 今後の展望 良いと感じた点 実際にAI-DLCを触ってみて、以下の点が良いと感じました。 Human in the Loopの実現: AIが実行し、人間が監視するという関係性が明確。各ステージで人間の承認が必要なため、重要な意思決定は人間がコントロールできる コンテキストの保存と再開: aidlc-state.md でプロジェクトの状態を追跡しているため、セッションが途切れても前回の続きから再開できる ドキュメント化による追跡可能性: audit.md にすべてのやり取りが記録されるため、なぜその決定をしたのかを後から追跡できる 適応的なワークフロー: プロジェクトの複雑さに応じて、実行するステージが自動的に調整される 試した上で見つかった課題 Inception前の準備の必要性 今回「クーポン機能を追加したい」というリクエストからInceptionを開始しましたが、背景知識や「なぜこの機能が必要なのか」がアウトプットに反映されにくいことがわかりました。また、要件の解像度が低い状態でInceptionを始めると、議論が発散しやすくなります AI-DLCのInceptionに入る前に、ビジネス背景や目的を整理するステップが必要だと感じました。 仕様とAI実装のギャップ Inceptionフェーズで仕様を決め切った上でも、以下の2つの問題が発生しました。 仕様の記載漏れ: Inceptionフェーズで決めた仕様に漏れがあり、Constructionフェーズで初めて気づくケース。例えば、APIレスポンスのラッパー形式やお気に入り店舗のパラメータなど、実装段階で判明した考慮漏れがありました 仕様通りに実装されない: 仕様として記載されているにもかかわらず、AIが異なる実装をするケース。例えば、既存の認証方式と異なるパターンで実装したり、既存のアーキテクチャパターンに従わない実装が生成されることがありました 前者は要件定義やアプリケーション設計の精度を上げていく必要があります。今回検証だったので細部まで確認できていないところがありました。そのため、実業務に導入した場合はよりこの部分に時間を使うべきだと思いました。 後者はモデルの進化を待ちつつ、コンテキストの渡し方の工夫や、実装が仕様に準拠しているかを監査するサブエージェントの整備など、ガードレールを張っていくことが必要だと感じました。 コンテキスト管理の課題 AIツール固有の課題として、コンテキスト管理の難しさがあります。実装フェーズではコードの読み書きが多く発生するため、auto-compact（コンテキストの自動圧縮）が頻発しました。その結果、audit.mdへの書き込みが不安定になったり、要件定義ファイルへの指摘を繰り返してもアウトプットに反映されないことがありました。 対策として、コンテキストの使用量を抑えるためにルールファイルを分割して必要なタイミングでのみ読み込む方式にしたり、サブエージェントを活用して処理を分散させるなどの工夫が必要です。 レビュー負荷への対応 AIのアウトプット量が増えることで、人間のレビュー負荷が増大するという課題があります。この課題に対しては、以下のアプローチを検討しています。 レビューを軽減するプロセスの構築: 自動テストやLintの活用 AIの出力品質を上げる工夫: プロンプトの改善、ルールの整備 段階的なレビュー: 各ステージでの承認による分散 これらの最適解は、チームやプロダクトによって異なるため、継続的に改善していく必要があります。 最後に AI-DLCは、AIを活用した開発における「ボトルネックを特定し、解消していく」ためのフレームワークとして有望だと感じています。 今回見えてきた課題はAI-DLCのフレームワーク自体の問題ではなく、AIと人間が協働する上で必然的に発生する問題です。今後も継続的に活用しながら、チームに最適な形にカスタマイズしていきたいと考えています。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 今回からサムネイルがリニューアルされ、新メンバーの古屋さんも一緒に写って心機一転、今年も張り切って週刊AWSお届けしたいと思います。ちなみに新年を迎えてから、私はずっとkiroに向き合って時間を過ごすことが多く、最近個人的にアプリを世に公開しました。いろいろとAI駆動開発のコツが身についてきた感じがします。こんな感じで週末プログラマーが今後どんどん増えていくんだろうなと思っています。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年1月26日週の主要なアップデート 1/26(月) AWS Transfer Family が Amazon FSx for NetApp ONTAP をサポート開始 AWS Transfer Family で Amazon FSx for NetApp ONTAP のファイルシステムに SFTP / FTPS / FTP でアクセスできるようになりました。これまで NFS / SMB でのみアクセス可能だった FSx for ONTAP のデータに、外部パートナーや内部ユーザーが業界標準のファイル転送プロトコルでセキュアにアクセスできます。S3 Access Points 経由でのアクセス制御により、既存のファイルシステムワークフローを維持しながら、データセキュリティとコンプライアンス要件を満たせます。詳細は こちらのドキュメントをご参照ください。 Amazon WorkSpaces Core がマネージドインスタンスの月額料金を発表 Amazon WorkSpaces Core の管理インスタンスに月次固定料金プランが新登場しました。従来は時間単位課金のみでしたが、常時稼働するデスクトップ環境では月次プランの方がコスト削減できます。例えば毎日 8 時間以上利用する場合、月次プランが経済的です。一方で利用頻度が不定期な場合は時間単位課金がお得。同じ環境内で両方の課金方式を混在させることも可能になり、用途に応じた柔軟なコスト管理が実現できます。 Amazon Bedrock がプロンプトキャッシュで 1 時間の持続時間をサポート Amazon Bedrock で Anthropic Claude モデルのプロンプトキャッシュが 1 時間まで延長可能になりました。従来の 5 分から大幅に延長され、長時間の AI エージェントワークフローや複数回にわたる会話でコスト効率と性能が向上します。例えば、ユーザーが断続的にやり取りするチャットボットや、複雑な処理を段階的に実行する AI エージェントで特に効果的です。詳細は こちらのドキュメントをご参照ください。 1/27(火) Amazon Connect でケースに対する詳細なアクセス制御がサポートされました Amazon Connect Cases でタグベースのアクセス制御が利用できるようになりました。これまでは細かいアクセス権限設定が困難でしたが、ケーステンプレートにタグを設定し、セキュリティプロファイルで特定タグ付きケースへのアクセスユーザーを制限できます。例えば詐欺関連ケースに専用タグを付けて詐欺対応チームのみアクセス可能にするなど、データガバナンスが強化されます。詳細は こちらのドキュメントをご参照ください。 AWS Marketplace が FPGA 製品への AMI セルフサービスリスティング体験を拡張 AWS Marketplace で FPGA (Field Programmable Gate Array) を使った AMI 製品の出品がセルフサービスで可能になりました。従来は手動フォームでの申請が必要でしたが、新しい UI や API を使って直接出品できるようになり、市場投入までの時間を大幅に短縮できます。Amazon F2 インスタンスで動作する高性能な AI や機械学習向けハードウェアアクセラレーターなどの製品販売が効率化され、開発者や企業がより迅速にビジネスを展開できるようになります。詳細は こちらの Seller Guide をご参照ください。 Amazon WorkSpaces が高度なプリンターリダイレクション機能を発表 Amazon WorkSpaces Personal で高度なプリンター リダイレクション機能が利用開始となりました。Windows ユーザーが仮想デスクトップから両面印刷、用紙トレイ選択、ステープル機能などプリンターの全機能を活用できるようになります。従来は基本的な印刷しかできませんでしたが、専門文書やラベル印刷など業務で必要な高度な印刷機能が使えるため、オフィス環境と同等の印刷体験を実現します。詳細は こちらのドキュメントをご参照ください。 1/28(水) マルチリージョン強整合性を持つ Amazon DynamoDB グローバルテーブルが AWS Fault Injection Service によるアプリケーション復旧力テストをサポート Amazon DynamoDB global tables with multi-Region strong consistency が AWS Fault Injection Service (FIS) に対応しました。これにより、リージョン障害などの実際の障害シナリオを意図的に発生させて、アプリケーションがどう応答するかをテストできるようになりました。従来は実際の障害が起きるまでアプリの復旧力を検証できませんでしたが、今回のアップデートで事前にテストして監視や復旧プロセスを改善できます。詳細は こちらのドキュメントをご参照ください。 1/29(木) Amazon GameLift Servers がゼロインスタンスへの自動スケーリングに対応 Amazon GameLift Servers でインスタンス数を 0 まで自動スケールできるようになりました。従来は低アクティビティ時でもインスタンスを稼働し続ける必要がありコストがかかっていましたが、今回のアップデートでゲームセッション要求時のみ自動でスケールアップし、非アクティブ時は完全にスケールダウンできるようになります。ピーク・オフピーク時間が明確なゲームや季節性ゲーム、新規ローンチゲームで大幅なコスト削減が期待できます。詳細は こちらのドキュメントをご参照ください。 AWS が AWS MCP Server (プレビュー) でデプロイメントエージェント SOP を発表 AWS MCP Server で Deployment Agent SOPs がプレビュー開始されました。これにより、開発者は自然言語のプロンプトだけで Web アプリケーションを AWS にデプロイできるようになります。従来はプロトタイプから本番環境への移行に複雑な DevOps 作業が必要でしたが、今回のアップデートで React や Vue.js などのフレームワークで作成したアプリを、たった一つのプロンプトで本番デプロイまで自動化できます。AWS CDK や CI/CD パイプラインも自動生成されるため、開発効率が大幅に向上します。バージニア北部リージョンでプレビュー提供中です。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock が Responses API を使用したサーバーサイドカスタムツールをサポート開始 Amazon Bedrock の Responses API でサーバーサイドツールのサポートが開始されました。これまではクライアントサイドでのツール利用のみでしたが、今回の更新によりサーバーサイドでも直接ツールを呼び出せるようになります。これにより AI アプリケーションが Web 検索、コード実行、データベース更新などをリアルタイムで実行できるため、より高度な自動化処理が可能です。カスタム Lambda 関数や AWS 提供ツールを利用でき、バージニア北部、東京、ミラノなど 9 つのリージョンで利用開始されています。詳細は こちらのドキュメントをご参照ください。 1/30(金) Amazon RDS for Oracle が追加ストレージボリュームを使用したクロスリージョンレプリカをサポート開始 Amazon RDS for Oracle でクロスリージョンレプリカが追加ストレージボリュームに対応しました。これまでプライマリストレージのみでしたが、最大 3 つの追加ボリューム (各 64 TiB) を設定でき、合計 256 TiB まで拡張可能です。ダウンタイムなしでストレージ容量を調整でき、災害復旧用のレプリカでも同様の柔軟性を得られます。詳細は こちらのドキュメントをご参照ください。 新しい Partner Revenue Measurement により AWS サービス消費量の可視性を提供 AWS が Partner Revenue Measurement という新機能を発表しました。AWS パートナーが自社のソリューションがどの程度 AWS サービスの利用につながっているかを可視化できるようになります。これまでパートナーは自分たちの提供するソリューションの AWS 収益への影響を具体的に測定することが困難でしたが、AWS Marketplace の製品コードを使ったタグ付けにより定量的な測定が可能になりました。パートナーにとって自社製品の価値を数値で示せるメリットがあります。詳細は こちらのオンボーディングガイドをご参照ください。 Amazon SageMaker Unified Studio が AWS PrivateLink をサポート開始 Amazon SageMaker Unified Studio が AWS PrivateLink に対応しました。これまではデータ通信がパブリックインターネットを経由していましたが、今回のアップデートにより VPC 内での完全なプライベート接続が可能になります。企業のセキュリティ要件が厳しい環境や、機密データを扱う ML プロジェクトにおいて、データ転送の安全性を大幅に向上させることができます。東京リージョンを含む 15 のリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。