本ブログは三菱電機ビルソリューションズ株式会社様と Amazon Web Services Japan 合同会社が共同で執筆しました。 多数のシステム群のクラウド移行を検討されている三菱電機ビルソリューションズ様の実際の課題と、生成 AI を活用した解決策を共有することで、同様の課題に直面している企業の皆様にとって参考となれば幸いです。 三菱電機ビルソリューションズが直面したDB移行の課題 企業のデジタルトランスフォーメーションが加速する中、三菱電機ビルソリューションズでもクラウド化に向けた活動を推進しています。その取組みの一つとして、オンプレミスの Oracle Database からクラウドネイティブな Amazon Aurora PostgreSQL への移行を検討しています。 データベース移行には、スキーマ変換、データ移行、アプリケーションコードの修正など、多岐にわたる作業が必要になります。 このうち、スキーマ変換については、 AWS Database Migration Service Schema Conversion (AWS DMS SC) や AWS Schema Conversion Tool (AWS SCT) が強力な支援ツールとして機能します。これらのサービスはテーブル定義、インデックス、ビューなどの多くのデータベースオブジェクトを自動的に PostgreSQL の形式に変換でき、移行プロジェクトの効率化に大きく貢献しています。 しかし、 すべてのデータベースオブジェクトが自動変換できるわけではありません。 特に、複雑なビジネスロジックを含む PL/SQL で書かれたストアドプロシージャやファンクション、パッケージなどは、Oracle Database 固有の機能や構文を多用しているため、AWS SCT でも完全な自動変換が困難なケースが存在します。 三菱電機ビルソリューションズにおける今回の取組みでは、AWS SCT で自動変換できないオブジェクトの変換だけで約200人月の工数が必要と見積もられており、移行プロジェクトのボトルネックとなっていました。 そこで三菱電機ビルソリューションズと AWS 生成 AI イノベーションセンター は共同で、Amazon Bedrockを活用した生成 AI エージェントによるコード変換ソリューションの検証を実施しました。 検証の過程で複数のソリューションを開発しましたが、その中で本ブログでは汎用性の高い Amazon Bedrock と Strands Agents を活用した生成 AI エージェントによる変換ソリューション をご紹介します。このソリューションにより、PL/SQL オブジェクトの自動変換を実現し、移行プロジェクトを大幅に効率化できました。 Strands Agents + 専用ツール群による包括的アプローチ 今回私たちが開発したソリューションでは、Strands Agents に実際のデータベース操作や変換作業に必要な具体的なツール群を提供することで、生成 AI によるデータベースオブジェクトの変換を可能にしています。また、コード変換だけでなく、基本的なテストケースの自動生成と結果比較の機能も組み込むことで、変換品質の向上を図っています。 従来の「コード生成のみ」のアプローチと異なり、このソリューションはテスト用のデータベース環境での基本的な動作確認まで自動化しています。これにより、単なる構文変換レベルを超えた「基本動作確認済みの変換」を実現し、移行後の品質リスクを軽減しています（ただし、これらの自動テストは網羅的ではなく、本番環境への適用前には人間の専門家による追加検証が必要です）。 次に、具体的なエージェントの仕組みを説明します。 提供ツール群の詳細 AI エージェントには主に下記の３種類のツール（MCP サーバー）を与えています。エージェントはプロンプトで指示された作業フローと、実際の作業状況を踏まえて、いつどのツールを利用するか柔軟に判断します。 1. データベース接続・操作ツール Oracle Database 接続ツール : 対象オブジェクトの DDL 取得、依存関係確認、テスト実行 PostgreSQL 接続ツール : 変換後 DDL の投入、構文チェック、テスト実行 2. ファイル操作ツール ファイル読み書きツール : DDL、テストコード、実行結果の保存・読み込み 3. システム実行ツール シェルスクリプト実行ツール : 複雑なデータベース操作やバッチ処理の実行 こちらは Strands Agents によるエージェント実装のサンプルコードです。ファイル操作ツールは Strands Agents Tools ライブラリで提供されています。また、データベース接続・操作ツールとシステム実行ツールは自作の MCP サーバーを利用しています。 import json from mcp import StdioServerParameters from mcp.client.stdio import stdio_client from strands import Agent from strands.tools.mcp import MCPClient from strands_tools import file_read, file_write from utils.callbacks import AgentCallbackHandler from prompts.prompts import get_system_prompt def load_mcp_config(): """MCP設定ファイルを読み込み""" with open("mcp.json", "r") as f: return json.load(f) def create_mcp_client(): """MCP クライアントを作成""" config = load_mcp_config() server_config = config["mcpServers"]["sql-converter"] return MCPClient( lambda: stdio_client( StdioServerParameters( command=server_config["command"], args=server_config["args"], env=server_config.get("env", {}), ) ) ) def create_agent(mode="db_object"): """エージェントとMCPクライアントを初期化""" system_prompt = get_system_prompt(mode) mcp_client = create_mcp_client() with mcp_client: mcp_tools = mcp_client.list_tools_sync() all_tools = [file_read, file_write] + mcp_tools agent = Agent( system_prompt=system_prompt, tools=all_tools, callback_handler=AgentCallbackHandler() ) return mcp_client, agent こちらは Oracle Database に接続するツールを提供する MCP サーバーのサンプルコードです。 FastMCP で MCP サーバーを作成し、@mcp.tool() で定義した run_ora_sql 関数を Strands Agents から呼び出せるツールとして公開しています。 内部では python-oracledb ドライバを使って Oracle Database に接続し、SQL クエリを実行、結果を取得しています。 from mcp.server.fastmcp import FastMCP import oracledb mcp = FastMCP("sql-converter") @mcp.tool() def run_ora_sql(sql): """ Execute SQL query on Oracle database. Args: sql (str): SQL query to execute on the Oracle database. Returns: list: Query execution results from the Oracle database. """ return oracle_execute(sql) def oracle_execute(sql): """ Execute SQL query on Oracle database. Args: sql (str): SQL query to execute on the Oracle database. Returns: list: Query execution results from the Oracle database. """ logger.info(f"Executing: {sql}") response = execute_query(sql) logger.info("Query completed") return response def execute_query(sql): """ Execute SQL query on Oracle database. Args: sql (str): SQL query to execute Returns: list: Query execution results Raises: Exception: If query execution fails """ credentials = get_db_credentials() connection = None cursor = None try: connection = oracledb.connect( user=credentials["user"], password=credentials["password"], dsn=credentials["dsn"], ) cursor = connection.cursor() cursor.execute(sql) (以下省略) 変換・検証の流れ これらのツールを用いて、エージェントは以下の包括的な処理を自動実行できます。 Phase 1: Oracle Database 環境での分析・テスト Oracle Database に接続し、対象オブジェクトのDDLを取得 依存関係（パッケージ、関数、型など）を確認 Oracle Database でのテストデータ作成とテストコード生成 Oracle Database 環境でテスト実行し、結果を記録 Phase 2: PostgreSQL 変換・検証 PostgreSQL に依存関係が定義されているか確認 Oracle Database のDDLを PostgreSQL に変換 PostgreSQL 環境で構文チェックとオブジェクト作成 Phase 3: 品質確保・結果比較 PostgreSQL 環境でのテストデータ・コード生成 同一テストケースでの PostgreSQL 実行 Oracle Database 実行結果との詳細比較・検証 差異分析と最終的な成功/失敗判定 技術的工夫ポイント 1. AWS DMS SC による変換結果利用 生成AIは強力なツールですが、すべてのタスクを任せる必要はありません。PostgreSQL にテーブルが定義されていない場合でも類推してテーブルを作成することも可能ですが、 AWS DMS SC により Oracle Database から PostgreSQL にテーブルを事前に変換・定義しておくと、より効率よくオブジェクトの変換を進めることができます。 2.マルチエージェントでの責務分割 シンプルなデータベースオブジェクトであれば1つのエージェントですべての手順を正しく実行できますが、より複雑で長いコードになると単一エージェントでは処理能力の限界が見られました。具体的には、一部の実装を簡略化したり、無意味なテストを作成してしまうなどの問題が見られました。 この問題を解決するため、以下の3つのエージェントによる分業体制を検討しました。 Oracle 検証エージェント ：Oracle Database でのテスト作成と実行を担当 PostgreSQL 変換エージェント ：Oracle DDL から PostgreSQL への変換とシンタックスチェックを担当 PostgreSQL 検証エージェント ：変換後の PostgreSQL コードに対するテスト作成・実行とテスト結果の比較を担当 この分業アプローチにより、各エージェントが専門領域に集中できるようになり、変換の精度と効率を改善することができました。 3.段階的な変換 移行対象のオブジェクトの中にはコード行数が数千行にも及ぶ巨大なプロシージャやパッケージも含まれました。 このようなオブジェクトについては、全体をまとめて変換するのではなく、機能的なまとまり（内部プロシージャ・関数など）ごとに変換することで、変換の精度を改善することができました。 別のアプローチ プロジェクト初期段階では、生成 AI にコード変換やテスト生成を担わせつつ、全体のワークフローは決定的に定義するアプローチも検討しました。固定ワークフローは、特定のデータベース環境や移行パターンに最適化すれば、処理速度や動作の確実性の面でエージェントより優れた結果が得られる可能性があります。 一方で、依存関係の処理、コード変換、テスト生成・実行、エラー発生時のリトライといった複雑なフローを正確に作り込むには多くの開発工数がかかります。また、プログラムが複雑化するとメンテナンス性の課題も生じます。 検討の結果、三菱電機ビルソリューションズのプロジェクトでは多様なデータベースオブジェクトへの対応力と将来的な拡張性を重視し、エージェント型アーキテクチャを活用していく方針となりました。 生成AIによる変換結果 私たちが開発した生成 AI による変換ソリューションにより、 AWS SCT による自動変換が不可だったオブジェクトのうち約90％を AI エージェントにより自動変換 できました。また、簡易的にではありますが、Oracle Database と PostgreSQL においてテストを実行し結果の合致を確認することで、一定の動作確認もできました。AI エージェントの利用により、データベースオブジェクトの変換が大幅に効率化できることを示しています。 ただし、生成 AI を活用したコード変換に際しては、ハルシネーションのリスクに留意した上で、従来の手動変換と同様、 十分なテスト期間を設けた網羅的なテスト実施が重要 です。全てのプロシージャや SQL 等が生成 AI で変換できる訳ではないことを念頭に、生成 AI で変換された SQL で正しい結果が得られるか、性能面で要件を満たせるか別途確認する必要があります。 今回の検証結果を受けて、三菱電機ビルソリューションズでは今後の移行プロジェクトにおいても、AIエージェントの活用を検討しています。 なお、今回ご紹介したエージェントのサンプルコードは こちらのGitHubリポジトリ で公開しているので、ぜひ試してみてください。 著者について 岡本 正義 三菱電機ビルソリューションズ株式会社 木田 悠歩 アマゾンウェブサービスジャパン合同会社, Generative AI Innovation Center, Deep Learning Architect 呉 和仁 アマゾンウェブサービスジャパン合同会社, シニア自動車製造ソリューションアーキテクト

こんにちは！ AWS でソリューションアーキテクトをしている鈴木です。 本ブログは Kiroweeeeeeek ( X: #kiroweeeeeeek ) の第 8 日目です。昨日のブログはしょぼちむさんの「 イベントストーミングから要件・設計・タスクへ。Kiro を活用した仕様駆動開発 」という内容でした。 本記事では、Kiro において中核をなす「Spec ファイル」の負債にならないための扱い方をお伝えします。なお、Kiro の一般提供に関しての総合的な情報は「 Kiro が一般提供開始: IDE とターミナルでチームと共に開発 」をお読みください。 Spec ファイルの概要 本題に入る前に Spec ファイルの概要と Spec ファイルによって開発者が得られる恩恵について記述します。 Kiro の Spec ファイルは「仕様駆動開発」を構成する要素です。仕様駆動開発とは、仕様を起点として設計・実装を進める開発手法で、仕様と実装の同期を保ちながら開発を進めることができます。 Spec ファイルは以下の 3 つのファイルで構成されています。 requirements.md：EARS (Easy Approach to Requirements Syntax) 記法での要件 design.md：構造やデータフローなど実装方針 tasks.md：要件と設計を基に Kiro が生成する実装タスク群 Kiro は Spec モードでの対話の中で、初めに requirements.md で要件を定義し、そこから design.md で実装方針や設計を作成し、最後に tasks.md で実装のためのタスクを作成していきます。そうして出来た tasks.md 内のタスクに沿ってコードを生成・更新していくことで実際に実装がされていく流れです。 このような形式を取ることで Kiro は仕様と実装の間で同期を保つことができます。これにより「仕様書の更新漏れ」や「仕様書と実装のイメージの乖離」といった問題を起こすことなく継続的に開発が可能です。 しかしながら正しく Spec ファイルを扱わないと上記のメリットを十分に享受することができず、むしろ負債になる可能性があります。今回は「Spec ファイルの切り方」「Spec ファイルの更新方法」「Spec ファイルの共有方法」の 3 つの視点から、負債にならないための工夫をお伝えします。 Spec ファイルの切り方 機能ごとに分離する Kiro を使う中で負債になりがちな行為として、「プロジェクト全体を一つの大きな Spec ファイルで管理しようとする」というものが挙げられます。EC サイトの例を元に考えてみましょう。EC サイトは確かに一つのアプリケーションですが、その中では複数の機能、用途が組み合わさって構成されています。これらをすべて「EC サイト」という一つの Spec ファイルにまとめてしまうと、 記載されている内容が多くなり、可読性が落ちる。 チームで開発する上でコンフリクトが生じやすくなり、開発のストレスが増大する。 特定機能を更新したいだけなのに、Spec ファイル全体に影響が波及してしまう。 などの問題が生じてしまい、結果として Spec ファイルが機能しなくなり、Spec ファイルの内容と実装の間で同期が保たれなくなる危険性があります。そのため Kiro では巨大な一つの Spec ファイルを作成するのではなく、複数の Spec ファイルを機能ごとに作成することを推奨しています。 例えば EC サイトの場合、以下のように機能ごとに Spec ファイルを切ることが出来ます。 .kiro/specs/ ├── user-authentication/ # ログイン, サインアップ, パスワードの変更 ├── product-catalog/ # 商品のリスティング, 検索, フィルタリング ├── shopping-cart/ # カートに追加, 数量の更新, 会計 ├── payment-processing/ # Payment gateway の統合, 注文の確認 └── admin-dashboard/ # 商品の管理, 顧客分析 切り方の粒度や観点には正解はないので、ご自身のアプリケーション要件やチームの状況、アーキテクチャ設計に応じて柔軟に決定いただくのが良いかと思います。 切り方については Kiro と Vibe モードを利用して、壁打ちをしながら進めていくことも可能です。初めに Kiro と会話をしながら要件を固めて「この固まった要件で機能ごとに Spec ファイルを分けてくれますか？」と聞いてみると添付の画像のように案を出してくれます。 Spec ファイルの更新 Spec ファイルは一度作って終わりではなく、定期的なメンテナンスが前提になっています。要件が追加されたり、設計方針が変わった場合は、Spec ファイルを更新することで Kiro が生成するタスクやコードにも変更を反映しましょう。注意点として、要件の変更があった場合に Spec ファイルに変更を適応しないで Vibe モードや手動でコードの変更を行うことは避けるべきです。Kiro のメリットである「仕様と実装の間で同期」が崩れてしまうためです。 requirements.md から変更を適応する 要件の追加・削除・修正があった場合は、以下のフローでコードの変更を行います。 要件の更新 ：requirements.md ファイルを直接修正するか、Spec モードを開始して Kiro に新しい要件や設計要素を追加するよう指示します。 設計の更新 : 仕様の design.md ファイルに移動し、「Refine」を選択します。この操作により、設計ドキュメントと関連するタスクリストの両方が、修正された要件を反映して更新されます タスクの更新 : tasks.mdファイルに移動し、「Update tasks」を選択します。これにより、新しい要件に対応する新しいタスクが作成されます。 タスクの実装 : 3 のプロセスで追加、修正されたタスクを実行することでコードに変更を適応する。 このように更新を行なっていくことで、「要件 → 設計 → タスク → 実装」の一貫性が保たれ、要件変更による「設計だけ古くなる」「タスクだけ古い」といったズレが発生しにくくなります。 Vibe から Spec に適応する 要件が変更された際には requirements.md から変更を適応するべきだということをお話ししましたが、実際に実装をしてみてから仕様を決定したいというニーズもあるかと思います。例えば、「UI の色味や挙動をみてから変更したい」などのボトムアップな実装を行いたい場合などです。 また、LLM との雑談ベースでの会話やブレインストーミングで整理した機能案から仕様を作成したいといったニーズもあるかと思います。そのような場合は、Vibe モードで実装してから Spec ファイルへの自動生成・適応することができます。 Kiro の Vibe モードをまずは立ち上げ、その中で会話や実装を行います。その後、Kiroに「ここまでの変更を Spec に変換して」というと、これまでのVibe モードのコンテキストから Spec ファイルを構築することが可能となります。特に実装の初期フェーズでは、言語化が固まりきっていない段階の「思考の断片」を Spec に落とし込める点が非常に便利です。 Spec ファイルの共有 Spec ファイル はバージョン管理を行なう Spec ファイルはバージョン管理することが推奨されています。バージョン管理することで、実装と実装意図をまとめて管理することが可能となります。 また、バージョン管理することでチーム間での無駄なコミュニケーションを減らすことも可能となります。例えばフロントエンドチームがバックエンドチームの実装意図を知りたい場合、従来であれば開発者に聞くか仕様書を探索する必要がありました。バージョンを管理すれば、Kiro に実装の意図を聞くだけで Spec ファイルを参照して答えてくれます。 また、コードに対するレビューと同じように、Spec に対してもレビューを行うことで、 要件の解釈がチーム内でズレない 設計方針の合意形成が早い 誤った前提でコードが実装されるリスクを軽減できる といったメリットを受けることが出来ます。さらに、Spec ファイルがバージョン管理されていれば、その機能の背景や意図を理解しながらレビューでき、「なぜこの実装なのか？」という議論がスムーズになります。 アプリケーションを跨ぐ仕様は共有する 複数のアプリケーションを並行して開発している場合、認証部分の仕様などを共通化させたいニーズがあるかと思います。 そういった場合に、それぞれのアプリケーションごとに個別の Spec ファイルを作ってしまうと、本来共通であるべき仕様がアプリ間で徐々にズレていくという問題が発生します。 片方のアプリだけ認証フローを更新し、もう片方が古い仕様のまま残ってしまったり、エッジケースの扱いがアプリによって微妙に異なってしまったりと、どれが正しい仕様なのかが分からない状態になりやすいのです。 そこで重要なのが、共通仕様は 1 つの Spec ファイルとして切り出して共有するというアプローチです。 認証認可、決済、プロフィール設定など、複数アプリで跨って利用する部分は 専用の Spec リポジトリにまとめておくことで、 仕様の更新が 1 箇所で完結する アプリ間の仕様のズレを防げる チーム間の前提が揃い、開発スピードが落ちない といったメリットが得られます。Git Submodule などを用いることで複数プロジェクトから参照可能です。 添付画像は Git Submodule を用いて共通の Spec ファイルとアプリケーション固有の Spec ファイルを管理する例です。共通の Spec ファイルは /shared の下にアプリケーション固有の Spec ファイルは /local の下に配置することで実現しています。 共通仕様は 1 箇所で定義し、複数アプリがそれを参照するという構造を作ることで、仕様の一貫性を保ちつつ、長期的に負債化しづらい開発体制を維持できます。 まとめ 本記事では、Kiro の Spec ファイルを負債にしないための 3 つのポイントを解説しました。 ３つのポイントを振り返ると、以下のようになります。 Spec ファイルの切り方：プロジェクト全体を一つの巨大な Spec ファイルで管理せず、機能ごとに分けることで可読性とメンテナンス性を向上させる。 Spec ファイルの更新：要件変更時は requirements.md → design.md → tasks.md → 実装の順での更新、もしくは Vibeモードから都度 Spec ファイルへの変換を行うことで、仕様と実装の同期を保つ。 Spec ファイルの共有：バージョン管理によりチーム内で Spec ファイルを共有することで実装と実装意図をまとめて管理できる。また、複数アプリ間の共通仕様は専用リポジトリで一元管理することでアプリ間の仕様のズレを防ぐことができる。 これらを実践していくことで Spec 機能の効果を最大限発揮することができ、Kiro がチーム開発における強力ツールとして力を発揮していくことができるかと思います。皆さんは Spec ファイルの扱いでどのような工夫をされていますでしょうか？是非、 X 上で #kiroweeeeeeek をつけて教えていただければと思います！ 鈴木 智貴 (Tomoki Suzuki) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 2025 年に新卒で入社した 1 年目の SA。大学時代に薬局向けのスタートアップで CTO を経験。好きなサービスは Kiro。好きなドラマは『SPEC ～警視庁公安部公安第五課 未詳事件特別対策係事件簿～』。 LinkedIn:  https://www.linkedin.com/in/tomoki-suzuki-7a8457277/ X:  https://x.com/tomozooooooonn?s=21

本記事は 2025 年 11 月 20 日に公開された Anthony Hayes による “ Your guide to AWS Advertising & Marketing Technology at re:Invent 2025 ” を翻訳したものです。 AdTech のイノベーター、広告代理店の経営者、MarTech の開発者、データサイエンティストの皆様、 Amazon Web Services (AWS) re:Invent 2025  は、クラウドを活用した広告・マーケティングテクノロジー (AMT) の変革力を探求する前例のない機会をもたらします。ラスベガスで開催される re:Invent 2025（12月1日～5日）にご参加いただき、顧客エンゲージメントの未来、データドリブン戦略、そして広告・マーケティングのイノベーションを解き放つ最先端の人工知能ソリューションについて Dive Deep し、知識・インスピレーション・ネットワーキングの世界をお楽しみください。 AI エージェントの最新イノベーションと、それが広告・マーケティングワークロードをどのように革新しているかをご覧ください。このブログ記事には、ネバダ州ラスベガスでの時間を最大限に活用するために、AWS 広告・マーケティングテクノロジーチームから直接提供されたヒントが満載です。最も重要なのは、広告・マーケティング業界の参加者に最も関連性が高いと考えられる、厳選されたブレイクアウトセッションとテクニカルセッションのリストをご確認ください。 はじめよう このブログ記事のリソースを厳選し、成功するアジェンダの計画をお手伝いします。また、広告・マーケティングテクノロジー向けのAWS re:Invent 参加者ガイド をダウンロードして、計画にお役立てください。AWS のソリューション、サービス、パートナーについて業界の専門家から直接学び、技術的な質問にその場で回答を得て、最新情報に即座にアクセスでき、そして何よりも、学びながら楽しむことができます。 AWS AMT ブログ と AWS re:Invent ウェブサイト をチェックして、re:Invent での広告・マーケティングテクノロジーに関する最新情報を入手してください。 参加登録 をして席を確保し、iOS または Android 用の AWS Events モバイルアプリ をチェックして、体験を計画し最大限に活用しましょう。 re:Invent が初めての方へ： re:Invent キーノートで、今年最も重要な AWS の発表について学ぶ準備をしましょう。 ブレイクアウトセッションは講義形式で 1時間です。これらのセッションは re:Invent キャンパス全体で開催され、あらゆるレベル（200～400）のあらゆる種類のトピックをカバーします。 チョークトークは、AWS の専門家との 60 分間のインタラクティブな少人数制のホワイトボードセッションです。実際のアーキテクチャの課題に関する技術的な議論が含まれます。 ライトニングトークは、100～300 レベルの重要なトピックをカバーする 20 分間のセッションです。 ワークショップは 2 時間のハンズオンセッションで、小グループで AWS サービスを使用して問題を解決します。 ビルダーズセッションは、少人数制のインタラクティブな 1時間のデモンストレーションです。各ビルダーズセッションは、参加者が構築する内容についての AWS 専門家による短い説明またはデモンストレーションから始まります。デモンストレーションが完了すると、参加者は自分のラップトップを使用して、ガイダンスを受けながら実験と構築を行います。 メインキーノート 最大のAWSローンチと業界インサイトを特集する、これらの必見の キーノート をお見逃しなく： 2025年12月2日（火） 8:00 AM – 10:30 AM: CEO Keynote with Matt Garman 2025年12月3日（水） 8:30 AM – 10:30 AM: The Future of Agentic AI is Here with Dr. Swami Sivasubramanian, VP of Agentic AI at AWS 3:00 PM – 4:30 PM: The Partnership Advantage with Dr. Ruba Borno, VP of Global Specialists and Partners at AWS 2025年12月4日（木） 9:00 AM – 10:30 AM: Infrastructure Innovations with Peter DeSantis, SVP of Utility Computing, and Dave Brown, VP of Compute and ML Services at AWS 3:30 PM – 4:30 PM: A Special Closing Keynote with Dr. Werner Vogels, CTO of Amazon.com デイリーセッションハイライト 2025年12月1日（月） 月曜日は、本番環境で AI エージェントを大規模に安全にデプロイ・運用するための強力な AI エージェントのセッションでスタートします。ハンズオンワークショップを体験し、エージェント駆動型プロセスが広告キャンペーンやライブ制作ワークフローをどのように変革できるかを学びましょう。 IND319: Building live video understanding solutions using agentic AI on AWS (workshop), Mandalay Bay | 8:00 AM – 10:00 AM IND357: Multi-agent collaboration for optimized advertising performance (chalk talk), Caesars Forum | 9:00 AM – 10:00 AM AIM395: Concept to campaign: Marketing agents on Amazon Bedrock AgentCore (breakout session), Mandalay Bay | 4:00 PM – 5:00 PM 2025年12月2日（火） 火曜日の充実したラインナップは、プライバシー強化 ML、AdTech 関連、実際の顧客事例を特集し、AI 駆動型広告イノベーションに Dive Deep します。 IND304: Transform video highlight production with agentic AI-human collaboration (chalk talk), Wynn | 10:00 AM – 11:00 PM IND309: Breaking down silos: multi-agent architecture for media operations (chalk talk), Wynn | 12:00 PM – 1:00 PM IND311: Build media workflows with natural language using agentic AI (builder’s session), MGM | 12:00 PM – 1:00 PM SPS302: Democratize data: Bundesliga real-time insights without writing any SQL (chalk talk), Caesars Forum | 1:00 PM – 2:00 PM IND3326: Formula 1 extends fandom with AI, data, and AWS Media Services (breakout session), MGM | 1:30 PM – 2:30 PM IND3334: AdTech at AI Speed: Building Dynamic Creative Agents in Five Days (lightning talk), Venetian Industries Pavilion | 3:00 PM – 3:20 PM IND360: Privacy-enhanced ML and GenAI for AdTechs with AWS Clean Rooms (chalk talk), Caesars Forum | 3:00 PM – 4:00 PM 2025年12月3日（水） 水曜日は、Amazon Ads が AI エージェントで広告作成を民主化する方法を紹介し、 AWS RTB Fabric  を使用したリアルタイム入札ワークロード、コマースメディアエージェント、クリエイティブ最適化に関するセッションを開催します。 IND3335: Amazon Ads Creative Agent uses AWS to democratize ad creation (breakout session), Wynn | 8:30 AM – 9:30 AM IND397: AI-powered content compliance: Media rating automation with Nova (chalk talk), Caesars Forum | 2:30 PM – 3:30 PM IND411: Build AI Commerce Media Agents: Audience Discovery & Campaign Performance (builder’s session), Mandalay Bay | 4:00 PM – 5:00 PM IND379: AWS RTB Fabric: Real-time bidding workloads with AdTech partners (breakout session), Mandalay Bay | 5:30 PM – 6:30 PM IND312: Build streaming analytics dashboards in minutes with Amazon Q developer (builder’s session), MGM | 5:30 PM – 6:30 PM 2025年12月4日（木） 木曜日は、1桁ミリ秒のレイテンシーでリアルタイム入札ワークロードとプライバシー強化分析を構築するためのハンズオンワークショップを開催します。最先端の AdTech ソリューションの実践的な経験をする良い機会です。 IND366: Build ultra-low latency ad workloads with unmatched cost-performance with AWS RTB Fabric (workshop), Mandalay Bay | 12:00 PM – 2:00 PM IND3309: Privacy-enhanced multi-party analytics with AWS Clean Rooms: Setup to insights (workshop), Mandalay Bay | 3:00 PM – 5:00 PM IND3327: AIOps revolution: How iHeart slashed incident response time by 60% with Bedrock AgentCore (breakout session), MGM | 3:30 PM – 5:30 PM 2025年12月5日（金） 金曜日は、Bloomberg が自然言語クエリとマルチモーダル入力を、 AI を使用してビデオコンテンツに変換する方法をご覧ください。 IND3331: AI at the speed of news: Bloomberg Media’s vision for the future (breakout session), Venetian | 8:30 AM – 9:30 AM デモと特別な展示 The Fragrance Lab – Venetian の Expo Hall で、AI 駆動型イノベーションを実証するユニークなアクティベーションを体験してください。The Fragrance Lab で、Amazon Bedrock の Amazon Nova によって生成されたカスタムフレグランスを開発し、AWS を使用した会話型インサイトを通じてパーソナライズされた広告キャンペーンを作成しましょう。 Sports Forum Live – Formula 1、NFL、NBA、PGA TOUR などのリーダーとのインタビューを特集する、完全に AWS 上でのライブブロードキャスト制作をお見逃しなく。月曜日午後 4時～6時、火曜日～木曜日午後 12時～4時、Caesars Forum（Industries Pavilion に隣接）で開催します。 Expo Hall と Industries Pavilion The Venetian の Expo Hall にある Industries Pavilion で、最新のAWSソリューション、サービス、パートナーを紹介するインタラクティブなデモを体験し、顧客がクラウドとAI 技術でどのように画期的な変革を達成しているかをご覧ください。 Monday, December 1: 4:00 PM – 7:00 PM (Welcome reception) Tuesday, December 2: 10:00 AM – 6:00 PM Wednesday, December 3: 10:00 AM – 6:00 PM (Happy Hour 4:30 PM – 6:00 PM) Thursday, December 4: 10:00 AM – 4:00 PM まとめ 皆様をラスベガスにお迎えし、広告・マーケティングのイノベーションを解き放つお手伝いができることを楽しみにしています。会場でお会いしましょう！ AWS 広告・マーケティング の詳細については、チームに お問い合わせ いただくか、広告・マーケティングテクノロジー向けの AWS re:Invent 参加者ガイド をダウンロードして、体験の計画にお役立てください。 Gaby Ferreres Gaby Ferreres は AWSの広告・マーケティング、メディア・エンターテインメント、ゲーム業界向けワールドワイドインダストリーズプロダクトマーケティングの責任者であり、顧客に代わってイノベーションを加速するためにテクノロジーリーダーと協力しています。彼女はグローバルマーケティングリーダーであり、顧客ジャーニーを向上させる体験のクリエイターです。AWS 入社前は、Microsoft と Telefonica でさまざまなポジションを務めていました。 Jonathan Harmms Jonathan Harmms は Amazon Web Services (AWS) の広告・マーケティング業界向けプロダクトマーケターです。 本稿の翻訳は、ソリューションアーキテクトの小川翔が担当しました。原文は こちら 。

本記事は、DynatraceおよびSoftwareOne PowerConnectとの共同執筆です。Dynatrace Extension Servicesディレクターの Krzysztof Ziemianowicz 氏、およびSoftwareOne PowerConnectのSAPソリューションアーキテクトである Stephen Bangs 氏の貢献とサポートに感謝いたします。 モダンなSAP環境では、ビジネスプロセスが単一システムの枠を超えて拡張されるにつれ、高度な監視機能が求められています。組織は現在、SAP Cloud ERP、SAP Business Technology Platform（BTP）、AWSサービス、および様々なクラウドソリューションを含む相互接続されたプラットフォームを管理しています。この複雑性には、システム監視に対する新しいアプローチが必要です。 単一システムのメトリクスとリアクティブなアラートのために設計された従来の監視ツールは、今日の統合されたビジネスプロセスの要求を満たすことができません。現代の運用では、最適なパフォーマンスを維持するために、接続されたすべてのシステムにわたる包括的な可視性が必要です。 SoftwareOne PowerConnect for SAP Solutionsは、SAPエコシステム全体にわたる広範なカバレッジを提供することで、これらの課題に対処します。そのオブザーバビリティフレームワークは、 OpenTelemetry 標準を通じて、システム固有の監視を実用的なインテリジェンスに変換し、プロアクティブなパフォーマンス管理とリアルタイムの運用インサイトを可能にします。 PowerConnectの深いSAP専門知識とDynatrace AIを活用したプラットフォームを組み合わせることで、組織は以下を獲得します： 包括的なシステム可視性 プロアクティブな問題検出 自動化された根本原因分析 強化されたビジネス成果 この統合されたアプローチは、エンドツーエンドのプロセス可視性を提供し、組織がSAPランドスケープ全体にわたって中断を防ぎ、運用を最適化するのを支援します。 Dynatrace上のPowerConnect for SAPでSAPの可視性を強化 PowerConnectは、SAP Cloud ERP、SAP BTP、およびSAP SaaSからオブザーバビリティシグナルを取得し、 Dynatrace Grailデータレイクハウス に記録します。これは、組織が AWSオブザーバビリティシグナル のすべてを、 統合分析モデル の下で維持できる場所です – まさにITランドスケープ全体を単一の連続体として見るのと同じです。DynatraceはAWS Agentic AI Marketplaceの一部であり、Dynatraceソリューションは現在、 Amazon Q、Amazon Bedrock、Amazon SageMaker などのAWS AIサービス内でネイティブに構成可能です。このパートナーシップにより、企業はより深いインサイトを引き出し、自信を持ってデジタルトランスフォーメーションを推進できます。 Dynatrace AIを活用したオブザーバビリティプラットフォームは、高度なAI/ML駆動のパターン検出と自動分析を通じて、テレメトリデータを実用的なインテリジェンスに変換します。事前構築されたDynatraceダッシュボードと分析機能は即座に価値を提供し、複雑なSAP環境の直感的な可視化を提供し、パフォーマンスの問題と最適化の機会を迅速に特定します。プラットフォームのエンドツーエンドのAI駆動コンテキストインテリジェンスにより、組織はテクノロジースタック全体にわたってトランザクションを追跡し、依存関係を理解できます。 以下の図は、PowerConnectとDynatraceがAWS上のSAP Cloud ERP Privateとどのように統合されるかを示しています： PowerConnect for SAP solutionsのインストール PowerConnect for SAP solutionsのインストールは、SAP Cloud ERP private内のすべてのSAPシステムでサポートされています（参照： サポート対象製品 ）。組織は以下のようにPowerConnect for SAP solutionsのインストールをリクエストできます： SAP Enterprise Cloud Services（ECS）にリクエストを提出して、PowerConnect ABAPをインストールします — これはSAPS/4HANAをカバーします — また、必要に応じて、SAP Process OrchestrationとSAP BusinessObjectsをカバーするPowerConnect Javaをインストールします。 SAP ECSにリクエストを提出して、SAPの管理アカウント内のプロキシサーバーからDynatraceテナントURLを許可リストに追加します。詳細については、 Dynatraceドキュメント を参照してください。 その後、組織は Dynatrace Hub から PowerConnect for SAP on Dynatrace アプリケーションをインストールできます。Dynatrace Hubは、ユーザーがDynatraceプラットフォームのアプリや拡張機能を含む機能を管理するためのアクセスポイントです。 SAPインスタンス上のPowerConnectセットアップからDynatraceテナントへのデータフローが開始されると、他のアプリケーションオブザーバビリティソースと同様に、Dynatraceダッシュボード、サービス監視、トランザクショントレーシング、およびビジネス分析機能を使用してSAPシグナルを可視化および分析できます。 設定後、組織は一般的なSAPオブザーバビリティのユースケースに対応する既製のダッシュボードを活用できます： バックグラウンドおよびバッチジョブ ABAPダンプとランタイムエラー セキュリティ監査ログとアプリケーションログの分析 ワークプロセス、ロック、および更新リクエスト トランザクショナルRFCおよびキューRFCトランザクション IDocステータス、IDocセグメント、およびアウトバウンド配送モニター 図：DynatraceにおけるSAPビジネスプロセス分析ダッシュボード PowerConnect for SAP on Dynatraceアプリケーション には、すぐに使える200以上の既製ダッシュボードが用意されており、組織は独自のダッシュボードを構築することもできます。 Distributed Tracingアプリは、PowerConnectによって複数のシステムにわたって収集されたSAPトレースを一元化して分析します。Business Flowアプリは、SAPプロセスの実行とビジネスイベントをマッピングして評価します。以下の画像は、ビジネスイベントの分析を示しています： すべてのSAP環境に対応する単一ソリューション 以下の図は、SAP BTP、SAP Integration Suite、SAP SuccessFactors、SAP Ariba、SAP Fieldglassを含むSAPクラウドソリューションの標準統合アーキテクチャを示しています： このアーキテクチャパターンは以下のように実装されます： 組織は、 PowerConnect Cloud スタンドアロンエージェントをホストするためにAWS上にAmazon EC2インスタンスをプロビジョニングします。 このエージェントは、単一のEC2インスタンスにインストールすることも、高可用性を提供するために2つのEC2インスタンスにインストールすることもできます。 PowerConnect CloudコンポーネントをホストするこのAmazon EC2インスタンスは、SAP APIに接続し、Dynatraceに転送されるシグナルを抽出します。 Amazon EC2上のPowerConnect Cloudのインストール手順は、 インストールドキュメント に記載されています。 PowerConnect Cloud専用のEC2インスタンスには、SAP BTPプラットフォーム、SAP SaaSアプリケーション、およびDynatraceテナントへの接続が必要です。 または、PowerConnect CloudインスタンスをCloud Foundryコマンドラインツールを使用してSAP BTP Cloud Foundry環境にインストールすることもできます。 Dynatraceは、SAP CPIメッセージ監視やSAP BTP syslogインサイトなど、ロール指向のダッシュボードで必要なデータを即座に提示できる単一のデータソースを提供します： 図：SAP CPIメッセージ監視とSAP BTP syslogインサイト まとめ AWS上のDynatraceとPowerConnectの統合は、従来の単一システムアプローチを超えた、この現代的なオブザーバビリティフレームワークを提供し、今日の相互接続されたSAPランドスケープに必要な包括的な可視性とAI駆動のインサイトを提供します。AWSのスケーラブルなインフラストラクチャ、AWS Agentic AI Marketplaceを通じたネイティブAIサービス統合、およびシームレスなマーケットプレイスデプロイメントオプションを活用することで、組織はこのソリューションを迅速に実装し、SAP監視機能を変革できます。AWS上のDynatraceとPowerConnectのこの組み合わせは、組織がビジネスクリティカルなプロセスへのリアルタイムインサイトを獲得し、ボトルネックを特定し、ワークフローを最適化し、SAPランドスケープ全体でユーザーエクスペリエンスを向上させることができるため、具体的なビジネス価値を提供します。 Dynatrace Platform および PowerConnect for SAP SolutionsはAWS Marketplaceで利用可能です。Dynatrace、Grail、およびDynatraceロゴは、Dynatrace, Inc.グループ企業の商標です。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

2025 年 11 月 19 日、Billing Transfer の一般提供についてお知らせします。これは、会社の関連会社や Amazon Web Services (AWS) パートナーなどの他の請求管理者に支払い責任を移管することで、複数の組織にわたって請求書を一元的に管理および支払うための新機能です。この特徴量により、複数の組織にまたがるお客様は、複数の組織にわたる環境全体のクラウドコストを包括的に把握できますが、組織管理者はアカウントに対するセキュリティ管理の自律性を維持できます。 お客様は AWS Organizations を使用すると、マルチアカウント環境の請求を一元的に管理できます。ただし、複数の組織環境で運用している場合、請求管理者は請求書を収集して支払いを行うには、各組織の管理アカウントに個別にアクセスする必要があります。請求管理へのこの分散型アプローチは、複数の AWS 組織にまたがる企業にとってコスト管理と請求書の支払いを無駄に複雑にします。この特徴量は、AWS パートナーが AWS の製品やソリューションを再販し、複数の顧客の消費分を AWS に支払う責任を引き受ける場合にも役立ちます。 Billing Transfer を使用すると、複数の組織環境で事業を行っているお客様は、1 つの管理アカウントを使用して、請求書の収集、支払い処理、詳細なコスト分析などの請求の側面を管理できるようになりました。これにより、請求業務がより効率的かつスケーラブルになり、個々の管理アカウントはアカウントに対する完全なセキュリティとガバナンスの自律性を維持できます。Billing Transfer は、 AWS Billing Conductor と統合することで独自の料金データを保護するのにも役立ちます。これにより、請求管理者はコストの可視性をコントロールできます。 Billing Transfer の使用を開始する Billing Transfer をセットアップするには、外部管理アカウントが請求元アカウントと呼ばれる管理アカウントに Billing Transfer の招待状を送信します。承認されると、外部アカウントが請求転送アカウントになり、招待状で指定された日付から、請求元アカウントの一括請求の管理と支払いを行います。 まず、 [Billing and Cost Management console] (請求とコスト管理コンソール) に移動し、左側のナビゲーションペインで [Preferences and Settings] (設定) を選択して、 [Billing transfer] (請求転送) を選択します。管理アカウントから [Send invitation] (招待を送信) を選択すると、複数の組織環境全体で請求を一元管理できます。 これで、請求を管理したい請求元アカウントの E メールアドレスまたはアカウント ID を入力して、Billing Transfer の招待状を送信できます。請求元アカウントに表示されるコストデータを管理するには、請求と支払いを開始する月次請求期間と、AWS Billing Conductor から料金プランを選択する必要があります。 [Send invitation] (招待を送信) を選択すると、請求元アカウントに [Outbound billing] (アウトバウンド請求) タブに請求転送通知が届きます。 [View details] (詳細を表示) を選択し、招待ページを確認して、 [Accept] (承認) を選択します。 転送が承認されると、請求元アカウントからのすべての使用量が、請求元アカウントでの請求と税金の設定を使用して請求転送先アカウントに請求され、請求書は請求元アカウントに送信されなくなります。どの当事者 (請求元アカウントと請求転送先アカウント) でも、いつでも転送を撤回できます。 請求転送が開始されると、請求転送先アカウントは月末に各請求転送の請求書を受け取ります。 請求元アカウントの使用状況を反映した転送済み請求書を表示するには、 [Bills] (請求) ページの [Invoices] (請求書) タブを選択します。 転送された請求書は、請求元アカウント ID で識別できます。請求元アカウントの請求書の支払いは、 [支払い] メニューでも確認できます。これらは請求転送先アカウントにのみ表示されます。 請求転送先アカウントは、請求ビューを使用して、 AWS Cost Explorer 、 AWS のコストと使用状況レポート 、 AWS Budgets と請求ページの請求元アカウントのコストデータにアクセスできます。請求ビューモードを有効にすると、請求元アカウントごとに希望する請求ビューを選択できます。 請求元アカウントには次の変更が適用されます: 過去のコストデータは利用できなくなるため、承認する前にダウンロードする必要 コストと使用状況レポートは転送後に再設定する必要があります 請求転送先アカウントに振り込まれる請求書には、常にお届け先のアカウントの税金と支払いの設定が使用されます。そのため、請求元アカウントとその AWS Organizations のメンバーアカウントの使用状況を反映したすべての請求書には、請求転送先アカウントで決定された税金設定に基づいて計算された税金 (該当する場合) が記載されます。 同様に、記録上の販売者と支払い設定も、請求転送先アカウントで決定された設定に基づいています。請求書設定機能で使用できる請求書単位を作成することで、税金と支払いの設定をカスタマイズできます。 詳細については、AWS ドキュメントの「 Billing Transfer 」をご覧ください。 今すぐご利用いただけます Billing Transfer は現在、すべての商用 AWS リージョンでご利用いただけます。詳細については、「 AWS クラウド財務管理サービスの製品ページ 」をご覧ください。 今すぐ Billing Transfer を試してみて、 AWS Billing に関する AWS re:Post にフィードバックを送るか、通常の AWS サポートの連絡先を通じてフィードバックを送ってください。 – Channy 原文は こちら です。

組織は、マイクロサービスを導入して段階的に革新し、ビジネス価値をより早く提供することで、Kubernetes のフットプリントをますます拡大しています。この成長によりネットワークへの依存度が高まり、プラットフォームチームが EKS のネットワークパフォーマンスとトラフィックパターンをモニタリングする上で、指数関数的に複雑な課題が生じています。その結果、組織はコンテナ環境が拡大するにつれて運用効率を維持するのに苦労し、多くの場合、アプリケーションの配信が遅れ、運用コストが増加します。 2025 年 11 月 19 日、 Amazon Elastic Kubernetes Service (Amazon EKS) の Container Network Observability について発表できることを嬉しく思います。Amazon EKS の包括的なネットワークオブザーバビリティ特徴量のセットを使用すると、システム内のネットワークパフォーマンスをより正確に測定し、EKS のネットワークトラフィックの状況と動作を動的に可視化できます。 Amazon EKS の Container Network Observability を簡単に見てみましょう。 EKS の Container Network Observability は、ワークロードトラフィックの可視性を高めることで、オブザーバビリティの課題に対処します。クラスター内のネットワークフローとクラスター外部の送信先を持つネットワークフローのパフォーマンスに関するインサイトを提供します。これにより、EKS クラスターネットワーク環境をより観察しやすくすると同時に、より正確なトラブルシューティングや調査作業のための組み込み機能が提供されます。 EKS の Container Network Observability の使用を開始する この新特徴量は、新規または既存の EKS クラスターで有効にできます。新しい EKS クラスターの場合、 [Configure observability] (オブザーバビリティを設定) のセットアップ中に、 [Configure network observability] (ネットワークオブザーバビリティを設定) セクションに移動します。ここでは、 [Edit container network observability] (コンテナネットワークオブザーバビリティを編集) を選択します。 サービスマップ 、 フローテーブル 、 パフォーマンスメトリクスエンドポイント の 3 つの特徴量が含まれていることがわかります。これらは Amazon CloudWatch Network Flow Monitor によって有効になっています。 次のページで、 AWS Network Flow Monitor Agent をインストールする必要があります。 有効になったら、EKS クラスターに移動して [Monitor cluster] (クラスターをモニタリング) を選択できます。 これで、クラスターのオブザーバビリティダッシュボードに移動します。次に、 [Network] (ネットワーク) タブを選択します。 包括的なオブザーバビリティ特徴量 EKS の Container Network Observability には、AWS サービスビュー、クラスタービュー、外部ビューの 3 つのビューを含む、パフォーマンスメトリクス、サービスマップ、フローテーブルなど、いくつかの主要特徴量があります。 パフォーマンスメトリクス を使用すると、ポッドとワーカーノードのネットワーク関連のシステムメトリクスを Network Flow Monitor エージェントから直接スクレイピングして、任意のモニタリング先に送信できるようになりました。使用可能なメトリクスには、入力/出力フロー数、パケット数、転送バイト数や、帯域幅、1 秒あたりのパケット数、接続追跡制限に関するさまざまな許容超過カウンタなどがあります。次のスクリーンショットは、 Amazon Managed Grafana を使用して Prometheus によりスクレイピングされたパフォーマンスメトリクスを可視化する方法の例を示しています。 サービスマップ 特徴量を使用すると、クラスター内のワークロード間の相互通信を動的に可視化できるため、アプリケーションのトポロジーを一目で簡単に理解できます。サービスマップは、再送信、再送信タイムアウト、通信ポッド間のネットワークフローで転送されたデータなどの主要なメトリクスを強調表示することで、パフォーマンスの問題をすばやく特定するのに役立ちます。 これがどのように機能するかをサンプルの e コマースアプリケーションでお見せしましょう。サービスマップには、マイクロサービスアーキテクチャの概要と詳細の両方が表示されます。この e コマースの例では、3 つのコアマイクロサービスが連携していることがわかります。 GraphQL サービス は API ゲートウェイとして機能し、フロントエンドサービスとバックエンドサービス間のリクエストを調整します。 顧客が製品を閲覧したり注文したりすると、GraphQL サービスは 製品サービス (カタログデータ、料金設定、在庫用) と 注文サービス (注文の処理と管理用) 両方との通信を調整します。このアーキテクチャにより、懸念事項を明確に分けながら、各サービスを個別にスケールできます。 より詳細なトラブルシューティングを行うには、ビューを拡張して個々のポッドインスタンスとその通信パターンを表示できます。詳細を見ると、マイクロサービス通信の複雑さがわかります。ここでは、各サービスの複数のポッドインスタンスと、それらの間の接続ネットワークを確認できます。 このようなきめ細かな可視性は、不均一な負荷分散、ポッド間の通信ボトルネック、または特定のポッドインスタンスでより高いレイテンシーが発生している場合などの問題を特定する上で重要です。例えば、ある GraphQL ポッドが特定の製品ポッドに対して不釣り合いに多くの呼び出しを行っている場合、このパターンをすばやく見つけて潜在的な原因を調査できます。 フローテーブル を使用して、クラスター内の Kubernetes ワークロードのトップトーカーを 3 つの異なる視点からモニタリングし、それぞれがネットワークトラフィックパターンに関する独自のインサイトをもたらします。 フローテーブル – クラスター内の Kubernetes ワークロードのトップトーカーを 3 つの異なる視点からモニタリングし、それぞれがネットワークトラフィックパターンに関する独自のインサイトをもたらします。 AWS サービスビュー には、 Amazon DynamoDB や Amazon Simple Storage Service (Amazon S3) などの Amazon Web Services (AWS) サービスへのトラフィックが最も多いワークロードが表示されるため、データアクセスパターンを最適化し、潜在的なコスト最適化の機会を特定できます。 クラスタービュー には、クラスター内で最も負荷の高いコミュニケーター (東西トラフィック) が表示されます。つまり、最適化やコロケーション戦略の恩恵を受ける可能性のある、やり取りが多いマイクロサービスを見つけることができます。 外部ビュー は、AWS 以外の送信先 (インターネットまたはオンプレミス) へのトラフィックが最も多いワークロードを識別します。これは、セキュリティのモニタリングと帯域幅管理に役立ちます。 フローテーブルには、ネットワークトラフィックパターンを分析するための詳細なメトリクスとフィルタリング機能が表示されます。この例では、e コマースサービス間のクラスタービュートラフィックを表示するフローテーブルを見ることができます。このテーブルは、 注文 ポッドが複数の 製品 ポッドと通信して、大量のデータを転送していることを示しています。このパターンは、注文処理中に注文サービスが頻繁に製品を検索していることを示しています。 フィルタリング機能はトラブルシューティングに役立ちます。例えば、特定の注文ポッドからのトラフィックに焦点を当てる場合などです。このきめ細かなフィルタリングにより、パフォーマンスの問題を調査する際に通信パターンをすばやく分離できます。例えば、顧客のチェックアウト時間が遅い場合は、注文サービスから製品サービスへの呼び出しが多すぎないか、特定のポッドインスタンス間にネットワークのボトルネックがないかをフィルタリングできます。 その他の情報 EKS の Container Network Observability に関するキーポイントは次のとおりです。 料金 – ネットワークモニタリングには、Amazon CloudWatch Network Flow Monitor の標準料金をお支払いいただきます。 可用性 – EKS の Container Network Observability は、Amazon CloudWatch Network Flow Monitor が利用できるすべての商用 AWS リージョンでご利用いただけます。 メトリクスを任意のモニタリングソリューションにエクスポート – メトリクスは、Prometheus や Grafana と互換性のある OpenMetrics 形式で利用できます。設定の詳細については、「 Network Flow Monitor のドキュメント 」をご覧ください。 Amazon EKS の Container Network Observability を今すぐ使用開始して、クラスターのネットワークオブザーバビリティを向上させましょう。 構築がうまくいきますように! –  Donnie 原文は こちら です。

2025 年 11 月 18 日、アプリケーションに必要なパフォーマンスレベルを維持しながら、AI ワークロードのコストをより細かく制御できる新しいサービスティアが Amazon Bedrock に導入されました。 私は、AI アプリケーションを構築しているお客様と仕事をしており、異なるワークロードには異なるパフォーマンスとコストトレードオフが必要になることを現場で直接見てきました。AI ワークロードを実行する組織の多くは、パフォーマンス要件とコスト最適化のバランスを取るという課題に直面します。アプリケーションには、リアルタイムでのやり取りのために高速な応答時間を必要とするものもあれば、データをより段階的に処理できるものもあります。これらの課題を念頭に、ワークロード要件とコスト最適化の一致における柔軟性を高める追加の料金オプションが本日発表されました。 Amazon Bedrock では、ワークロード向けに Priority、Standard、Flex の 3 つのサービスティアが提供されるようになりました。各ティアは、特定のワークロード要件に一致するように設計されています。アプリケーションには、ユースケースに基づくさまざまな応答時間要件があります。最速の応答時間が求められる金融取引システムなどのアプリケーションもあれば、コンテンツ生成といったビジネスプロセスをサポートするために高速な応答時間が必要になるアプリケーションや、データをより段階的に処理できるコンテンツ要約などのアプリケーションもあります。 Priority ティアは、他のティアよりも先にリクエストを処理するため、コンピューティングリソースがチャットベースの顧客対応アシスタントや、リアルタイムの言語翻訳サービスといったミッションクリティカルなアプリケーションに優先的に割り当てられますが、料金は他のティアより割高になります。 Standard ティアは、日常的な AI タスクのための一貫的なパフォーマンスを通常料金で提供し、コンテンツ生成、テキスト分析、定形化されたドキュメント処理に最適です。より長いレイテンシーに対応できるワークロードの場合は、低料金の Flex ティアがコスト効率に優れたオプションを提供します。このティアは、モデル評価、コンテンツ要約、マルチステップ分析ワークフロー、エージェンティックワークフローに最適です。 今後は、各ワークロードを最も適切なティアに一致させることで支出を最適化できるようになります。例えば、迅速な対応が必要なチャットベースのカスタマーサービスアシスタントを実行している場合は、Priority ティアを使用して最速の処理時間を達成できます。より長い処理時間に対応できるコンテンツ要約タスクの場合は、信頼性の高いパフォーマンスを維持しながらコストを削減するために Flex ティアを使用できます。Priority ティアをサポートするモデルでは、お客様がそのほとんどで Standard ティアよりも最大 25% 優れた OTPS (1 秒あたりの出力トークン数) レイテンシーを実現できます。 各サービスティアでサポートされるモデルの最新リストについては、Amazon Bedrock ドキュメント をご覧ください。 ワークロードに適したティアの選択 以下は、ワークロードに適したティアの選択に役立つメンタルモデルです。 カテゴリー 推奨されるサービスティア 説明 ミッションクリティカル Priority 他のティアよりも先にリクエストが処理されます。ユーザー向けアプリ (カスタマーサービスのチャットアシスタント、リアルタイムの言語翻訳、インタラクティブな AI アシスタントなど) のための低レイテンシー応答 ビジネス (標準) Standard 重要なワークロード (コンテンツ生成、テキスト分析、定型化されたドキュメント処理など) のための応答性に優れたパフォーマンス ビジネス (ノンクリティカル) Flex 緊急性の低いワークロード (モデル評価、コンテンツ要約、複数ステップのエージェンティックワークフローなど) のための優れたコスト効率性 アプリケーション所有者とともに現在の使用パターンを確認することから始めます。次に、即時応答が必要なワークロードと、データをより段階的に処理できるワークロードを特定します。その後、異なるティアを使用してトラフィックのごく一部のルーティングを開始し、パフォーマンス面とコスト面のメリットをテストできます。 AWS 料金見積りツール は、予想されるワークロードを各ティアに入力することで、異なるサービスティアのコスト見積もりに役立ちます。特定の使用パターンに基づいて予算を見積もることができます。 使用状況とコストを監視するには、 AWS Service Quotas コンソール を使用するか、 Amazon Bedrock でモデル呼び出しのログ記録を有効 にし、 Amazon CloudWatch を使用してメトリクスを観察できます。これらのツールはトークンの使用状況を可視化し、さまざまなティア全体でのパフォーマンスの追跡に役立ちます。 新しいサービスティアは、今すぐ使用を開始できます。API コールごとにティアを選択します。以下は ChatCompletions OpenAI API を使用した例ですが、 InvokeModel 、 InvokeModelWithResponseStream 、 Converse 、および ConverseStream API のボディで同じ service_tier パラメータを渡すことができます (サポートされるモデルの場合)。 from openai import OpenAI client = OpenAI( base_url="https://bedrock-runtime.us-west-2.amazonaws.com/openai/v1", api_key="$AWS_BEARER_TOKEN_BEDROCK" # Replace with actual API key ) completion = client.chat.completions.create( model= "openai.gpt-oss-20b-1:0", messages=[ { "role": "developer", "content": "You are a helpful assistant." }, { "role": "user", "content": "Hello!" } ] service_tier= "priority" # options: "priority | default | flex" ) print(completion.choices[0].message) 詳細については、「 Amazon Bedrock User Guide 」を参照するか、詳しい計画策定のサポートについて AWS アカウントチームまでお問い合わせください。 皆さんがこれらの新しい料金オプションを使用して AI ワークロードを最適化する方法を聞くのを楽しみにしています。皆さんの経験は、ソーシャルネットワークを通じてオンラインで共有、または AWS イベントで私と共有してください。 – seb 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS を皆様へお届けします！ いよいよ来週 12 月 1 日からは、 AWS re:Invent 2025 がラスベガスで開幕しますね！最新サービスの発表から技術セッションまで、AWSの最前線が一堂に会するこの一大イベントで、どんな革新的な新機能やエキサイティングなアナウンスが飛び出すのか、今から胸が高鳴ります。また、 「AWS Black Belt Online Seminar 2025 年 AWS re:Invent 速報 を今年も開催いたします。 現地参加・オンライン参加を問わず、最新のクラウド技術トレンドを一緒にキャッチアップしていきましょう！ そして年末に向けてアップデートがますます活発になる中、見逃せないのが AWS 認定試験の受験支援キャンペーン です。現在、受験料 25% 割引と同じ試験の再受験無料特典を提供するキャンペーンが実施されています。初回受験は2月15日 (PST)、再受験は3月31日 (PST) までが期限となっています。他特典との併用はできませんが、新年向けてスキルアップを目指すチャンスなので、ぜひこの機会をお見逃しなく！ それでは、先週の主なアップデートについて振り返っていきましょう！ 2025年11月17日週の主要なアップデート 11/17(月) AWS Marketplace で推定税額と請求エンティティ情報を表示開始 AWS Marketplace で購入時に推定税額情報と請求エンティティが表示されるようになりました。これまでは購入完了後に税額が確定していましたが、今回のアップデートにより取引完了前に総費用を把握でき、調達承認と予算編成の透明性が向上します。AWS 請求コンソールの設定に基づいて推定税額、税率、請求エンティティを確認でき、PDF でダウンロードも可能です。税の種類（付加価値税、商品サービス税、米国売上税など）や前払い料金の推定税額も表示されます。詳細は こちらの参考資料をご参照ください。 Amazon MWAA が Apache Airflow ワークフロー向けサーバーレスデプロイメントオプションを導入 Amazon MWAA で Apache Airflow のサーバーレスデプロイメントオプションが提供開始されました。従来は Apache Airflow 環境の管理運用が必要でしたが、今回のアップデートにより基盤となるインフラのプロビジョニングやスケーリングなどをサービス側が自動で行うため、運用負荷が大幅に削減されます。サーバーレスアーキテクチャと自動スケーリングにより、タスク実行時に使用された実際のコンピュート時間に対してのみ課金され、コスト最適化が実現できます。データエンジニアは YAML や Python DAG でワークフローを定義でき、Amazon Provider Package に含まれる 80 以上の AWS Operators を利用できます。東京リージョンを含む 15 の AWS リージョンで利用開始できます。詳細は こちらの Blog 記事をご参照ください。 Amazon EC2 で Microsoft SQL Server 高可用性デプロイメントのコストを削減 Amazon EC2 で SQL Server の High-Availability (HA) 構成時のライセンス費用を大幅に削減できるようになりました。従来はプライマリとセカンダリの両ノードで SQL Server ライセンス費用が発生していましたが、数クリックで新機能を有効化することで、セカンダリノードの SQL Server ライセンス費用が免除され、最大 40% のコスト削減が可能です。Always On 可用性グループや Always On フェイルオーバー クラスター インスタンスを使用する企業のミッションクリティカルなデータベースで特に効果的で、パフォーマンスを犠牲にすることなく運用コストを抑制できます。詳細は こちらの Blog 記事をご参照ください。 11/18(火) ウェブサイト配信とセキュリティの定額料金プランを発表 Amazon CloudFront を中心に、ウェブサイト配信とセキュリティをまとめてカバーする定額料金プランの提供が開始されました。従来は CDN や WAF をはじめ、DDoS 対策、DNS、ログ収集などのために利用する複数のサービスや機能の料金を個別に見積もる必要がありましたが、月額固定料金 (Free / Pro / Business / Premium の 4 プラン) で一括して利用できるようになります。バイラル化や DDoS 攻撃によるトラフィック急増時でも超過料金の心配がなく、予算管理が楽になります。詳細は こちらの Blog 記事をご参照ください。 Amazon Redshift が大文字小文字を区別しない照合順序を持つデータベースでの SUPER データ型のサポートを発表 Amazon Redshift が、大文字と小文字の違いを区別しない照合順序を持つデータベースでの SUPER データ型の利用を発表しました。これまで JSON や API データなど、大文字小文字の表記が統一されていない半構造化データの分析が困難でしたが、SUPER データ型と PartiQL を使用することで、構造化データと、大文字・小文字の表記が混在する JSON や API などの半構造化データを組み合わせた柔軟な分析が可能になります。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock が Priority と Flex 推論サービス Tier を導入 Amazon Bedrock に新しい Priority Tier と Flex Tier が追加されました。Flex Tier は、モデル評価やコンテンツ要約など多少の遅延を許容できる処理向けのコスト重視の Tier であり、Priority Tier はリアルタイム対話など高い応答性能が求められる用途に最適で、標準 Tier と比べて最大 25% のレイテンシー改善を提供します。既存の Standard Tier と合わせて 3 つの Tier から選択できるようになり、ワークロードに応じてコストと性能のバランスを最適化できます。詳細は こちらの Blog 記事をご参照ください。 11/19(水) 複数組織の請求とコスト管理のための Billing Transfer を開始 AWS Billing Transfer という新機能がリリースされました。これまで複数の AWS Organizations を運用している場合は、それぞれの組織で個別に請求管理を行う必要がありましたが、今回の機能により単一の管理アカウントから複数組織の請求を一元管理できるようになります。請求書の収集、支払い処理、詳細なコスト分析を集約して実行できるため、大規模な環境での運用効率が大幅に向上します。2026 年 5 月 31 日まで無料トライアルを提供しており、AWS GovCloud (US) と中国リージョンを除く全てのパブリックリージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 AWS Lambda がテナント対応アプリケーションの構築を簡素化する新しいテナント分離モードを発表 AWS Lambda で新しいテナント分離モードが利用可能になりました。これまで SaaS プラットフォームなどのマルチテナントアプリケーションを構築する際、テナントごとに専用の Lambda 関数を作成するなど複雑な独自ソリューションが必要でした。新機能では、Lambda 関数を呼び出す際にテナント ID を指定するだけで、各テナントの実行環境を完全に分離できます。これにより開発・運用の負担を大幅に軽減し、セキュリティ要件の厳しいマルチテナントアプリケーションを簡単に構築できるようになりました。詳細は こちらの Blog 記事をご参照ください。 開発者に AWS CLI と SDK 認証でのコンソール認証情報の使用を可能に AWS CLI や SDK での認証が大幅に簡単になりました。従来はプログラムからの AWS サービス利用時に別途アクセスキーを作成・管理する必要がありましたが、今回のアップデートで AWS コンソールのサインイン認証情報をそのまま利用できるようになりました。新しい aws login コマンドを実行するだけで、ブラウザ認証を経て一時的な認証情報が自動生成され、ローカル開発環境ですぐに AWS サービスを利用開始できます。認証情報は短期間で自動ローテーションされるため、セキュリティリスクも軽減されます。詳細は こちらの Blog 記事をご参照ください。 Savings Plans と Reserved Instances のグループ共有が一般提供開始 AWS で Savings Plans と Reserved Instances のグループ共有が一般提供開始されました。これにより、お客様は Cost Categories で定義した組織内のグループ単位でコミットメントの適用範囲を制御できるようになります。特定グループ内に割引を限定する「制限共有」と、まずグループ内に優先適用したうえで余剰分を組織全体に共有する「優先共有」を選択可能です。詳細は こちらの Blog 記事をご参照ください。 11/20(木) Amazon S3 が属性ベースアクセス制御をサポート Amazon S3 で属性ベースアクセス制御 (ABAC) がサポートされました。これまでバケットのタグはコスト配分にのみ使われていましたが、今回のアップデートでアクセス制御にも活用できます。組織の成長に伴う頻繁な IAM ポリシーやバケットポリシーの更新作業を大幅に削減し、大規模なアクセス管理を簡素化できます。タグを参照する IAM ポリシーを作成すれば、バケットにタグを追加するだけで自動的にアクセス権限が適用される仕組みです。詳細は こちらの Blog 記事をご参照ください。 Amazon CloudFront がオリジン接続で TLS 1.3 をサポート開始 Amazon CloudFront がオリジン接続で TLS 1.3 をサポート開始しました。これにより、従来の TLS バージョンと比べて、より強力な暗号化とハンドシェイクの高速化によってオリジンサーバーとの通信性能が最大 30% 向上します。設定変更は不要で、S3 や ALB などすべてのオリジンタイプで自動的に利用でき、従来バージョンとの後方互換性も維持されます。金融や医療、EC サイトなど機密データを扱うアプリケーションでより安全な通信が可能になり、追加料金なしで全エッジロケーションで提供されます。詳細は こちらのドキュメントをご参照ください。 Amazon EC2 での Microsoft SQL Server 2025 イメージの提供開始を発表 Amazon EC2 で Microsoft SQL Server 2025 の License-Included AMI が利用可能になりました。最新の SQL Server を手軽に起動でき、TLS 1.3 をデフォルトでサポートするため、従来よりもセキュリティとパフォーマンスが向上します。AWS Tools for Windows PowerShell や Systems Manager などが事前にインストール済みなので、サーバー構築の手間が大幅に削減されます。データベースサーバーを素早く立ち上げたい企業にとって便利なアップデートです。詳細は こちらの Blog 記事をご参照ください。 11/21(金) Amazon WorkSpaces Applications が Internet Protocol Version 6 (IPv6) をサポート開始 Amazon WorkSpaces Applications で Internet Protocol Version 6 (IPv6) のサポートが開始されました。これまで IPv4 のみでの接続でしたが、IPv6 対応デバイスからも直接 WorkSpaces Applications ドメインおよび外部エンドポイントへ接続できるようになります。IPv4 と IPv6 間のアドレス変換が不要になるため、高価なネットワーク機器のコストを削減でき、より大きなアドレス空間を活用できます。東京リージョンなど 16 のリージョンで追加料金なしで利用可能です。詳細は こちらのドキュメントをご参照ください。 分析と AI/ML 開発のための Amazon SageMaker Data Agent の紹介 Amazon SageMaker Data Agent が新登場しました。自然言語でやりたいことを説明するだけで、データ分析や機械学習に必要な SQL や Python コードを自動生成してくれる AI エージェントです。これまでデータエンジニアやアナリストが手作業で行っていたコード作成や実行計画の策定を大幅に効率化できます。SageMaker Unified Studio の新しいノートブック機能で利用でき、東京リージョンを含む 9 つのリージョンで提供開始されています。詳細は こちらの Blog 記事をご参照ください。 AWS Transit Gateway で柔軟なコスト配分を発表 AWS Transit Gateway で柔軟なコスト配分機能 (Flexible Cost Allocation) の一般提供が開始されました。従来は送信側のアカウントが全ての通信料金を負担する仕組みでしたが、新機能では送信側、受信側、または中央の Transit Gateway アカウントに料金を配分できるようになります。複数の部署や組織で Transit Gateway を共有している場合、実際のデータ利用に応じた課金や、部署ごとの予算管理が可能になります。追加料金なしで全ての商用リージョンで利用でき、コンソールや CLI から設定できます。詳細は こちらのドキュメントをご参照ください。 今週は「運用を軽くする、コストを見える化する、すぐ試せる」を後押しする発表が多く、現場での一歩目がさらに速くなる期待感がありますね。冒頭でお伝えした通り、来週はいよいよ年に一度の“最新クラウドテクノロジーが集まる場” である re:Invent です。素敵な re:Invent ウィークをお過ごしください！ それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail とAmazon Q Developer で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。いよいよ来週からはre:Inventですね。毎年この時期はさまざまなサービスアップデートが発表されるので楽しみにされている方も多いのではないでしょうか。 そして毎年おなじみAWS Japanから提供する re:invent 速報を今年も開催いたします。ぜひ こちらのページ より事前登録をお願いいたします。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、11 月 17 日週の生成 AI with AWS界隈のニュースを見ていきましょう。Kiro のGAに伴い Kiroweeeeeeek in Japan という集中ブログ連載も開催中ですので、これを機にぜひキャッチアップにお役立てください。 さまざまなニュース お客様事例 三遠ネオフェニックス様の AWS 生成 AI 事例「Amazon Bedrock と Step Functions を活用したバスケットボール・スカウティングレポート自動生成システムの構築」のご紹介 三遠ネオフェニックス様は、Bリーグに所属し、豊橋市をホームタウンに、三遠地域（東三河・遠州）をホームエリアに活動するプロバスケットボールクラブです。試合データの増加により人力での分析が困難になり、アナリストの経験に依存する属人化や過密スケジュールでのレポート作成が課題となっていました。これを解決するため、AWS Step Functions と Amazon Bedrock を組み合わせたサーバーレスアーキテクチャを構築しました。Synergy Sports Technology社の分析ツールからスタッツデータをAPI取得し、3つのステップ（分析切り口の抽出、深掘り分析、サマリ生成）で処理を行い、Slackにレポートを自動送信する仕組みを実現しました。その結果、客観的かつ網羅的な分析を自動生成でき、新たな戦術的インサイトの発見とアナリストの負担軽減を実現しています。 NTT西日本の AWS 事例：Amazon Bedrock Knowledge Bases を活用した営業支援 AI ボットの開発 NTT西日本様では、ビジネスチャットの「elgana」を提供しています。サービス開発を進める中で社内の膨大なドキュメントや知識を効果的に活用する必要がありました。この課題に対し、RAG（Retrieval-Augmented Generation）技術を活用した生成AIソリューションを実装しました。Amazon Bedrock Knowledge Basesを中心としたアーキテクチャにより、社内情報を基にした正確な回答生成を実現しています。その結果、業務効率の向上と知識の民主化を達成し、今後さらなる活用範囲の拡大を検討しています。 Python 初心者が生成AIとともに短期プログラミング開発に挑戦した結果 ANAシステムズ様は、航空業界向けのシステム開発を手がける企業です。開発プロセスにおいて、コード作成やレビューに多くの時間を要していました。この課題を解決するため、Pythonと生成AIを組み合わせた開発支援ツールを導入しました。Amazon Bedrockを活用したコード生成・レビュー支援により、開発者の生産性が大幅に向上しました。その結果、開発サイクルの短縮とコード品質の向上を実現し、今後は他の開発言語への展開も視野に入れています。 東京大学 松尾・岩澤研究室主催の AI エンジニアリング実践講座にて、1400 名を超える受講者に AWS 上でのクラウド開発を体験していただきました [ 準備、構築編 ] 東京大学で実施された大規模AIエンジニアリング実践講座の内容を紹介する連載記事の第1回です。1400名を超える受講者に対して、マルチアカウント環境でのデータ基盤構築を実践的に学んでもらう取り組みについて解説しています。記事では、大規模な教育環境の準備プロセス、AWS Organizations を使ったアカウント管理、受講者ごとの独立した環境構築の自動化など、大規模講座運営のノウハウを共有しています。 東京大学 松尾・岩澤研究室主催の AI エンジニアリング実践講座にて、1400 名を超える受講者に AWS 上でのクラウド開発を体験していただきました [ 演習、運用編 ] 東京大学AIエンジニアリング実践講座連載の第2回として、実際の演習内容と運用フェーズについて解説しています。受講者が取り組んだデータパイプライン構築、機械学習モデルのデプロイ、マルチアカウント環境でのガバナンス実践など、実務に即した課題を紹介しています。記事では、1400名規模の同時演習を支える監視体制、トラブルシューティングの仕組み、受講者サポートの工夫などについても触れています。また、受講者からのフィードバックや学習効果の測定方法も紹介されており、大規模技術教育プログラムの運営ノウハウが詰まった内容となっています。 東京大学 松尾・岩澤研究室主催の AI エンジニアリング実践講座にて、1400 名を超える受講者に AWS 上でのクラウド開発を体験していただきました [ 後片づけ編 ] 東京大学AIエンジニアリング実践講座連載の最終回として、講座終了後のリソース削除と振り返りについてまとめています。1400アカウント分のリソースを効率的かつ確実にクリーンアップする自動化の仕組みや、コスト管理のベストプラクティスを解説しています。記事では、削除漏れを防ぐためのチェック機構、予期せぬコスト発生への対策、アカウントのアーカイブ方法などを詳しく紹介しています。また、講座全体を通じて得られた知見、改善点、今後の展望についても触れられており、大規模クラウド教育プログラムのライフサイクル全体を理解できる内容になっています。 技術記事 質問への回答とアクションを実行するエージェント型チームメイト Amazon Quick Suite の発表 Amazon QuickSight からアップグレードされたAI エージェント機能を持つ「Amazon Quick Suite」について詳しく紹介しています。自然言語でのデータ分析、ダッシュボード作成、インサイト発見に加え、分析結果に基づいたアクションの実行まで可能になりました。記事では、ビジネスユーザーが技術的な知識なしにデータ分析を行える仕組みや、AIエージェントが自動的にデータパターンを発見して提案する機能を解説しています。また、Slackなどのコラボレーションツールとの統合により、チーム全体でのデータ駆動型意思決定を促進する方法も紹介されています。 Kiro が一般提供開始: IDE とターミナルでチームと共に開発 Kiroの一般提供開始を発表する記事です。プレビュー期間中のフィードバックを反映した改善点、新機能、エンタープライズ向けの機能強化について詳しく紹介しています。記事では、チーム開発での活用方法、組織全体でのKiro展開のベストプラクティス、セキュリティとコンプライアンス要件への対応などを解説しています。また、正式リリースに伴う料金体系、サポート体制、今後のロードマップについても触れられており、本番環境でKiroを採用する際の判断材料となる情報が網羅されています。 Kiro CLI の紹介：Kiro エージェントをあなたのターミナルへ 新しいCLIエージェント「Kiro CLI」を紹介する記事です。Kiro CLIは、コマンドラインから自然言語でAWSリソースの操作やコード生成を行える革新的なツールで、ターミナル上で直接AIアシスタントと対話できます。従来のIDE統合とは異なり、シェルスクリプトの作成、インフラ管理、トラブルシューティングなど、CLI中心の作業フローに最適化されています。開発者はターミナルを離れることなく、コンテキストを保持しながら効率的に作業を進められるため、DevOpsエンジニアやインフラエンジニアにとって特に有用なツールとなっています。 道に迷わないために: Kiro のチェックポイント機能の紹介 Kiroのチェックポイント機能について詳しく解説しています。長時間実行される開発タスクや複雑なマルチステップの作業において、進捗を保存し、必要に応じて特定の時点に戻れる機能です。記事では、チェックポイントの作成方法、管理方法、復元方法について具体的な操作例とともに説明しています。また、試行錯誤が必要な開発作業や、複数の実装アプローチを比較検討する際に、チェックポイント機能がどのように役立つかを実例を交えて紹介しており、開発効率の向上とリスク軽減に貢献する機能であることが理解できます。 Kiro : コードは仕様と一致していますか？ 〜プロパティベーステストで「正しさ」を測定する〜 プロパティベーステストの概念と、Kiroを使った実装方法について解説しています。従来のユニットテストが特定の入力に対する出力を検証するのに対し、プロパティベーステストはコードが満たすべき性質（プロパティ）を定義し、多様な入力パターンで自動的に検証します。記事では、AIシステムの品質保証において特に重要なこの手法を、Kiroがどのようにサポートするかを具体例とともに紹介しています。エッジケースの発見、回帰テストの強化、仕様とコードの整合性確認など、従来のテスト手法では困難だった課題に対する実践的なアプローチが学べる内容です。 Kiroweeeeeeek in Japan 開催のお知らせ Kiroweeeeeeek in Japanの概要を紹介する記事です。1週間にわたる連載企画の全体像と、各連載記事のテーマ（実装ガイド、IDE連携、セキュリティ、ペアプログラミング、シェルスクリプティングなど）について説明しています。この企画は、Kiroの多様な活用方法を段階的に学べるように設計されており、初心者から上級者まで幅広い読者に対応しています。各記事では実践的なユースケースとベストプラクティスを紹介し、読者がすぐに自分の環境でKiroを活用できるようサポートしています。 Kiro 導入ガイド：始める前に知っておくべきすべてのこと Kiroweeeeeeek in Japan連載の第1回として、Kiroの基本的な実装方法を解説しています。セットアップ手順から基本的な使い方、初期設定のベストプラクティスまで、ステップバイステップで説明しています。記事では、Kiroのインストール方法、認証設定、プロファイル管理、基本的なコマンド操作について詳しく解説しており、初めてKiroを使う方でもスムーズに始められる内容となっています。また、よくある問題とその解決方法も紹介されており、導入時のトラブルシューティングにも役立ちます。 Amazon Q Developer の IDE プラグインから Kiro に乗り換える準備 Kiroweeeeeeek in Japan連載の第2回として、IDE上のAmazon Q DeveloperとCLI上のKiroの連携と使い分けについて解説しています。IDE統合とCLI統合それぞれの強みを理解し、開発フローに応じて最適なツールを選択する方法を学べます。記事では、コード編集時はIDE統合を、インフラ操作やスクリプト作成時はKiroを使うといった、ハイブリッドな活用パターンを紹介しています。また、両ツール間でのコンテキスト共有や、ワークフロー全体でのAI活用戦略についても触れており、開発環境全体の生産性向上に貢献します。 Kiro を組織で利用するためのセキュリティとガバナンス Kiroweeeeeeek in Japan連載の第3回として、Kiroを企業環境で安全に利用するためのセキュリティとガバナンスの考慮事項を解説しています。IAMポリシーの設定、アクセス制御、監査ログの管理、コンプライアンス要件への対応など、エンタープライズ利用に必要な要素を網羅的にカバーしています。記事では、最小権限の原則に基づいたポリシー設計、チーム全体でのKiro利用ガイドラインの策定、セキュリティインシデント発生時の対応手順などを具体的に紹介しています。組織全体でKiroを安全に展開するための実践的なベストプラクティスが学べる内容です。 Kiroを使ったペアプログラミングのすすめ Kiroweeeeeeek in Japan連載の第4回として、KiroとのペアプログラミングによるAI駆動開発の実践方法を紹介しています。従来の人間同士のペアプログラミングとは異なり、AIアシスタントとの協働により、コード品質の向上と開発速度の加速を同時に実現できます。記事では、Kiroに適切な指示を出す方法、生成されたコードのレビューとリファクタリング、テストケースの作成支援など、実践的なペアプログラミングのテクニックを解説しています。AIアシスタントと効果的に協働しながらコードを書く新しい開発スタイルを体験でき、個人開発者からチーム開発まで幅広く応用できる内容となっています。 インフラエンジニアのあなたも！Shell スクリプト開発で Kiro を使ってみよう Kiroweeeeeeek in Japan連載の第5回として、Kiroを活用したシェルスクリプト作成について解説しています。複雑なシェルスクリプトも自然言語で要件を伝えるだけで生成でき、運用自動化が大幅に効率化されます。記事では、ログ解析スクリプト、バックアップ自動化、システム監視スクリプトなど、実務でよく使われるシェルスクリプトの生成例を紹介しています。また、生成されたスクリプトのエラーハンドリング改善、パフォーマンス最適化、可読性向上のためのリファクタリングなど、Kiroを使った継続的な改善プロセスも解説されており、インフラエンジニアの日常業務に直接役立つ内容です。 AWS で利用できる Anthropic ソリューションのご紹介 AnthropicのClaudeモデルをAWS上で活用するためのソリューションパターンを包括的に紹介しています。Amazon Bedrockを通じたClaude活用の基本から、高度なユースケースまで幅広くカバーしています。記事では、Claudeの特徴である長いコンテキストウィンドウ、高度な推論能力、安全性への配慮などを活かしたアーキテクチャ設計のベストプラクティスを解説しています。また、RAG実装、エージェント構築、マルチモーダル処理など、実践的な実装パターンと、それぞれのユースケースに適したモデル選択のガイダンスも提供されており、Claudeを使った生成AIアプリケーション開発の全体像を理解できます。 Claude Code on AWS パターン解説 – Amazon Bedrock / AWS Marketplace ClaudeのコーディングAI機能をAWS環境で活用するための具体的なパターンを解説しています。コード生成、レビュー、リファクタリング、デバッグ支援など、開発ワークフローの各段階でClaudeを効果的に活用する方法を紹介しています。記事では、Amazon BedrockとAWS Marketplaceの両方でのClaude利用方法を比較し、それぞれのメリットと適用シーンを明確にしています。また、CI/CDパイプラインへの統合、コードレビュー自動化、技術的負債の削減など、実務での活用例も豊富に紹介されており、開発チーム全体の生産性向上に貢献する実践的な内容となっています。 Amazon CloudWatch MCP Server と Amazon Q CLI で SAP 運用を効率化 – Part 3 CloudWatch MCP ServerとAmazon Q CLIを組み合わせたSAP運用効率化の連載記事Part 3です。Model Context Protocol (MCP) を活用して、SAP環境の監視データをAIエージェントが理解し、運用タスクを自動化する方法を解説しています。記事では、CloudWatchメトリクスとログをMCPサーバー経由でAIエージェントに提供し、自然言語での問い合わせに対して適切な運用アクションを実行する仕組みを詳しく説明しています。SAP特有の複雑な運用要件に対応しながら、AIを活用した効率的な監視・対応フローを構築する実践的な手法が学べます。 Amazon CloudWatch MCP Server と Amazon Q CLI で SAP 運用を効率化 – Part 4 SAP運用効率化連載の最終回として、より高度な自動化シナリオと実践的なユースケースを紹介しています。インシデント対応の自動化、予防保全のためのパターン分析、運用レポートの自動生成など、AIを活用した次世代のSAP運用管理手法を解説しています。記事では、実際の運用現場で発生する複雑な問題に対して、AIエージェントがどのように対応するかを具体例とともに示しています。また、チーム全体でのナレッジ共有や、運用品質の継続的改善にAIをどう活用するかについても触れており、SAP運用の未来像を描く内容となっています。 参加前にチェック – AWS re:Invent 2025 での Well-Architected とクラウド最適化セッションガイド AWS re:Invent 2025のWell-ArchitectedとCloud Optimizationに関するセッション情報をまとめたガイドです。参加すべきセッションの選び方、事前に押さえておくべきポイント、各セッションの難易度や対象者を詳しく紹介しています。記事では、Well-Architected Framework の最新アップデート、コスト最適化の新しいアプローチ、サステナビリティを考慮したアーキテクチャ設計など、注目のトピックを網羅しています。また、セッション間の関連性や推奨される受講順序も示されており、限られた時間で最大限の学びを得るための戦略的なプランニングに役立つ内容です。 re:Invent 2025 クラウド財務管理セッション完全ガイド：参加前に押さえておきたいポイント re:Invent 2025のクラウド財務管理に関するセッション情報を網羅したガイドです。コスト最適化、予算管理、FinOpsの実践、チャージバック・ショーバックの仕組みなど、財務管理に関する最新情報を得られるセッションを体系的に紹介しています。記事では、CFOやFinOpsチーム向けのビジネス寄りのセッションから、エンジニア向けの技術的なコスト最適化手法まで、幅広い視点でのセッション情報を提供しています。また、AWS Cost Anomaly Detection、Savings Plans、Reserved Instancesなどの最新機能に関するセッションも紹介されており、組織全体でのクラウドコスト管理戦略を学べる内容です。 AWS re:Invent 2025: 4つの変革的テーマで学ぶセキュリティセッションガイド re:Invent 2025のセキュリティに関するセッションを4つの変革的テーマ（ゼロトラスト、AI/MLセキュリティ、脅威検知と対応、コンプライアンスとガバナンス）に分けて紹介しています。各テーマごとに、基礎から応用まで段階的に学べるセッション構成を解説しています。記事では、生成AIアプリケーションのセキュリティ対策、サプライチェーンセキュリティ、クラウドネイティブなセキュリティアーキテクチャなど、最新のセキュリティトレンドに対応したセッション情報を提供しています。また、実際のインシデント対応事例や、セキュリティ自動化のベストプラクティスを学べるセッションも紹介されており、包括的なセキュリティ戦略の構築に役立つ内容です。 re:Invent 2025 で学ぶ AI を活用した運用管理の構築方法 re:Invent 2025のAI駆動型運用管理に関するセッション情報を紹介しています。AIを活用した運用自動化、異常検知、インシデント対応、予測的メンテナンスなど、次世代の運用管理手法を学べるセッションをまとめています。記事では、Amazon Q Developer の運用調査機能、CloudWatch の AI 機能、Systems Manager の自動化機能など、AWSの最新運用ツールに関するセッションを体系的に紹介しています。また、AIOpsの実践事例、運用コストの削減手法、チーム全体での運用効率化戦略など、実務に直結する内容を学べるセッション情報も提供されており、運用チームの変革を目指す方に最適なガイドとなっています。 サービスアップデート Amazon Q Developer のコスト管理機能を強化 Amazon Q Developer に強化されたコスト管理機能が追加されました。開発チームは、Q Developer の利用状況とコストをより詳細に追跡・管理できるようになり、予算管理が容易になります。ユーザーごと、プロジェクトごとの利用状況を可視化でき、コスト最適化の意思決定がしやすくなります。 Amazon Bedrock Data Automation で同期的な画像処理をサポート Amazon Bedrock Data Automation が同期的な画像処理に対応しました。これにより、リアルタイムでの画像分析や処理が必要なユースケースにおいて、即座に結果を取得できるようになります。ドキュメント処理、OCR、画像からのデータ抽出などのワークフローがより効率的になり、レスポンスタイムが重要なアプリケーションでの活用が広がります。 Amazon Bedrock Model Import で OpenAI GPT OSS モデルをサポート Amazon Bedrock の Model Import 機能が大幅に拡張され、OpenAI の GPT OSS モデルのカスタムウェイトのインポートに対応しました。これにより、お客様は既存のモデルをカスタマイズして Amazon Bedrock の統合された環境で管理・運用できるようになり、インフラストラクチャの管理が不要なサーバーレス環境で運用し、運用の複雑さが軽減されます。 Amazon Bedrock が追加リージョンで利用可能に Amazon Bedrock の提供リージョンが拡大されました。より多くの地域のお客様が、低レイテンシーで生成AIサービスを利用できるようになります。データレジデンシー要件への対応も容易になり、グローバルな展開が加速します。 Amazon Bedrock Guardrails がコーディングユースケースに対応 Amazon Bedrock Guardrails がコーディングユースケースに特化した保護機能を提供開始しました。コード生成時のセキュリティリスク、脆弱性のあるコードパターン、不適切なコード生成を防ぐためのガードレールを設定でき、安全なコード生成AIアプリケーションの構築が可能になります。企業環境でのコード生成AI活用において重要なセキュリティ要件を満たせます。 Amazon Bedrock Guardrails Automated Reasoning Checks で自然言語サポートを追加 Amazon Bedrock Guardrails の Automated Reasoning Checks は、形式検証と呼ばれる技術を利用して生成AIモデルの出力の正確性とポリシー準拠を検証する機能です。このアップデートにより、セキュリティポリシーやコンプライアンス要件を自然言語で記述でき、より直感的にポリシー検証を行えるようになります。技術的な専門知識がなくても、ビジネス要件を直接ポリシーとして表現できます。 Amazon Bedrock で Priority と Flex の推論サービスティアを発表 Amazon Bedrock に新しい推論サービスティア「Priority」と「Flex」が追加されました。Priorityティアは低レイテンシーが求められるミッションクリティカルなワークロード向けで、安定したパフォーマンスを保証します。Flexティアはコスト効率を重視したバッチ処理向けで、スループット重視のワークロードに最適です。ユースケースに応じた最適な選択が可能になり、コストとパフォーマンスのバランスを取りやすくなります。 Amazon Bedrock Data Automation が Speech Analytics で10言語に対応 Amazon Bedrock Data Automation のSpeech Analytics機能の対応言語が10言語に拡大されました。日本語を含む多言語でのドキュメント処理やデータ抽出が可能になり、グローバルなビジネスでの活用が広がります。多言語対応により、地域を問わず一貫したデータ処理ワークフローを構築できます。 Amazon SageMaker にビルトインAIエージェント機能を搭載したNotebooksを発表 Amazon SageMaker に、AIエージェントが組み込まれた新しいNotebook機能が追加されました。データサイエンティストや機械学習エンジニアは、自然言語でコードの生成や説明、デバッグの支援を受けられるようになり、開発効率が大幅に向上します。Notebook内で直接AIアシスタントと対話しながら作業を進められるため、機械学習ワークフローがよりスムーズになります。この機能により、初心者でも高度な機械学習タスクに取り組みやすくなります。 Amazon SageMaker Data Agent を発表 – 分析とAI/ML開発を加速 Amazon SageMaker に新しいData Agent機能が追加されました。この機能により、データの準備、探索、変換といった時間のかかる作業を自動化できます。自然言語でデータ処理のリクエストを行うと、AIエージェントが適切なデータ処理パイプラインを構築してくれるため、データサイエンティストはモデル開発により多くの時間を割けるようになります。データエンジニアリングの専門知識がなくても、高度なデータ処理が可能になる画期的な機能です。 Amazon SageMaker HyperPod で IDE と Notebooks の AI 機能を発表 大規模な機械学習トレーニング向けの Amazon SageMaker HyperPod に、IDEとNotebookのAI支援機能が追加されました。分散トレーニング環境でもAIアシスタントの支援を受けながら開発できるようになり、大規模モデルの開発効率が向上します。複雑な分散トレーニングのコード作成やデバッグも、AIの支援により容易になります。 Amazon EKS と ECS でフルマネージド MCP サーバーをプレビュー提供開始 Amazon EKS と Amazon ECS で、Model Context Protocol (MCP) サーバーのフルマネージドサービスがプレビューとして提供開始されました。コンテナ環境でのAIモデルのコンテキスト管理が簡素化され、より効率的なAIアプリケーションの構築が可能になります。MCPサーバーの運用負荷が軽減され、開発者はアプリケーションロジックに集中できます。 Amazon Lex で Wait and Continue 機能が10言語に対応 会話型AIサービスの Amazon Lex に、Wait and Continue 機能が追加され、日本語を含む 10言語に対応しました。ユーザーが応答を考える時間を取れるようになり、より自然な会話体験を提供できます。タイムアウトの柔軟な制御により、ユーザーフレンドリーな対話フローを実現できます。 Amazon EC2 P6 B300 インスタンス – NVIDIA Blackwell Ultra GPU 搭載で提供開始 最新の NVIDIA Blackwell Ultra GPU を搭載した Amazon EC2 P6 B300 インスタンスの提供が開始されました。大規模言語モデルのトレーニングや推論において、従来世代と比較して大幅な性能向上とコスト効率の改善を実現します。最先端のAIワークロードに最適なインスタンスで、より高速なモデル開発が可能になります。 Amazon Polly で生成AIを活用した新しい TTS エンジンを発表 Amazon Polly に生成AI技術を活用した新しいText-to-Speech (TTS) エンジンが追加されました。より自然で表現豊かな音声合成が可能になり、感情表現やイントネーションの質が大幅に向上しています。カスタマーサービス、コンテンツ制作、アクセシビリティ向上など、幅広い用途での活用が期待されます。 Amazon CloudWatch で EKS のコンテナ単位のサブミニッツ GPU メトリクスをサポート Amazon CloudWatch が、Amazon EKS 上のコンテナ単位で1分未満の粒度でGPUメトリクスを収集できるようになりました。AIワークロードのパフォーマンス監視とトラブルシューティングがより詳細に行え、GPU利用率の最適化やコスト削減に役立ちます。リアルタイムに近い監視により、問題の早期発見が可能になります。 AWS Security Incident Response で AI 駆動型調査機能を発表 AWS Security Incident Response に、AIエージェントを活用した自動調査機能が追加されました。セキュリティインシデント発生時に、AIが自動的に関連情報を収集・分析し、対応を支援することで、インシデント対応時間を大幅に短縮できます。セキュリティアナリストの負担を軽減し、より迅速な脅威対応が可能になります。 AWS WAF で Web Bot 認証サポートを追加 AWS WAF に Web Bot 認証機能が追加されました。正規のボット（検索エンジンクローラーなど）と悪意のあるボットを区別し、適切にトラフィックを制御できるようになります。ボット対策の精度が向上し、正規ユーザーへの影響を最小限に抑えながらセキュリティを強化できます。 Amazon CloudWatch Application Signals に GitHub Action MCP Server を追加 Amazon CloudWatch Application Signals に GitHub Action との統合機能と MCP Server の改善が追加されました。CI/CDパイプラインとアプリケーション監視の連携が強化され、開発ワークフローがより効率的になります。デプロイメントの品質を自動的に監視し、問題を早期に検出できます。 AWS Marketplace で Bedrock AgentCore Runtime 向け A2A Server を提供開始 AWS Marketplace で、Amazon Bedrock AgentCore Runtime 向けの Agent-to-Agent (A2A) Server が提供開始されました。複数のAIエージェント間の連携を容易にし、より複雑なAIワークフローの構築が可能になります。エージェント間の通信プロトコルが標準化され、マルチエージェントシステムの開発が簡素化されます。 AWS DMS Schema Conversion で SAP Sybase ASE から PostgreSQL への変換をサポート AWS Database Migration Service (DMS) の Schema Conversion 機能が、SAP Sybase ASE から PostgreSQL へのスキーマ変換をサポートしました。レガシーデータベースからの移行がより容易になり、モダナイゼーションを加速できます。 AWS Transform for VMware で Landing Zone 設定生成機能を強化 AWS Transform for VMware に、Landing Zone 設定を自動生成する機能が追加されました。VMware環境からAWSへの移行計画を立てる際に、適切なLanding Zone構成を自動的に提案してくれるため、移行プロジェクトの初期設計が効率化されます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近見たドラマは「阿修羅のごとく」です。

2025 年 11 月 18 日、NVIDIA Blackwell Ultra GPU によって高速化された次世代 GPU プラットフォームである Amazon Elastic Compute Cloud (Amazon EC2) P6-B300 インスタンスの一般提供をお知らせします。これらのインスタンスは、前世代のインスタンスと比較して 2 倍のネットワーク帯域幅と 1.5 倍の GPU メモリを提供し、大規模な AI アプリケーション向けにバランスの取れたプラットフォームを構築します。 これらの改善を経た P6-B300 インスタンスは大規模な AI モデル 、特に Mixture of Experts (MoE) やマルチモーダル処理などの高度な手法を採用している AI モデルのトレーニングと提供に最適です。1 兆パラメータのモデルを扱い、何千もの GPU にわたる分散トレーニングを必要とする組織に対して、これらのインスタンスはコンピューティング、メモリ、ネットワーク機能の完璧なバランスを提供します。 前モデルと比較して加えられた改善点 P6-B300 インスタンスは 6.4 Tbps の Elastic Fabric Adapter (EFA) ネットワーク 帯域幅を提供し、大規模な GPU クラスター間の効率的な通信をサポートします。これらのインスタンスには 2.1 TB の GPU メモリが搭載されているため、大規模モデルを 1 つの NVLink ドメイン内に配置できます。その結果、モデルのシャーディングと通信のオーバーヘッドが大幅に削減されます。これらのインスタンスを EFA ネットワーキングと AWS Nitro System の高度な仮想化およびセキュリティ機能と組み合わせると、AI ワークロードにおいて前例のないスピード、スケール、セキュリティが実現します。 EC2 P6-B300 インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU システムメモリ GPU GPU メモリ GPU から GPU への相互接続 EFA ネットワーク帯域幅 ENA 帯域幅 EBS 帯域幅 ローカルストレージ P6-B300.48xlarge 192 4TB 8x B300 GPU 2,144 GB HBM3e 1,800 GB/秒 6.4 Tbps 300 Gbps 100 Gbps 8x 3.84TB 知っておくと便利な情報 永続的ストレージに関しては、料金パフォーマンスの考慮事項によって、AI ワークロードは主に Amazon FSx for Lustre 、 Amazon S3 Express One Zone 、 Amazon Elastic Block Store (Amazon EBS) などの高性能な永続的ストレージオプションを組み合わせて使用します。例を挙げると、P6-B300 の専有 300 Gbps Elastic Network Adapter (ENA) ネットワーキング により、S3 Express One Zone を使用した高スループットのホットストレージアクセスが可能になり、大規模なトレーニングワークロードをサポートできます。FSx for Lustre を使用している場合、EFA と GPUDirect Storage (GDS) を組み合わせて P6-B300 インスタンスの Lustre ファイルシステムへの最大 1.2 Tbps のスループットを実現し、モデルをすばやくロードできるようになりました。 今すぐご利用いただけます P6-B300 インスタンスは、米国西部 (オレゴン) AWS リージョン の Amazon EC2 Capacity Blocks for ML および Savings Plan でご利用いただけるようになりました。 P6-B300 インスタンスのオンデマンド予約については、アカウントマネージャーにお問い合わせください。Amazon EC2 でのいつものお支払いと同様に、お支払いいただくのは使用した分の料金のみです。詳細については、「 Amazon EC2 の料金 」をご覧ください。アプリケーションの移行を開始するのに役立つ、 高速コンピューティングインスタンス のフルコレクションをご覧ください。 詳細については、 Amazon EC2 P6-B300 インスタンスのページ をご覧ください。 AWS re:Post for EC2 に、または通常の AWS サポート担当者を通じて、ぜひフィードバックをお寄せください。 – Veliswa 原文は こちら です。

本記事は 2025 年 11 月 24 日に公開された Anthony Hayes による “ The Future of AWS CodeCommit ” を翻訳したものです。 2024年7月、私たちは採用状況やお客様のニーズに関する評価に基づき、AWS CodeCommit の段階的に廃止する方針を発表しました。しかし、私たちはデータの分析やお客様の声を聞くことを止めていませんでした。そして、お客様が示してくださったことは明確でした。コードリポジトリには AWS が管理するソリューションが必要だということです。このフィードバックを受け、CodeCommit は本日より改めて、完全な一般提供（GA）に戻ります。 私たちはお客様の声をお聞きしました 昨年の段階的廃止の発表後、多くのお客様からご意見をいただきました。フィードバックは率直で、多くのことを明らかにしてくれました。皆様が教えてくださったのは、CodeCommit は単なるコードリポジトリではなく、インフラストラクチャの重要な要素だということです。IAM との深い統合、VPC エンドポイントのサポート、CloudTrail ログ記録、そして CodePipeline や CodeBuild とのシームレスな連携は、とくに規制業界で運用しているチームや、すべての開発インフラストラクチャを AWS 内に配置したいチームにとって大きな価値があります。要するに、CodeCommit は多くのお客様にとって不可欠なものであることを学びました。そのため、私たちは CodeCommit のサービス提供を再開いたします。 今回の段階的廃止の発表により、不確実性を生んでしまったことは認識しています。CodeCommit からの移行を計画または実行するために時間とリソースを投資された皆様には、お詫び申し上げます。私たちはこの経験から学び、今後より良いサービスを提供することをお約束します。 今日から変わること 以下が本日からの変更点です。 CodeCommit は新規のお客様にも再び開放されます – 本日より新規のお客様のサインアップが可能になります。新しいアカウントのオンボーディングやリポジトリの作成をお待ちいただいていた場合は、AWS コンソール、CLI、または API を通じて今すぐ実行できます。 現在または過去にご利用いただいていたお客様へ – すでに移行を完了し、GitHub、GitLab、Bitbucket、またはその他のプロバイダーへの移行を完了している場合もあるかと思います。これらは優れたプラットフォームであり、それらを使用するという決定を全面的にサポートします。もし CodeCommit への復帰をご検討の場合は、サポートチームやアカウントチームがお手伝いします。 移行の途中にある場合は、計画を一時停止または取り消すことができます。AWS サポートまたはアカウントチームに連絡して、具体的な状況を話し合い、最適な進め方を決定してください。 CodeCommit を使い続けてくださった方々には、この期間中のご辛抱に感謝します。私たちは蓄積された機能リクエストとサポートチケットのバックログに取り組んでおり、お客様のニーズに応じて優先順位をつけています。今後も、サービス改善やワークフロー（人間、機械、エージェントを含む）支援のご意見を引き続きお聞かせください。 今後の予定 私たちは CodeCommit を維持するだけでなく、投資を進めていきます。ロードマップは次のとおりです。 Git LFS サポート（2026 年第 1 四半期）– これはもっとも多くリクエストされた機能です。Git Large File Storage により、画像、動画、デザインアセット、コンパイル済みバイナリなどの大きなバイナリファイルを、リポジトリを肥大化させることなく効率的に管理できるようになります。大きなアセットに対して、より高速なクローン、より良いパフォーマンス、よりクリーンなバージョン履歴を実現します。 リージョン拡張（2026 年第 3 四半期開始）– CodeCommit は eu-south-2 と ca-west-1 の追加の AWS リージョンに拡張され、アプリケーションを構築およびデプロイしている場所により近くなります。 これらの機能と追加のロードマップ項目については、今後数か月のうちに更に詳細をお知らせします。最新の AWS リリースについては、 What’s New フィードをご確認ください。 料金、SLA、および開始方法 料金に変更はありません。現在の料金体系は CodeCommit 料金ページ で確認できます。また、サービス規約で定義されている 99.9% の稼働時間 SLA を引き続き維持します。 CodeCommit を初めて使用する場合、または移行後に戻る場合は、 開始ガイド でステップバイステップの手順を確認してください。移行のサポートや特定のセットアップに関する質問については、AWS サポートまたはアカウントチームにお問い合わせください。 今すぐご利用いただけます AWS CodeCommit は現在 29 のリージョンで利用できます。新規のお客様は今すぐリポジトリの作成を開始できます。CodeCommit コンソールにアクセス して開始してください。 皆様の AWS へのフィードバック、ご辛抱、そして変わらぬご信頼に感謝いたします。私たちは CodeCommit を AWS 開発にもっとも統合された Git リポジトリサービスにしていくことをお約束します。 詳細情報: AWS CodeCommit ドキュメント AWS DevOps ブログ CodeCommit 料金 翻訳は AppDev Consultant の宇賀神が担当しました。

本記事は「 Making your Kiro credits go further 」を翻訳したものです。 Kiro の Auto エージェントがより効率的になり、Kiro に期待する高品質を維持しながら、クレジットでより多くのことができるようになりました。 より効率的な Auto エージェント 私たちの Kiro における目標は、最高の価格で最高の結果をお届けすることです。この目標を達成するため、私たちは以前から Auto を開発してきました。Auto は Sonnet 4.5 などの最先端モデルと、意図検出、キャッシュなどの専門的なモデルや最適化技術を組み合わせたエージェントです。Auto の品質については高い基準を設けており、最先端モデルが提供するレベル以下のものは受け入れません。11 月 7 日に新バージョンの Auto をリリースした結果、リクエストで消費するクレジットが大幅に削減されました。日常的な一般的なリクエストでは、お客様のクレジット使用量が 21 % 削減されました。最も要求が厳しく複雑なリクエストをお持ちのお客様では、36 % の削減を実現しています。 これが日々の開発作業にどのような意味を持つのでしょうか？以前は 1 クレジットを使用していた一般的なリクエストが、現在は 0.79 クレジットで済むようになりました。つまり、現在の Kiro プランのクレジットで約 20 %多くのことが実現でき、同じクレジット数でより長期間の開発作業が可能になります。 Kiro ユーザーで、Caylent のプリンシパルアーキテクトかつ AWS コミュニティビルダーの Andres Moreno 氏は次のように述べています。「Kiro がリクエストあたりのクレジット使用量を確実に削減していることを実感しています。とても素晴らしく、処理速度も非常に高速です。」 すでに Auto をご利用の方は、この削減効果を実感していただけているはずです。まだ Auto をお試しでない方は、今が始める絶好のタイミングです！そして、これはまだ始まりに過ぎません。私たちはニューラルネットワークと形式的推論を組み合わせたニューロシンボリック AI を含む、Auto のエキサイティングな改善に取り組んでいます。これらの進歩により、より良い要件の作成、実装のより効果的な検証、そしてクレジット使用量を効率的に保ちながらより高品質なコードの生成が可能になります。

本記事は「 Introducing Opus 4.5 in Kiro 」を翻訳したものです。 Claude Opus 4.5 のサポート提供を開始できることを嬉しく思います。Opus 4.5 は、Anthropic 社の最新かつ最も高性能なモデルで、コーディングとエージェントワークフローにおいて新たな基準を打ち立てています。 Opus 4.5 は、SWE-bench において最先端のパフォーマンスを達成しています。開発タスクの実装や複雑なバグの修正において、複数のシステムにわたって推論を行いながら、トレードオフと曖昧さのバランスをより適切に取ることができます。Opus 4.5 は、長時間のタスクを実行し、複雑なコードベース全体にわたって推論できるエージェントを動かすことに最適であり、仕様駆動開発に理想的です。 このアップデートにより、Opus 4.5 を使用して最も複雑な本番ソフトウェア開発タスクを解決し、詳細な仕様書やアーキテクチャ設計を生成できるようになります。一方、Auto は日常的な機能を迅速かつコスト効率よく実装するお手伝いをします。 このモデルは、Kiro IDE と Kiro CLI において、Google、GitHub、AWS BuilderID でログインするユーザーにご利用いただけます。現在、AWS IAM Identity Center でログインするお客様には Opus 4.5 をご利用いただけません。Opus 4.5 のクレジット倍率は 2.2 倍で、Sonnet 4.5 の 1.3 倍、Haiku 4.5 の 0.4 倍と比較してご参考ください。 Kiro での Opus 4.5 は実験的サポート として提供されています。皆様がどのようなものを構築されるか楽しみにしており、 Discord や X でのフィードバックをお待ちしています。

こんにちは、Amazon Q Developer CLI Contributor 兼ソリューションアーキテクトの小西 (konippi) です。 Kiroweeeeeeek in Japan の Day 6 では、Amazon Q Developer CLI から Kiro CLI で変更された点や Kiro CLI のおすすめ機能について解説します。本記事では、 Kiro の一般提供 で利用可能になった Kiro CLI に焦点を当て、「Amazon Q Developer CLI から Kiro CLI で何が変わったの？」という疑問をお持ちの方の参考になれば幸いです。 まだ Day 5 の記事を読んでいない方はぜひ、松本さん執筆の「 インフラエンジニアのあなたも！Shell スクリプト開発で Kiro を使ってみよう 」をご一読ください。 はじめに Kiro が一般提供されてからちょうど 1 週間が経ちましたが、Kiro CLI はもうお試しいただけたでしょうか？まだインストールがお済みでない方は、 インストール方法 を参考にぜひインストールしてみてください。また、Kiro CLI の概要を知りたい方はぜひ「 Kiro CLI の紹介 : Kiro エージェントをあなたのターミナルへ 」をご一読ください。 Amazon Q Developer CLI から Kiro CLI へ Kiro CLI は Amazon Q Developer CLI の次期アップデート版となっており、2025 年 11 月 17 日にリリースされた Amazon Q Developer CLI v1.20.0 より正式に Kiro CLI にアップデートされました。このアップデートに伴い、起動コマンドも q / q chat から kiro-cli に変更されました。 過去の変更履歴を確認したい方は kiro-cli version --changelog=all コマンドよりご確認いただけます。 $ kiro-cli version --changelog=all Changelog for all versions: Version 1.20.0 (2025-11-17) - Added: The Kiro CLI is here! Kiro CLI leverages the Kiro Auto agent to deliver the best results at the best price, in your terminal, and takes you from natural language, to code, to deployment. Kiro CLI supports different agent modes, MCPs, Kiro steering files, and custom agents, allowing you to mold the CLI to meet your needs. Version 1.19.7 (2025-11-17) - Added: Kiro CLI announcement. Learn more at kiro.dev/cli-upgrade Version 1.19.6 (2025-11-13) - Fixed: Right arrow key being disabled - [#3439](https://github.com/aws/amazon-q-developer-cli/pull/3439) Version 1.19.5 (2025-11-12) - Fixed: Minor bug fixes (以下省略...) Kiro CLI リリースによる変更点 2025 年 11 月 24 日時点では、ロゴやテーマカラー、設定ファイルパスを除き Kiro CLI は Amazon Q Developer CLI と基本機能に差異はございません。また、Amazon Q Developer サブスクリプションと Kiro サブスクリプション利用における基本機能も差異はございません。つまり、基本機能に関しては今までの Amazon Q Developer CLI と同等であり、これからの Kiro CLI のアップデートを楽しみにしていただけますと幸いです。本記事では、利用条件 (認証方法やライセンスなど) や設定ファイルパスなどの変更点について解説していきます。 利用条件における変更点は以下の通りです。 利用条件 Kiro CLI Amazon Q Developer CLI インストール方法 ネイティブインストール dmg と zip ベースのインストール 認証方法 Google, GitHub, AWS Builder ID, AWS IAM Identity Center AWS Builder ID, AWS IAM Identity Center エントリーポイント kiro-cli q / q chat ルール Kiro ステアリング Amazon Q Developer ルール サブスクリプション (詳細は こちら ) Amazon Q Developer, Kiro Amazon Q Developer, Kiro ライセンス AWS Intellectual Property License Apache 2.0 設定ファイルパスの変更点は以下の通りです。 Configuration Scope Kiro CLI Amazon Q Developer CLI MCP サーバー ユーザー ~/.kiro/settings/mcp.json ~/.aws/amazonq/mcp.json ワークスペース .kiro/settings/mcp.json .amazonq/mcp.json プロンプト ユーザー ~/.kiro/prompts ~/.aws/amazonq/prompts ワークスペース .kiro/prompts .amazonq/prompts カスタムエージェント ユーザー ~/.kiro/agents ~/.aws/amazonq/cli-agents ワークスペース .kiro/agents .amazonq/cli-agents ルール / ステアリング ユーザー ~/.kiro/steering ~/.aws/amazonq/rules ワークスペース .kiro/steering .amazonq/rules 設定 グローバル ~/.kiro/settings/cli.json – 他詳細な変更点は以下の通りです。 Kiro CLI のアップデート時には既存の .amazonq フォルダを直接変更しない MCP サーバー、エージェント、ルール、プロンプトは、インストール時に ~/.aws/amazonq フォルダから ~/.kiro 内の適切なフォルダ (上記参照) に自動的にコピー Kiro Web ポータルによる認証 ログは $TMPDIR/kiro-log に書き込み 既存のカスタムエージェントは引き続き動作可能 デフォルトエージェント名が q_cli_default から kiro_default に変更 ( kiro-cli agent またはチャット内の /agent list コマンドにて確認できます) kiro_default の設定パス欄が “No path found” なのはインメモリで管理しているため デフォルトエージェントは Amazon Q Developer ルールと Kiro ステアリングの両方をサポート UI の色とロゴがアップデート おすすめ機能 ここからは Amazon Q Developer CLI Contributor の私から Kiro CLI のおすすめ機能をいくつかご紹介します。Kiro CLI には 20 を超える機能が用意されており、その中でも特に便利な機能を厳選してご紹介します。 ファジー検索機能 kiro-cli コマンドでチャット画面を表示している際、 Ctrl+S を押下することで全てのコマンドをファジー検索可能な機能が搭載されています。 ※ 実験機能 ( /experiment ) については、有効化された機能のみ表示されます。 カスタムエージェント機能 カスタムエージェントは、異なるユースケースごとに特定の構成を定義することで、Kiro の動作をカスタマイズすることができます。各カスタムエージェントはエージェントがアクセス可能なツール、付与される権限、含めるコンテキストを指定する構成ファイルによって定義されます。カスタムエージェントに関する詳細な内容は「 Amazon Q Developer CLI カスタムエージェントで開発の混乱を乗り越えよう 」をご一読いただけますと幸いです。 カスタムエージェント機能で解決できることの例を以下に示します。 特定のツールを事前承認 : プロンプトなしで実行できるツールを定義 ツールアクセスを制限 : 利用可能なツールを制限して複雑さを軽減 関連するコンテキストを含める : プロジェクトファイル、ドキュメント、システム情報を自動読み込み ツールの動作を設定 : ツールの動作方法に関する特定のパラメータを設定 以下の画像では、フロントエンドエージェントとバックエンドエージェントの例を示しています。フロントエンドエージェントには Figma という追加のツールがあり、バックエンドエージェントには PostgreSQL という追加のツールがあることに注目してください。さらに、フロントエンドエージェントは fs_write とすべての Figma ツールを信頼しますが、バックエンドエージェントは fs_write の使用許可を求め、2 つの PostgreSQL ツールのうち 1 つだけを信頼します。 スクリーンショット貼り付け機能 /paste コマンドもしくは Ctrl+V によってクリップボードにコピーしたスクリーンショットを直接チャットに貼り付けることができます。 スクリーンショット貼り付け機能で解決できることの例を以下に示します。 UI/UX レビューの迅速化 : スクリーンショットをもとに改善点やアクセシビリティの問題を指摘してもらえる パフォーマンス分析の効率化 : モニタリングツールのグラフやメトリクスから、ボトルネックを特定してもらえる /experiment コマンド /experiment コマンドは、実験的に利用可能な高度な機能を提供するコマンドです。実験機能であるため、 いつでも変更や削除される可能性があること 機能自体完璧でない可能性があること を認識していただいた上でご利用いただくようお願いします。 現在利用可能な実験機能は以下の通りです。 /knowledge : チャットセッション間で情報を保存・取得できる永続的なコンテキストストレージ機能 /thinking : 複雑な問題を段階的に推論するための思考プロセス機能 /tangent : 一時的な独立した会話モードに入る機能 /todos : タスクリストを作成・管理できる機能 /checkpoint : ワークスペースのスナップショットを作成し、ファイルの状態を保存・比較・復元できる機能 ( /tangent 使用中は使用不可) コンテキスト使用率インジケーター : プロンプトにコンテキスト使用率をパーセンテージで表示する機能 Delegate ツール : バックグラウンドで非同期に実行されるサブエージェントプロセスを起動・管理できる機能 まとめ Kiro CLI は Amazon Q Developer CLI の次期アップデート版として、基本機能を維持しながら、認証方法の拡張やライセンスの変更などの利用条件、設定ファイルパスなどが刷新されました。また、今回ご紹介したファジー検索やカスタムエージェント機能などのおすすめ機能に加え、開発効率を向上させる便利な機能が多数搭載されています。これからの Kiro CLI に関するアップデートをぜひ楽しみにしていただければと思います。 Kiro CLI に関しては、 Kiro のドキュメント を参照し、ぜひたくさんの機能を触ってみてください！ 著者 小西 杏典 (Kyosuke Konishi) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 2025 年に新卒入社した 1 年目のソリューションアーキテクト konippi です。Amazon Q Developer CLI をはじめ、いろいろな OSS に Contribution することが好きです。 X : https://x.com/_konippi LinkedIn : https://www.linkedin.com/in/kyosuke-konishi GitHub : https://github.com/konippi

こんにちは、ソリューションアーキテクトの松本です。 本ブログは Kiroweeeeeek ( X: #kiroweeeeeeek ) の第 5 日目です。昨日のブログは菅原さんの「 Kiro を使ったペアプログラミングのすすめ 」という内容でした。これまでに公開した記事の一覧は Kiroweeeeeeek in Japan 開催のお知らせ をご参照ください。 本ブログでは、これまでの連載と少し視点を変えて、「Kiro は私に不要なツールでは？」と見逃しているかもしれない皆様にメッセージをお届けしたいと思います。具体的には、アプリケーション開発担当ではなく、サーバやミドルウェアを中心に扱うインフラエンジニアの皆様に、「使ってみたい」と思ってもらえるよう Kiro の魅力がお伝えしたいと思います。この記事は日曜に投稿しているので、ちょっとした番外編だと思って気楽に読んでいただければ幸いです。では、本編へどうぞ！ はじめに 私も以前はインフラエンジニアとして働いており、ちょっとした構築・運用作業を Shell スクリプトで自動化することが好きでした。当時を思い起こしてみると、こういったスクリプトの開発はテキストエディタや vi エディタで作成することがほとんどで、Eclipse や VSCode のようないわゆる統合開発環境は自分にとって無用の長物、過ぎた代物だと思い込んでいました。 しかし、そうではないことを知った今、「もしかしたら、あの時の私のように見過ごしてしまう方もいるかもしれない！」と気づいた私はいてもたってもいられず、今こうして一心不乱に筆を取っているというわけです。 皆様にできるだけわかりやすくお伝えするため、本ブログでは二つのシナリオを通して Kiro の魅力をご紹介いたします。 シナリオ 1 : ディスク容量をクリーンアップするスクリプトを開発する サーバ上のディスク容量を確保するために、定期的にファイル削除やローテーションを実行するのは必要な運用の一つです。単純なログファイルであれば logrotate などを利用して実装可能ですが、中にはアプリケーション固有のビジネスロジックに基づいたファイル操作・管理を必要とするケースも少なくありません。このようなスクリプトを Kiro を利用して開発するシナリオを考えてみましょう。 要件 このシナリオでは、「特定ディレクトリのファイル一覧を取得し、同一ファイルが Amazon S3 にアップロード済みであれば削除する」というディスククリーンアップスクリプトを考えてみましょう。 こういう “ちょっとした” スクリプトの開発では、ドキュメントが残っていないなんてことも残念ながらよくあります（私にも謝らなければいけない過去があります）。しかし、Kiro の Spec mode を利用すれば、Kiro の対話を通じてドキュメントもセットで生成してもらうことができるのです。 Kiro での作業手順 1. Kiro を起動し、要件を伝える Spec mode では次のように自然言語で要求を伝え、仕様書を生成してもらうことから始まります。 Linux サーバの特定ディレクトリのファイル一覧を取得し、同一ファイルが S3 にアップロード済みであればローカルディスクからそのファイルを削除するディスククリーンアップ Shell スクリプトを開発してください。 これは作成された仕様書の一部ですが、概ね期待していた内容が記載されています。 図中のように WHEN や IF、THEN で表現する記法は EARS 記法 (Easy Approach to Requirements Syntax) と呼ばれるもので、 要件を構造化して記述する手法です。要件の曖昧さを排除し、テストケースの作成も容易になるという特徴があります。Kiro ではこの記法を活用することで、明確で実装しやすい仕様書を自動生成しています。 2. Kiro が生成したドキュメントをレビューする 仕様書のレビューを進めていくと、バケット名などのパラメータは実行時に引数として与える想定であることが分かりました。 コマンドの引数でパラメータを与える方法だと、パラメータ変更のたびにジョブの呼び出し側の修正（例えば JP1 ジョブの定義など）が必要になるため、あまり望ましくありません。そこで、コンフィグファイルとしてパラメータ管理するように、仕様書の修正をリクエストします。 実行時のパラメータ指定は引数ではなくコンフィグファイルで定義するようにしたいです。 そうすると次のような修正案が提示されました。Config_File の概念が追加されており、これなら良さそうです。Kiro による自動生成と人間によるレビューでヒューマンインザループを実現できるので、適切なシーンで人間が介入できます。 なお、修正された内容は下図のように diff 表示が可能で、変更点を把握しやすくなっています。 3. 設計フェーズに進む 仕様書の生成は完了とし、次は設計フェーズに進みましょう。仕様書の生成と同様に、まずは Kiro が設計書を作成します。設計フェーズでも Kiro が生成した初版に少し手を加えて欲しかったので、次のような追加の指示を与え、設計書の生成を完了しました。 このスクリプトで登場するファイルの一覧とその情報（オーナーやパーミッション）と、セットアップの手順、手動実行の手順も書いておいてほしいです。cronで定期実行するつもりなので、セットアップ手順にはその部分も含めてください。 このファイル一覧があれば、OS 上のファイル変更を監視するミドルウェアを導入していた場合でも、監視対象の設定追加がスムーズに行えますね。 4. Kiro に Task の実行を指示する 設計書の生成も完了したので、スクリプト本体の開発を進めてもらいました。ところが、生成されたスクリプトを見てみるとスクリプト内のコメントが全て英語になっていました。できれば日本語のほうが読みやすいですから、設計に戻って追加の指示を与えました。 このスクリプトのユーザは日本語のほうが読みやすいので、設計書を修正してスクリプト内のコメントは全て日本語になるように指定してください。 このように的確に設計を修正してくれました。実装タスクは一部実行してしまっていたので、設計書の修正を伝えて再実行をリクエストします。 変更点も正確に把握できており、期待通りにスクリプトの修正が完了しました。このように、先のフェーズに進んだ後でも要求や設計に立ち返って、修正していくことが可能です。 このあとは順調にタスクを進め、一通りの実装作業を完了することができました。これはログ出力関数を作成しているシーンですが、今回のスクリプト以外にも活用できそうです。 このように、Kiro の Spec mode を利用することで、インフラエンジニアが必要とするスクリプトを簡単に開発することができ、かつ丁寧なドキュメントも用意できることがお分かりいただけたと思います。 シナリオ 2 : 既存のスクリプトを読み解き、改善する 悲しいことにこれもよくあることですが、前任者、あるいはさらにその前の担当者が残していったスクリプトを維持・保守しなければいけないシーンもあるでしょう。そしてシナリオ 1 のようにドキュメントも存在せず…。そんな時でも、Kiro の Vide mode があなたの作業をお手伝いします。 要件 今回のシナリオでは、ログ監視の仕様変更に伴い、既存のログ監視スクリプトを調査・改修することになったとします。要件としては既存の ERROR という文字列に加えて、 FATAL も検知対象にするというものです。既存のスクリプトは問題なく動作しているようですが、実は次のような問題点が含まれています。 コメントがほとんどない 未使用の関数・変数がある 不安を煽るコメントがある エラーハンドリングなし 危険なコマンド (rm -rf) が実行される可能性がある ファイルパスがハードコードされている グローバル変数の乱用がある 非効率なループ処理がある パスワードが平文で書かれている 大変恐ろしい状況ですが、作業に取り掛かってみましょう。 Kiro での作業手順 1. 既存スクリプトの解析をリクエストする まずは既存スクリプトの正体を明らかにするため、README.md を作成してもらうことにしました。 bad_example.sh の改修を任されたのですがドキュメントがないのでどういうスクリプトなのかよく分かりません。まずはこのスクリプトの仕様を解析し、 README.md に記録してください。 そうすると早速、先回りして問題点を指摘してくれました。もちろん、このブログのことやスクリプトの問題点については一切情報を与えていません。 出来上がった README.md を見てみると、丁寧に解説された文章ができていることが確認できました。 2. 既存の問題点を精査する さて、さきほどすでに一部が露見した問題点について、改めて精査してもらいます。 問題点が多いスクリプトのようなので、改めてスクリプトをチェックし、問題があると思われる箇所を全てリストアップしてください。 すると、次のように 20 件もの問題点が発見され、README.md に詳細を書き足してくれました。 あらかじめ仕込んでおいた問題点のほぼ全てが指摘されていますが、コメント関連の部分だけは指摘がないようなので、追加でチェックをお願いしてみます。 スクリプトの可読性の観点で、適切なコメントも必要だと思いますがその観点だとどうですか？ その結果、期待通りに問題点が抽出され、さらに対応優先度まで提案してくれました。 3. 既存のスクリプトを改修する もともとは仕様変更の依頼でしたが、問題点を放置しておくわけにもいきません。依頼元に報告した上で、問題点の修正も実施することにします。とはいえあまり長い記事になるのもよくないので、優先度が高い問題だけを修正してもらおうと思います。 まずは優先度：高の問題点を修正してください。 この通り、README.md の項目に従って 5 つの優先度が高い問題点を修正してくれました。問題点が修正できたところで、当初の依頼であった FATAL も検出できるように改修を進めてもらいます。 監視文字列として、FATAL も検出できるように改修してください。 diff で示されている通り、grep コマンドを修正して改修が完了しました。 本来はデグレ試験なども必要になりますが、いったん今回の記事ではここまでとしましょう。 なぜインフラエンジニアに Kiro が向いているのか 二つのシナリオを通じて、Kiro がインフラエンジニアの日常業務にどのように貢献できるかをご覧いただきました。ここで、インフラエンジニアにも向いている理由を一度振り返ってみましょう。 1. ドキュメント化の自動化 インフラエンジニアが作成する Shell スクリプトは「書いた本人しか理解できない」「動いているから触りたくない」という状況に陥りがちです。 Kiro は仕様書ベースでの開発を前提としているため、開発プロセスの中で自然とドキュメントが生成されます。しかも、単なる機能説明だけでなく、セットアップ手順、実行方法、ファイル構成まで含んだ実用的なドキュメントが作成されるため、引き継ぎや保守作業が格段に楽になります。さらに、既存のスクリプトから仕様書を生成することも可能です。 2. ベストプラクティスの適用 インフラエンジニアが作成するスクリプトは、本番環境で長期間稼働することが前提となります。そのため、エラーハンドリング、適切なログ出力、セキュリティ対策、リソースの適切な管理など、多くの考慮事項があります。 しかし、これらすべてを毎回完璧に実装するのは現実的ではありません。Kiro は、こうしたベストプラクティスを自動的に適用したコードを生成してくれるため、「動くけど不安なスクリプト」ではなく、「安心して運用できるスクリプト」を効率的に作成できます。 3. 学習コストの低さ 多くのインフラエンジニアにとって、従来の AI を搭載していない統合開発環境は「アプリケーション開発者のもの」という印象があり、導入に心理的なハードルがありました。また、これらのツールは高機能である反面、設定や操作方法の習得に時間がかかることもあります。 Kiroは VSCode ベースでありながら、主要なインターフェースは自然言語での対話です。「こういうスクリプトが欲しい」「この部分を修正したい」といった要望を日本語で伝えるだけで作業が進むため、新しいツールの操作方法を覚える必要がほとんどありません。 まとめ いかがでしたか？ Kiro 利用開始のハードルは決して高くありませんので、ぜひ試してみてください。日々の Shell スクリプト開発が、驚くほど効率的になるはずです。従来手作業で数時間かかっていた仕様書作成からコード実装までの作業が、Kiro との対話により大幅に短縮され、かつ品質の高いドキュメントも同時に得られます。 また、本ブログではご紹介しませんでしたが、Kiro CLI という直接ターミナルで利用可能なツールも提供しています。こちらもインフラエンジニアにとっては馴染みやすいツールだと思うので、ぜひ こちらのブログ をチェックしてください。 今回の記事は以上です。いよいよ kiroweeeeeeek も折り返しを迎えましたが、今後の記事にもぜひご注目ください。 引き続き X で #kiroweeeeeeek をつけて様々な角度からの投稿をお待ちしています！ 著者 松本 修一 アマゾンウェブサービスジャパン合同会社のソリューションアーキテクトです。普段は製造業のお客様のご支援を中心に活動しています。最近は週末に Zenn でゆる〜い記事を書くことが趣味です。

こんにちは！ AWS でソリューションアーキテクトをしている菅原です。 本ブログは Kiroweeeeeeek ( X: #kiroweeeeeeek ) の第 4 日目です。昨日のブログは吉村さんの「 Kiro を組織で利用するためのセキュリティとガバナンス 」という内容でした。平日だけの予定でしたが、皆様からの人気も高く休日も投稿をすることになっています。 先日、AWS のアジアパシフィックの社員による、社内ハッカソンが行われました。ハッカソンでプロダクトを作るにあたり、Kiro を使ったペアプログラミングを試行しました。この記事では、プレビュー以来 Kiro を使い続けてきた経験と、ハッカソンでの試行を通じて見えてきた、Kiro を活用したペアプログラミングの可能性とそのノウハウを共有します。 AI コーディング時代の新しい課題 AI コーディングツールの登場により、コード生成のスピードは劇的に向上しました。AI のコーディング速度は人間の処理能力を遥かに超え、今や開発のボトルネックは人間の考える時間や品質になっています。 ハッカソンの準備段階で、私たちはこの課題に直面していました。3 日間という限られた時間の中で、時間をかけるべきは独創的なアイデアとその実現方法の考案という、人間にしかできないことです。AI が生成する大量のドキュメントを効率的にレビューし、チーム全体で理解を共有する時間はなるべく短縮する必要がありました。そこで思いついたのが、Kiro の画面を 2 人で見ながら、リアルタイムで議論し、レビューを進めるというアプローチでした。これにより、人間の思考を整理し素早くレビューすることができ、AI が提案した文章やコードを何も見ずに承認するといった人間のサボりによる品質の低下も防ぐことができました。 AWS が提唱する開発方法論「 AI 駆動開発ライフサイクル (AI-DLC) 」も、AI と複数人が一緒に開発やレビューをする「モブエラボレーション」「モブコンストラクション」という方法で人間と AI の調和をとっています。今回は 2 人によるハッカソンのため、AI-DLC とは全く異なるアプローチで開発しましたが、コンセプトを参考にしています。 Tips1: Kiro によるホワイトボーディングの読み取り ハッカソンの初日、私たちはまず会議室に集まり、ホワイトボードを使ってアイデアを整理することから始めました。マーカーを使いながら、システムの全体像や主要な機能について議論を重ねました。この段階では、完璧な図を描くことよりも、思考を自由に展開し、お互いの理解を深めることを優先しました。ホワイトボーディングの最中、技術的な疑問点が浮かんだ際には、その場で Kiro のチャットに質問を投げかけました。 AWS Knowledge MCP Server などのツールを活用することで、AWS の最新のドキュメントや Web を参照しながら、議論を深めることができました。 議論がひと段落したところで、ホワイトボードに書かれた内容をスマートフォンで撮影しました。そして、その写真を Kiro に読み込ませました。Kiro は画像認識機能を持っているため、手書きの図や文字を理解し、テキストとして文字起こしすることができます。これを元に人間がレビューを行い、システムの概要を作成し、後続の Kiro の Spec 機能を活用する際の土台としました。 Kiro にホワイトボードの内容をまとめてもらっている画面 ここで重要なのは、いきなり Spec を生成するのではなく、まずホワイトボードと KIiro による思考の整理をしたことです。ホワイトボードの内容は、議論の流れや思考の断片が混在しており、そのまま Spec にするには整理が必要でした。文字起こしされたテキストを 2 人で確認しながら、「この部分は要件として明確にすべき」「この図は設計フェーズで詳細化する」といった判断を行いました。 Tips2: 仕様駆動開発とペアレビューの相性 Kiro の最大の特徴は「仕様駆動開発」です。今回の開発では、ホワイトボーディングで整理したアイデアを、Kiro の画像認識機能を使って文字起こしし、それをベースに要件定義を作成しました。Kiro は、私たちの自由な発想を構造化された仕様書に変換してくれました。ここからが重要なポイントです。生成された仕様書を 2 人で画面を見ながらレビューすることで、以下のような効果が得られました。 一つ目は、認知負荷の分散です。一人が設計の妥当性を追いながら、もう一人が仕様との適合性をチェックします。このように役割を自然に分担することで、より深いレビューが可能になりました。お互いが同じ部屋にいることにより、承認が適当にならなかったのも良かったポイントです。二つ目は、即座のフィードバックループです。疑問点や改善案をその場で議論し、すぐにKiroに修正を依頼できます。これにより、仕様の精度が飛躍的に向上しました。 ディスプレイを使って議論ををしている AWS のソリューションアーキテクト Tips3: ペアレビューを加速するKiroの機能群 ハッカソンを通じて、ペアレビューに特に有効だったKiroの機能をいくつか発見しました。 Agent Hooks：日英ドキュメント翻訳 ハッカソンでは、最終的に英語でプレゼンテーションを行う必要がありました。Kiro を使えば、日本語で書いた仕様書や設計書を、Agent Hooks を用いて英語に翻訳できます。Kiro の Agent Hooks は、AI 駆動のアクションをトリガーにして事前定義されたエージェントアクションを自動的に実行するツールです。Agent Hooks については詳しくは、 「Kiro の AI エージェントフックで開発ワークフローを自動化する 」をご覧ください。 Agent Hooks により、私たちは、日本語でドキュメント作成をしながら、並行して英語版のドキュメントも自動で手に入れることができました。2 人でレビューする際、「ドキュメントの更新を忘れていないか」という確認作業が不要になり、本質的な設計や実装の議論に集中できました。 Agent Hooksの例：日本語と英語の相互翻訳を行うことができる。 Git 統合：変更履歴の可視化 Kiroは、Visual Studio Code ベースであるため、Git との統合も優れています。ペアレビュー中に、「この変更は誰がいつ行ったのか」「前回のレビューからどこが変わったのか」を即座に確認できました。特に、Spec ファイルの変更履歴を追うことで、要件や設計の変遷を理解しやすくなりました。 MCPツール：外部知識の統合 Model Context Protocol（MCP）は、Kiroの拡張性を支える重要な機能です。私たちは、さまざまな MCP サーバーを設定し、開発の効率を上げていきました。使用した MCP の一部をご紹介します。 AWS Knowledge MCP Server AWS Terraform MCP Server 検索サービス MCP サーバー 社内のドキュメント管理ツールとの統合 MCP サーバー Kiro と MCP について詳しくは「 Kiro と Model Context Protocol (MCP) で開発生産性を解き放つ 」をご覧ください。 Agent Steering：プロジェクト固有のルール適用 Agent Steeringは、プロジェクト全体に適用されるガイドラインやルールを定義する機能です。ハッカソンでは、チームのコーディング規約やアーキテクチャの原則を Steering Rule として設定しました。これにより、Kiroが生成するコードや設計が、常にチームの方針に沿ったものになりました。 グループでのSteering 機能の活用方法は、別のブログで詳しくお伝えする予定です。 Tips4: ペアによるテストとデバッグ 開発の後半では、テストとデバッグのフェーズに入りました。Kiro は実装コードだけでなく、テストコードも自動生成してくれます。しかし、テストの品質を担保するためには、人間によるレビューが欠かせません。今回もペアでの行動をおこなっています。生成されたテストケースを 2 人で画面を見ながらレビューしました。「このパターンのテストが足りないのではないか」「この異常系のテストは必要だ」といった議論を重ね、テストの質を高めていきました。 実際にテストを実行すると、いくつかの失敗が発生しました。ここからがデバッグのフェーズです。エラーログを Kiroに解析させ、2 人で見ながら、問題の原因を特定していきました。デバッグは、従来の開発でも一人で行うと時間がかかる作業でした。しかし、Kiro を使いペアで取り組むことで、問題の切り分けが格段に速くなりました。一人が行き詰まっても、もう一人が別の視点から問題を見ることで、解決の糸口が見つかります。 まとめ: Kiro を使った新しい開発スタイルへ！ ハッカソンを終えて、Kiro を使ったペアプログラミングには、単なる効率化以上の価値があると感じました。それは、認知負荷を下げながら、より深い思考を可能にする開発手法だということです。 AI が生成する大量の情報を一人で処理するのは、認知的に負担が大きいものです。しかし、2人で役割を分担しながらレビューすることで、この負担を軽減できます。さらに、議論を通じて、単独では気づかなかった視点や改善案が生まれます。Kiro の仕様駆動開発は、この手法と非常に相性が良いと言えます。要件、設計、実装という明確なフェーズ分けにより、レビューの焦点が定まります。各フェーズで何を確認すべきかが明確なため、議論が散漫になりません。Agent Hooks、MCP、Steering といった機能は、この開発スタイルを強力にサポートしてくれます。 AI コーディングツールの進化により、開発のボトルネックは「コードを書くこと」から「生成されたものをレビューし、品質を担保すること」へと移行しつつあります。Kiro を使ったペアレビューは、この新しい課題に対する一つの解答だと考えています。 もちろん、すべてのプロジェクトでペアレビューが最適とは限りません。しかし、複雑な要件や、高い品質が求められるプロジェクトでは、試してみる価値があります。Kiro は、単なるコーディングアシスタントではなく、チームでの協働を支援するツールとしても、大きな可能性を秘めています。みなさんもぜひ Kiro を用いたより良い発手法を模索し、 #kiroweeeeeeek に共有してください！ 最後に最終的に 3 日間でできたアプリと、生成した Spec の一部をお見せします！ 実際に作ったサービス。ATM の監視カメラを想定したカメラ入力に、電話をしながら使う人物がいるとアラートを発報する。 実際に作ったサービスのアーキテクチャ Desgin.mdの一部 著者 菅原 太樹 (Taiki Sugawara) アマゾンウェブサービスジャパン合同会社 フィナンシャルサービス技術本部 ソリューションアーキテクト 2024年に新卒で入社した 2 年目 SA。主に保険業界のお客様を担当している。 ハッカソンでは全 154 チームのうち上位 10 位に入賞したものの、1 位を逃して消沈している。 X: @taikis_tech LinkedIn: https://www.linkedin.com/in/taikis/ ハッカソン参加者 伊勢田 氷琴 (Hikoto Iseda) アマゾンウェブサービスジャパン合同会社 広域事業統括本部 テクニカルソリューション部 ソリューションアーキテクト ソリューションアーキテクトとして、普段は幅広い業種・業界のお客様の技術支援に取り組んでいます。 AI/ML を専門領域として活動しております。 LinkedIn: https://www.linkedin.com/in/hikoto-iseda-4634aa250/

2025年9月に、AWS Systems Manager for SAP Configuration Managementを発表しました。これは、AWS Systems Manager for SAPの新機能で、 AWS Well-Architected FrameworkのSAP Lens および AWS for SAP技術ドキュメント に対してSAP HANAデータベース構成を検証できる機能です。この機能により、お客様は潜在的な設定ミスを特定し、AWS上のSAP HANAワークロードの最適なパフォーマンス、セキュリティ、信頼性を確保できます。 SAPアプリケーションは、財務からサプライチェーンまで、企業の中核ビジネスプロセスを支える重要な存在です。AWSはこれらのアプリケーションを実行するための堅牢な基盤を提供していますが、SAP管理者は最適な構成を維持するために、AWS、SAP、およびオペレーティングシステムベンダーからの膨大なドキュメントを確認する必要があります。この検証プロセスは複雑で時間がかかり、多くの場合、深い技術的専門知識が必要です。このプロセスを効率化するために、AWS Systems Manager for SAPは、Configuration Checks機能を提供するようになりました。これは、SAP on AWS固有の構成に焦点を当てた機能で、最小限のセットアップで主要な設定の自動検証を提供します。チェックは論理的にグループ化されてコンテキストを提供し、詳細なドキュメントへの参照が含まれており、管理者がSAP環境を効果的に維持するのに役立ちます。 AWS Systems Manager for SAP Configuration Managementは、自動化された構成検証機能を提供することで、このプロセスを簡素化します。リリース時には、3つの主要な構成チェックを提供します: 1. SAP EC2インスタンスタイプの選択: このSAP HANAアプリケーションに関連付けられているAmazon EC2インスタンスをチェックし、インスタンスタイプがSAPアプリケーションの実行に認定されているか、必要なハードウェア設定が整っているかを評価します。 2. SAP HANA EBSストレージ構成: Amazon EBSストレージ構成とAmazon EC2インスタンス上のSAP HANAファイルシステムのセットアップを、AWS推奨のストレージ構成と照らし合わせてチェックします。 3. SAP HANA Pacemaker構成: 高可用性で構成されたSAP HANAデータベースのPacemakerクラスター構成をチェックします。 各チェックは、個別のルールのセットを通じて、特定の構成領域の包括的な評価を提供します。これらのルールは構成のさまざまな側面を評価し、各ルールはOKAY、ERROR、WARNING、INFO、またはUNKNOWNのステータスを返します。チェックは特定の機能に合わせて調整されており、期待値、参照リンク、または関連する技術ドキュメントを介した修復ガイダンスを提供します。これらのチェックをサポートするために、 SAP HANAストレージ構成 および Pacemaker高可用性セットアップ に関する技術ドキュメントを更新し、追加の明確性を提供し、現在のベストプラクティスに合わせています。 このアプローチにより、お客様は構成関連の問題を防止し、手動検証の労力を削減し、AWSおよびSAP標準への準拠を維持しながら、設定ミスを迅速に特定して解決できます。 はじめに AWS Systems Manager for SAP Configuration Managerを使い始めるには、まず SAP HANAデータベースをSystems Manager for SAPに登録 します。この登録は、ベストプラクティスに対してアプリケーション構成を評価する前に必要です。 開始は簡単です。SAP HANAデータベースをAWS Systems Manager for SAPに登録した後、AWSマネジメントコンソールからAWS Systems Manager → Application Managerに移動します。検索フィールドで、Application sourceとしてSAPを選択すると、登録されたSAP HANAシステムをすばやく見つけることができます。評価したいSAP HANAアプリケーションを選択し、「Actions」ドロップダウンメニューをクリックして「SAP check configuration」を選択します。 構成チェッカーページでは、SAP HANAアプリケーションで利用可能なチェックのリストが表示されます。システムに対して実行する1つまたは複数のチェックを選択できます。「Run check」を選択することで、構成チェックプロセスを開始できます。数分以内に、検証に使用された詳細な参照を含む評価結果が表示されます。設定ミスが検出された場合は、それらを解決する方法に関するガイダンスも受け取ることができ、SAP HANAシステムの最適なパフォーマンスと信頼性を維持することが容易になります。 各構成チェックは、HANAシステムのさまざまな側面を徹底的に評価する複数のサブチェックで構成されています。これらのサブチェックを個別に確認できるため、特定の構成項目の優先順位付けと対処が容易になります。 「Evaluated」ドロップダウンメニューを使用すると、過去30日間の構成チェック結果にアクセスして、構成が時間の経過とともにどのように変化したかを監視できます。この履歴ビューを使用して、修復アクションを検証し、SAP HANAのアップグレードやオペレーティングシステムのパッチなどのシステム変更の影響を評価できます。この機能は、構成状態とシステムの改善の記録を維持するのに役立ちます。 アプリケーションは時間の経過とともにベストプラクティスから逸脱する可能性があるため、構成を定期的に検証することが重要です。AWS Systems Manager Configuration Management for SAPは、シンプルなAPI呼び出しを使用して構成チェックの自動スケジューリングを可能にします。このコマンドを、選択した任意のスケジューラー(cron、AWS Systems Manager State Managerなど)に統合できます: aws ssm-sap start-configuration-checks --application-id <your-application-id> --check-ids <check-id-1> <check-id-2> この新しい機能は、SAP HANAシステムの潜在的な設定ミスを特定し、解決に必要なガイダンスを提供する構成評価のコンパニオンとして機能します。修復は引き続きお客様の管理下にありますが、詳細なインサイトとドキュメント参照により、チームは情報に基づいた構成の決定を行い、時間の経過とともにシステムの最適化を維持できます。 サービス提供と料金 AWS Systems Manager Configuration Management for SAPは、Systems Manager for SAPがサポートされているすべてのリージョンで利用できるようになりました。このサービスは、アプリケーションごとの構成チェック実行あたり0.25ドルの従量課金制で価格設定されており、前払いのコミットメントや最低料金はありません。この透明性のある価格モデルにより、コストを管理しながら、必要に応じて構成チェックを実行できます。 まとめ このブログ投稿では、ベストプラクティスに対してSAP HANA構成を評価するのに役立つ新しい機能であるAWS Systems Manager for SAP Configuration Managerを紹介しました。AWS Systems Manager Application Managerコンソールを通じてConfiguration Managerを使用して、SAP HANAデータベース構成を評価し、詳細なチェック結果を表示し、時間の経過とともに構成の変更を追跡する方法を学びました。この機能は、Systems Managerの既存のSAP運用機能を補完し、AWS上のSAPワークロードを管理、監視、最適化するための包括的なソリューションを提供します。Configuration Managerを使い始めるには、SAPアプリケーションをAWS Systems Manager for SAPに登録し、今日から構成の評価を開始してください。詳細については、 AWS Systems Manager for SAPドキュメント ページをご覧ください。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

この記事は 2025 年 11 月 14 日に公開された “ Know before you go – AWS re:Invent 2025 guide to Well-Architected and Cloud Optimization sessions ” を翻訳したものです。 re:Invent 2025 で Well-Architected とクラウド最適化に関する学習とネットワーキングの時間を最大化する準備はできていますか？ 今年の Well-Architected とクラウド最適化に関するセッションについて、スケジュール計画に役立つ総合ガイドをご用意しました。 これらのセッションでは、チームが戦略的なクラウド構想をリードし、次世代アーキテクチャを設計し、コストを最適化し、AIを活用したシステムを安全に構築するために必要な実践的なガイダンスを提供します。 re:Invent における Well-Architected とクラウド最適化に関する主要テーマ – re:Invent 2025 では、以下のようなテーマが取り上げられる予定です。 AI を活用したアーキテクチャとガバナンス このテーマのセッションでは、AWS が AI テクノロジーを統合して従来のアーキテクチャ設計手法をどのように変革しているかを紹介します。 AI サービスを活用した自動化された Well-Architected レビューから、エージェンティック AI による自己進化システムの実装まで、これらのセッションでは、AI を使用してアーキテクチャの意思決定を自動化し、ガバナンスプロセスを合理化し、企業全体でベストプラクティスをスケールする方法を示します。 セッション : ARC324-R 、 ARC317-R 、 SPS320 、 ARC302-R （セッションの詳細は次のセクションに掲載されています） Well-Architected フレームワークの進化と実装 これらのセッションでは、AWS Well-Architected フレームワークが基本的な枠組みからさらに発展し、最新のアーキテクチャの課題に対応していることを紹介します。 参加者は、IoT セキュリティからバックアップ戦略まで、さまざまな分野でフレームワークの原則を適用する方法を学びながら、企業全体のガバナンスとコンプライアンスに重点を置いた内容を理解できます。 セッション : ARC204 、 SEC337 、 STG313-R 、 ARC323-R （セッションの詳細は次のセクションに掲載されています） コスト最適化と FinOps コスト最適化トラックでは、AI を活用した FinOps ソリューション、特にクラウド財務管理の革新的なアプローチに焦点を当てています。 セッションは、「Frugal Architect GameDay」のようなハンズオンワークショップから、効果的なコストガバナンスモデルの確立に関するチョークトークまで多岐にわたります。 セッション : ARC318-R 、 COP309-R 、 ARC309 、 DEV318 （セッションの詳細は次のセクションに記載されています） 学習スタイルに合わせたセッション形式 今年のカタログには、ブレイクアウト、チョークトーク、ワークショップ、ビルダーセッション、コードトークなど、さまざまな形式の魅力的なコンテンツが揃っています。 ブレイクアウトセッション – 最新情報の入手 これらのプレゼンテーションをお楽しみいただき、最新のソリューションの進化や実践的な活用方法について最新情報を得ることができます。 AWS の専門家とゲストスピーカーが、価値ある知見と実例を共有します。 アイデアからインパクトへ：クラウドのベストプラクティスを用いたアーキテクチャ設計 ARC204 | ブレイクアウトセッション |12 月 1 日、午前 8:30 PST AWS Well-Architected フレームワーク、AWS Cloud Adoption フレームワーク、AWS Cloud Operating Model といった基本的なフレームワークが、どのように発展してきたかをご紹介します。 これらは数千もの組織からのフィードバックや実際の経験から生まれ、構造化されたガイダンスからクラウド環境を最適化するための実践的な知見へと進化しました。 大規模なアーキテクチャ変更と運用上の優秀性の維持を両立しながら、クラウド変革を促進するために実践的な戦略を学びましょう。 生成 AI とエージェンティックアプリケーションをスケーリングするための Well-Architected な基盤の構築 AIM310 | ブレイクアウトセッション | 12 月 1 日、午前 10:00 PST 単なる実証実験を超えて、組織全体のすべての AI アプリケーションをサポートする本番環境対応の基盤を構築しましょう。これにより、実験段階から企業規模の AI 導入への重要な移行に対応できます。 大規模な環境でのモデルアクセスと管理、ツールの探索、メモリと状態の処理、および監視機能に対応しながら、モデルアクセス、オーケストレーションワークフロー、エージェント、ツールを、企業レベルのガバナンス制御と統合した基盤を構築することが可能になります。 ServiceNow と AWS による AI 駆動型エンタープライズアーキテクチャ ARC337-S | ブレイクアウトセッション | 12 月 2 日 午後 3:00 PST 「アーキテクチャ構想を堅牢なクラウド環境として実現する」という重大な課題に直面しています。 ServiceNow の Enterprise Architecture Workspace と AWS Well-Architected Tool の統合が、従来の設計プロセスをどのように変革するかをご覧ください。 エレガントな「シフトレフト」手法を通じて、アーキテクトはエンタープライズモデリングとクラウドのベストプラクティスを効果的に組み合わせた洞察を得られます。 このプレゼンテーションは、AWS パートナーである ServiceNow によってお届けします。 カスタマーサポートにおける AI 革命：予測型サービスシステムの構築 SPS315 | ブレイクアウトセッション | 12 月 3 日、午後 5 時 30 分 PST AWS が生成 AI を使用して、カスタマーサポートをリアクティブなものからプロアクティブなものへと変革する方法をご紹介します。 大規模言語モデルと AI エージェントがどのようにして顧客満足度と業務効率を向上させているかをお伝えします。 スマートなケースルーティング、状況を理解したサポート、問題の早期発見、責任ある AI 活用などのトピックを取り上げます。実際の成果を共有しながら、AI の能力と人間らしさのバランスについても紹介します。 AWS コスト最適化：開発者向けツールとテクニック DEV318   | ブレイクアウトセッション | 12 月 1 日、午後 3 時 PST クラウドアプリケーションの複雑さが増すにつれ、コスト最適化は開発者にとって重要な課題となります。このセッションでは、パフォーマンスやスケーラビリティを損なうことなく、費用を最適化する AWS ネイティブツールとコーディング手法について紹介します。 チョークトーク AWS のスピーカーが冒頭で背景説明を行い、その後ディスカッションの場を設けます。 AWS の専門家や他のお客様と共に質問を交えながらトピックについて深く掘り下げましょう。 エージェンティックシステムのアーキテクチャ設計： AWS AI による自己進化パターン ARC324-R | チョークトーク |12 月 2 日 午後 1 時 30 分 PST AWS Well-Architected の原則に沿った、エージェンティック AI を活用して、自律的に進化するシステムの設計方法を学びましょう。 自律的に適応・修復・最適化しながらもアーキテクチャの整合性を維持する最新パターンを学習しましょう。 Amazon Bedrock Agents による自律監視と自己修復機能の実装、AI 駆動のセキュリティ対策と自動復旧の仕組みの設計、そして信頼性とパフォーマンス基準を保ちながら継続的にワークロードパターンに適応するシステムの構築方法を学習できます。 Well-Architected なエージェンティック AI アプリケーションの構築 ARC317-R/R1 | チョークトーク | 12 月 2 日 午後 3:00 および 12 月 4 日 午後 1:00 PST 生成 AI エージェントの開発においては、セキュリティとコンプライアンスを重視した堅牢なアーキテクチャを採用し、企業の要件に適合した本番環境対応のエージェンティック AI アプリケーションを構築するための実証済みパターンに注力することが重要です。 AWS Well-Architected 生成 AI レンズを活用して、ガードレール、モニタリングシステム、アクセス制御を備えたエージェントアーキテクチャを設計し、規制コンプライアンスを確保しながらプロトタイプから全社規模の展開までスケールできるガバナンスパターンを実装します。 生成 AI を使用してアーキテクチャガイダンスを自動化する ARC315 | チョークトーク | 12 月 1 日 午後 4 時 30 分 PST 時間のかかる手作業のプロセスを、品質と一貫性を維持しながら戦略的な提案、設計原則、ベストプラクティスを大規模に生成できる AI システムへ移行しましょう。 AI によるアーキテクチャパターンの分析を活用して組織固有の設計原則を生成し、効果的な品質管理の仕組みを備えた AI 駆動のガイダンスシステムを実装しましょう。 また、人間によるモニタリングを行い、倫理的な課題に適切に対応しながら、AI を活用したアーキテクチャガイダンスをサポートするナレッジベースを構築しましょう。 エージェンティックなアーキテクチャ設計：プロトタイプから本番稼働可能なシステムへ ARC330-R/R1 | チョークトーク | 12 月 2 日 午後 5 時 30 分 および 12 月 4 日 午後 2 時 30 分 PST エージェンティックなアーキテクティングを通じてセキュリティ、モニタリング、CI/CD を組み込むことで、プロトタイプを本番環境対応のシステムに変換し、実験的な AI システムから本番環境グレードのアーキテクチャへの移行における実践的な課題に焦点を当てます。 AI エージェントを使用して AWS CDK インフラストラクチャとアプリケーションコードを生成および最適化し、自動化されたセキュリティ改善と CI/CD パイプラインの作成を実装し、AWS Well-Architected の原則を維持しながら、AI がインフラストラクチャの複雑さを処理することで、チームがビジネスロジックに集中できるようにします。 AI を活用した FinOps ：エージェントベースのクラウドコスト管理 ARC318-R/R1 | チョークトーク | 12 月 1 日 午後 4:00 および 12 月 3 日 午後 4:00 PST 複雑なマルチアカウント環境で散在するコストデータや最適化プロセスに対して、インテリジェントエージェントがどのように取り組むかを学びましょう。 従来の FinOps アプローチを超え、自律的かつインテリジェントなコスト最適化へと進化します。 Amazon OpenSearch Service によるデータ集約と Amazon Bedrock によるコンテキスト推論を活用して、継続的にコストを最適化しながら測定可能なビジネス成果を提供する、安全でスケーラブルな FinOps ソリューションを設計しましょう。 AWS の生成 AI で Well-Architected レビューを効率化する SPS320 | チョークトーク | 12 月 3 日 午後 4:00 PST Koch Industries が生成 AI を使って AWS Well-Architected レビューの方法を一新した事例をご紹介します。 Amazon Bedrock Knowledge Bases と Model Context Protocol (MCP) を使用して、アーキテクチャ評価を自動化し、ベストプラクティスのレビューを幅広く展開できるようになりました。これにより、ワークロードの最適化にかかる時間が数日から数分へと大幅に短縮されています。 さらに、実績のある変更管理の方法と組織への段階的な導入アプローチにより、より網羅的で一貫性のある、実践的な推奨事項を提供します。 AWS Control Tower を活用したエンタープライズ規模のガバナンスの設計 ARC323-R/R1 | チョークトーク | 12 月 3 日 午前 11:30 および 12 月 4 日 午後 2:00 PST 大規模企業向けの AWS Control Tower を活用した高度なコンプライアンス、セキュリティ、運用管理、先進的なガバナンス戦略を学習しましょう。 重要なトレードオフを理解しながら、AWS Well-Architected フレームワークの 6 つの基本原則に基づいたインフラを構築しましょう。 セキュリティ要件とイノベーションのニーズのバランスを取った効率的なマルチアカウント構造を設計し、集中管理型のガバナンスとセキュリティ制御を維持しながらセルフサービス機能を提供する大規模な自動コンプライアンス検証とポリシー適用の仕組みを構築します。 AWS IoT レンズと AWS セキュリティリファレンスアーキテクチャを使用した IoT ワークロードの保護 SEC337 | チョークトーク | 12 月 3 日 午前 11:30 PST 産業環境における接続性、自動化、効率性、リアルタイムデータ分析は新たな段階に進化しています。 しかし、この接続性の向上は同時に重大なセキュリティ課題ももたらします。 セキュリティ問題への対応を怠ると、脆弱性が露呈し、IoT やクラウドを活用したデジタル変革を進めようとする企業の妨げとなります。 このチョークトークでは、AWS Well-Architected IoT レンズと AWS セキュリティリファレンスアーキテクチャ（SRA）を基に、複雑な OT/IT 環境、IoT デバイス、エッジ、クラウドを保護するための技術、アーキテクチャパターン、ベストプラクティス、そして AWS セキュリティサービスについて詳しく解説します。 効果的なコストガバナンスの確立 COP309-R/R1 | チョークトーク | 12 月 3 日 午後 3:00 および 12 月 4 日 午後 12:30 PST 生成 AI エージェントの開発には、セキュリティとコンプライアンスを確保するための堅牢なアーキテクチャ設計が求められます。 このチョークトークでは、AWS の Well-Architected 生成 AI レンズを活用した、安全で効率的な AI エージェント構築のための実証済みパターンを紹介します。 参加者との対話やホワイトボードを用いた議論を通じて、本番環境に必要なアーキテクチャのガバナンスやベストプラクティスを探ります。 保護機能、監視システム、アクセス制御、持続可能なデプロイ手法を取り入れたエージェントアーキテクチャの設計方法を学びましょう。 拡張性があり、安全で効率的、さらにコスト効果に優れたエージェンティック AI アプリケーションを構築するための実践的な知識が得られます。 モノリスを分解し、Amazon ECS でアプリケーションをモダナイズする CNS346 | チョークトーク | 12 月 2 日 午後 4 時 30 分 PST モノリシックアプリケーションの新機能リリースに数ヶ月もかかり、スケーリングが難しくなるという一般的な課題の解決策を一緒考えましょう。 最初に、サーバー上で動作し共有データベースを使用する実際のアプリケーション事例を見ていきます。 そして Amazon ECS と Well-Architected フレームワークの原則を活用したモダナイゼーションの道筋を皆さんと一緒に設計します。 一般的なアーキテクチャパターン、コンテナ化戦略、CI/CD 自動化、ECS でのブルー/グリーンデプロイ手法などを詳しく探っていきます。 セッション終了後には、モノリシックアプリケーションを拡張性の高いマイクロサービスへ移行するための実践的なロードマップが得られます。 ぜひ皆さんの好奇心を持ち寄り、ライブでのアーキテクチャ設計にご参加ください。 ハンズオンワークショップとビルダーズセッション AWS のスピーカーが課題解決のためのユースケースとツールを紹介します。指示に従ってタスクを実行し、AWS の機能についての理解を深めることができます。 AI を活用した Well-Architected レビュー：自動化されたガバナンスの構築 ARC302-R | ビルダーズセッション | 12 月 1 日 午前 9:00、12 月 2 日 午前 11:30、12 月 3 日 午後 4:00 PST 生成 AI を活用して AWS Well-Architected フレームワークのレビューを自動化するインテリジェントシステムを構築しましょう。 これにより、従来は手作業で行っていたアーキテクチャ評価を、継続的かつインテリジェントなガバナンスプロセスへと変革できます。 Well-Architected の各柱に照らしてアーキテクチャを評価する際に、組織固有の要件も取り入れることができます。 また、アーキテクチャと Infrastructure as Code(IaC) のテンプレートを継続的に分析し、Model Context Protocol サーバーを使用してアーキテクチャのコンテキストに関する AI の理解を深めることも可能です。 これらの取り組みにより、これまで時間を要していたレビュー作業を、一貫性のあるガバナンスを備えたスケーラブルな自動化プロセスへと変革できます。 AI を活用したトラブルシューティング：カオスから Well-Architected へ ARC301-R | ビルダーズセッション | 12 月 1 日 午前 8:30、12 月 2 日 午後 3:00、12 月 3 日 午前 10:00 PST AI を活用したツールを使って複雑な課題に取り組み、アーキテクチャの問題を診断・解決する実践経験を積みましょう。 設計に問題のあるシステムを優れた構成のソリューションへと変換する方法を学びます。 Amazon Q を活用してスケーリングのボトルネックやデータベースの非効率性を解消し、Well-Architected フレームワークの原則を適用して、厳しい状況下でもパフォーマンスとセキュリティを向上させます。 問題をすばやく特定して解決する能力を高めながら、AWS の最適化スキルを習得し、アーキテクチャの問題点が深刻化する前に発見する方法を身につけることができます。 The Frugal Architect GameDay： コスト効率の高いアーキテクチャの構築 ARC309 | ワークショップ | 12 月 1 日、午前 8:00 PST この GameDay では、AWS の複数サービスにおけるコスト効率化に挑戦していただきます。 Frugal Architect の原則を実際のシナリオに当てはめながら、高コストなインフラ構成を効率的で持続可能な構成に変えるスキルを身につけられます。 コンピューティング、ネットワーク、ストレージ、サーバーレス、監視など様々な領域での課題に取り組み、サービス品質を維持しながらクラウドコストを最適化し、収益性を高める方法を学びます。 ゲーム化されたシナリオを通じて、コスト最適化の判断ポイントを楽しみながら素早く養うことができます。 AI による評価と Well-Architected のベストプラクティスを使用して AWS Backup を最適化する STG313-R | ビルダーズセッション | 12 月 2 日 13:30 および 12 月 3 日 8:30 PST AWS Backup Evaluator Solution を活用して AWS バックアップの実装を強化しましょう。このソリューションは複数の情報源からデータを集約し、バックアップ最適化の提案を行う AI エージェントです。 Strands Agents SDK を使用して Well-Architected AWS Backup レンズに基づきバックアップ環境を評価し、バックアップ全体を一元的に可視化して最適化の機会を特定します。 AWS のベストプラクティスに準拠し、バックアップ効率を常に監視する AI エージェントを導入することで、効率性とコスト効果を高めます。 AWS Cloud Support kiosk を尋ねましょう (Venetian) 重要な注意事項： セッションの日時や場所は、セッションの人気度や会場の収容人数に応じてスケジュールを最適化するため、変更される可能性があります。 登録済みのセッションや新たに追加されたアクティビティに関する最新情報については、このブログ記事と re:Invent セッションカタログを定期的にご確認ください。 パートナーとのセッションを含む Well-Architected コンテンツの全体は、 AWS re:Invent カタログ をご覧いただき、関心領域を Well-Architected フレームワークでフィルターしてください。 人気のあるセッションはすぐに満席になるため、早めに席を予約することを忘れずに。ハンズオンのビルダーズセッションやワークショップ用にノートパソコンを持参してください。 今すぐ登録 本ブログはテクニカルアカウントマネージャーの井上が翻訳しました。原文は こちら です。 Anitha Selvan Anitha Selvan は AWS のクラウド最適化組織の Go to Market のリードです。AWS サポート製品における 8 年以上のプロダクトマーケティングと市場投入戦略の経験を活かし、現在は組織のクラウド変革と AI 導入の加速を支援しています。Anitha は製品ローンチと市場投入戦略を専門とし、戦術的な実行力とアーキテクチャのベストプラクティスおよび組織変革管理に関する専門知識を組み合わせて、製品の採用と顧客エンゲージメントを促進しています。 Ryan Dsouza Ryan Dsouza は AWS のクラウド最適化組織のプリンシパルソリューションアーキテクトです。ニューヨーク市を拠点に、AWS の幅広い機能を活用して、より安全でスケーラブルかつ革新的なソリューションの設計、開発、運用を支援し、測定可能なビジネス成果を提供しています。彼は AWS Cloud Adoption フレームワークと Well-Architected フレームワークに準拠して、パフォーマンス、コスト効率、セキュリティ、回復力、運用の優秀性を最適化するソリューションを顧客が構築できるよう、戦略、ガイダンス、ツールの開発に積極的に取り組んでいます。

はじめに SAP HANA データベースを最新のパッチで常に最新の状態に保つことは、セキュリティ、パフォーマンス、信頼性を維持するために非常に重要です。しかし、従来のデータベースパッチ適用では、多くの場合、大幅なダウンタイムが必要となり、ビジネスオペレーションに影響を与えます。以前の AWS ガイダンス では、さまざまな 自動化（英語） アプローチを取り上げましたが、この投稿では、ネイティブ AWS サービスを使用して高可用性 SAP HANA データベースのほぼゼロダウンタイムを実現する新しいソリューションを紹介します。 AWS Systems Manager と AWS CloudFormation を使用して、Red Hat Enterprise Linux (RHEL) と SUSE Linux Enterprise Server (SLES) の両方の環境で SAP HANA データベースパッチ適用を自動化する方法を紹介します。 このアプローチの利点 この AWS ネイティブツールアプローチ を使用することで、重要な運用機能とセキュリティ機能を統合ソリューションに組み込み、SAP HANA データベースのメンテナンスを改善します。AWS Systems Manager は中央コマンドセンターとして機能し、更新プロセス全体を通じてリアルタイムモニタリング、詳細なログ記録、自動化されたヘルスバリデーションを提供します。このソリューションは、運用保証のためのロールバック機能を維持しながら、プライマリノードとセカンダリノード間の更新をインテリジェントに調整します。サードパーティツールの必要性を排除することで、ライセンスコストを削減するだけでなく、暗号化された通信や包括的な監査証跡を含むネイティブ AWS サービス統合の恩恵を受けることができます。単一の AWS Systems Manager コンソールを通じて管理されるこの統合アプローチは、組み込みのセキュリティとコンプライアンス制御を備えたエンタープライズスケールのデータベースメンテナンスを提供します。 前提条件 HA 構成で HANA データベース (HDB) を更新するために このコード を使用する前に、以下の前提条件を満たす必要があります： Amazon EC2 インスタンス上で高可用性モードで実行されている、事前設定済みの SAP HANA 2.0+ データベース環境。このブログでは初期セットアップについては説明しませんが、 AWS Launch Wizard を使用して SAP HANA などの SAP ワークロードのデプロイと設定を自動化することをお勧めします。また、設定に関するサポートが必要な場合は、SAP on AWS の ドキュメント をご活用ください。 SAP HANA データベース EC2 インスタンスが AWS Systems Manager によって管理されていることを確認してください。自動化ソリューションは Systems Manager の機能を活用してシームレスな管理と運用を実現するため、これは不可欠です。 自動化のために中央または共有サービスアカウントを活用している場合（AWS のベストプラクティスとして推奨）、続行する前に適切なクロスアカウント権限が設定されていることを確認してください。詳細については、この リンク を参照してください。 AWS Systems Manager の自動化は、Amazon S3 メディアファイルを EC2 インスタンスの /tmp ディレクトリに同期します。自動化を実行する前に、この一時ディレクトリに十分なストレージスペースがあることを確認してください。必要なスペースの量は、実行する更新のファイルサイズによって異なります。 SAP HANA データベース EC2 インスタンスに、キーと値のペア「Hostname: <hostname>」のタグを追加してください。後のステップでソリューションを実行する際に、このホスト名の値が必要になります。 アーキテクチャ図 アーキテクチャ図（図 1）は、AWS Systems Manager Automation Documents、SAP HANA パッチインストールメディアを含む Amazon S3 バケット、および AWS Secrets Manager に保存された重要なパラメータを使用したソリューションを示しています。SAP HANA ワークロードは、AWS アカウント内の Amazon EC2 インスタンス上で実行されます。 図 1 – HANA DB HA クラスター 実行の準備 SAP HANA SYSTEMDB に、データベース更新を実行するための十分な権限を持つユーザーアカウントを設定します。このユーザーは自動化プロセスで参照されるため、アップグレードを進める前に、アカウントに必要なすべての認可があることを確認することが重要です。SAP HANA データベースユーザー権限を設定する際は、最小権限の原則に従うことを強くお勧めします。詳細については、 更新用の低権限データベースユーザーの作成 を参照してください。 SAP HANA データベースインスタンスが、SAP HANA パッチインストールメディアを含む Amazon S3 バケットにアクセスするために必要な権限を持っていることを確認してください。EC2 インスタンスへの IAM ポリシーの作成とアタッチに関する詳細な手順については、AWS IAM ユーザーガイド の IAM ロールの操作を参照してください。スニペット 1 は、アカウント内の特定の IAM ロールに S3 バケットからファイルをダウンロードするために必要な権限を付与する方法を示すサンプルポリシーです。環境に応じて、バケット名とロール名（黄色でハイライト表示）を必ず変更してください。 {     "Version": "2012-10-17",     "Statement": [         {             "Sid": "AddPerm",             "Effect": "Allow",             "Principal": {                 "AWS": "arn:aws:iam::{account_id}:role/service-role/{ec2_role}"             },             "Action": [                 "s3:GetObject",                 "s3:GetObjectVersion",                 "s3:ListBucket"             ],             "Resource": [                 "arn:aws:s3:::{bucket_name}/*",                 "arn:aws:s3:::{bucket_name}"             ]         }     ] } スニペット 1 – S3 バケットポリシー 3. 自動化は、SAP HANA データベース認証情報を取得するために AWS Secrets Manager に依存しています。AWS Secrets Manager を使用すると、同じ AWS アカウントまたは異なる AWS アカウント間でシークレットを共有できます。この機能により、シークレット管理を単一の場所に集中化できます。詳細については、 AWS アカウント間で AWS Secrets Manager のシークレットを共有する方法 を参照してください。AWS Secrets Manager で必要なシークレット（sapadm ユーザーパスワードと SYSTEM ユーザーパスワード）を作成し、ターゲット AWS アカウントがこれらのシークレットにアクセスするための適切な権限を設定していることを確認してください。 4. 機密情報への安全なクロスアカウントアクセスを可能にするために、このソリューションは AWS KMS 暗号化を使用した AWS Secrets Manager を使用します。暗号化されたシークレットは、すべての参加 AWS アカウントからアクセス可能な KMS キーによって保護されている必要があります。クロスアカウントシークレットアクセスの設定に関する詳細なガイダンスについては、 ドキュメント を参照してください。 コードの実行方法 以下の手順に従って、この GitHub リポジトリ に含まれるコードを使用して、HANA データベースを更新してください。 HANA データベースがある同じアカウントの AWS Secrets Manager に必要なシークレットを作成します。参考として、図 2 に設定方法のサンプルシークレットを示しています。この例は、自動化が正しく機能するために必要な形式とキーと値のペアを示しています。実際の認証情報を使用しながら、シークレットが同様の構造に従っていることを確認してください。 図 2 – DB 認証情報のシークレット例 2. 更新ファイルの保存場所として機能する S3 バケットを確立します。 3. CloudFormation スタック作成ガイド を使用してソリューションをデプロイします。リポジトリの cloudformation フォルダー内にある以下の 2 つのファイルを参照してください： hana_db_patch_ha_rhel – RHEL システムで HA 用に設定されたデータベースに使用します。これにより、はじめにで説明した nZDT コンセプトが実現されます。 hana_db_patch_ha_suse – SUSE システムで HA 用に設定されたデータベースに使用します。これにより、はじめにで説明した nZDT コンセプトが実現されます。 4. Systems Manager > Documents > 「Owned by me」タブを選択 > 「patch」を検索して、該当するドキュメントを開きます： 図 3 – 使用可能な SSM ドキュメント 5. 右上隅の「Execute automation」を選択します： 図 4 – SSM 実行ステップ 6. 必要な入力パラメータを入力します： 図 5 – SSM ドキュメント入力パラメータ 7. 下にスクロールして「Execute」を選択します。 8. 正常に完了すると、図 6 のような完了メッセージが表示されます。 図 6 – SSM 自動化出力 実行フロー 以下に、この自動化によって実行されるすべてのステップとその詳細を示すフローチャートを示します。 フローチャート 1 – SSM 実行シーケンス 「フローチャート 1」に示されているステップは順次実行されます。いずれかのステップが失敗すると、プロセス全体が直ちに停止します。 エラーが発生した場合は、このブログのトラブルシューティングセクションを参照して、続行する前に問題を診断して解決してください。 トラブルシューティング 自動化の問題を監視および診断するために、AWS Systems Manager は EC2 インスタンスと CloudWatch Logs の両方に詳細な実行ログを保持します。これらのログは、自動化の段階的な進行状況をキャプチャします。 自動化ステータスの監視： Systems Manager の自動化のステータスを確認するには： AWS Systems Manager コンソールを開きます。 左側のナビゲーションペインで、Automation を選択します Configure preferences > Executions を選択します Automation executions セクションで自動化ステータスを表示します 実行の詳細の確認： AWS マネジメントコンソールでは、各自動化実行を詳細に調べることができます。以下のことが可能です： 個々の自動化ステップをナビゲートする 各ステップの結果を確認する 自動化プロセス中に発生した障害を特定する ログを使用したトラブルシューティング： 自動化ログにアクセスする方法は 2 つあります： EC2 インスタンスログ パス: /var/lib/amazon/ssm/{instance-id}/document/orchestration/{automation_step_execution_id}/awsrunShellScript/0.awsrunShellScript – EC2 インスタンスからの詳細な実行ログが含まれます パス: /tmp/hana/patch – パッチ手順に使用されるファイルが含まれます パス: /tmp/update – 更新コマンドを実行するための認証情報が含まれます CloudWatch Logs 統合 Systems Manager を設定して、自動化出力を Amazon CloudWatch Logs に送信できます セットアップ手順については、[ Run Command 用の Amazon CloudWatch Logs の設定 ] を参照してください コストに関する考慮事項 この HANA DB パッチ適用ソリューションで使用される AWS Systems Manager Automation は、従量課金制モデルに従います。実行された自動化ステップの数と期間に基づいて課金され、以下を含む寛大な無料利用枠があります： 月あたり 100,000 の自動化ステップ、 月あたり 5,000 秒の自動化実行時間 AWS Organizations を使用している場合、この無料利用枠の使用量は、一括請求ファミリー内のすべてのアカウント間で共有されます。無料利用枠全体を既に使用している他のワークロードを同じアカウントで実行している場合、このツールの実行に関連するコストは 10 米ドル未満に抑えられます。 コスト計算の詳細については、 AWS Systems Manager 料金 を参照してください。 まとめ このブログ投稿で示したように、HANA DB のパッチ更新の自動化は、AWS ネイティブツールを使用して簡単に実現できます。お客様の環境でこれを実装する際は、一部のマイナー OS バージョンによってソリューションが環境ごとに異なる動作をする可能性があるため、実際のビジネス環境に移行する前に、まず非本番アカウントで実行してください。 このソリューションを使用することで、さまざまな SAP ランドスケープと環境全体で更新プロセスがどのように行われるかを標準化し、プロセスの単一の信頼できる情報源を持つことができます。 詳細を知りたい、またはこのソリューションをプロジェクトに拡張する方法についてより深く理解したいとお考えですか？ 詳細については、 sap-on-aws@amazon.com までお問い合わせください。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

本記事は、2025 年 11 月 17 日に公開された Introducing Amazon MWAA Serverless を翻訳したものです。翻訳はクラウドサポートエンジニアの山本が担当しました。 本日、AWS は Amazon Managed Workflows for Apache Airflow (MWAA) Serverless の提供を発表しました。これは MWAA の新しいデプロイメントオプションで、 Apache Airflow 環境の運用オーバーヘッドを排除しながら、サーバーレススケーリングによってコスト最適化を実現します。この新しいサービスは、データエンジニアと DevOps チームがワークフローのオーケストレーションで直面する主な課題、つまり運用スケーラビリティ、コスト最適化、アクセス管理を解決します。 MWAA Serverless では、プロビジョニングされた容量を監視するのではなく、ワークフローロジックに集中できます。Airflow ワークフローをスケジュール実行またはオンデマンド実行で送信でき、実際に各タスクが実行されたコンピュート時間分のみ支払います。サービスが自動的にすべてのインフラストラクチャをスケーリングするため、負荷に関係なくワークフローを効率的に実行できます。 運用の簡素化に加えて、MWAA Serverless は AWS Identity and Access Management (IAM) による細粒度のアクセス制御を実現する 新しいセキュリティモデル を導入しました。各ワークフローに独自の IAM 権限を設定でき、お客様の VPC 上で各タスクを実行できるため、個別の Airflow 環境を作成することなく、正確なセキュリティ制御を実装できます。このアプローチにより、セキュリティ管理のオーバーヘッドを大幅に削減しつつ、セキュリティ体制を強化できます。 この記事では、MWAA Serverless を使用してスケーラブルなワークフロー自動化ソリューションを構築およびデプロイする方法を紹介します。ワークフローの作成とデプロイ、 Amazon CloudWatch を使用した監視の設定、既存の Apache Airflow DAGs (Directed Acyclic Graphs) をサーバーレス形式に変換する実践的な例を紹介します。また、サーバーレスワークフローを管理するためのベストプラクティスを探り、監視とログ記録の実装方法を紹介します。 MWAA Serverless の仕組み MWAA Serverless は、ワークフロー定義を処理し、サービス管理の Airflow 環境で効率的に実行し、ワークフローの需要に基づいてリソースを自動的にスケーリングします。MWAA Serverless は、 Amazon Elastic Container Service (Amazon ECS) エグゼキュータを使用して、各個別のタスクを独自の ECS Fargate コンテナ上で実行します。これは、お客様の VPC またはサービス管理の VPC のいずれかで行われます。それらのコンテナは、Airflow 3 Task API を使用して、割り当てられた Airflow クラスターと通信します。 図 1: Amazon MWAA のアーキテクチャ MWAA Serverless は、タスクの分離によってセキュリティを強化するため、人気のあるオープンソース DAG Factory 形式に基づく宣言型の YAML 構成ファイルを使用します。これらのワークフロー定義を作成するには、2 つの選択肢があります。 Amazon Provider Package の AWS 管理オペレーター を使用するワークフローを YAML に直接記述します AWS が提供する python-to-yaml-dag-converter-mwaa-serverless ライブラリ ( PyPi から入手可能) を使用して、既存の Python ベースの DAG を YAML に変換します この宣言的アプローチには 2 つの主な利点があります。まず、MWAA Serverless がワークフロー定義を YAML から読み取るため、ワークフローコードを実行せずにタスクのスケジューリングを決定できます。次に、MWAA Serverless はタスクが実行されるときにのみ実行権限を付与できるため、ワークフロー全体に広範な権限を必要としません。その結果、タスクの権限範囲が正確に限定され、時間制限される、より安全な環境を実現できます。 MWAA Serverless のサービス検討事項 MWAA Serverless には、サーバーレスとプロビジョニングされた MWAA デプロイメントを選択する際に考慮すべき、以下の制限があります: オペレーターサポート MWAA Serverless は、Amazon Provider Package のオペレーターのみをサポートしています。 カスタムコードやスクリプトを実行するには、以下のような AWS サービスを使用する必要があります。 AWS Lambda は Python コードの実行に使用します。 AWS Batch 、 Amazon ECS 、 Amazon EKS は Bash 操作に使用します。 AWS Glue はサードパーティのデータ接続に使用します。 ユーザーインターフェース MWAA Serverless は Airflow UI を使用せずに動作します。 ワークフローの監視と管理には、 Amazon CloudWatch と AWS CloudTrail との統合を提供しています。 MWAA Serverless の利用 MWAA Serverless を使用するには、以下の前提条件とステップを完了してください。 前提条件 始める前に、次の要件が満たされていることを確認してください: アクセスと権限 AWS アカウント バージョン 2.31.38 以降の AWS Command Line Interface (AWS CLI) をインストール済み IAMロールとポリシーを作成・変更するための適切な権限が必要です。これには以下の IAM 権限が含まれます： airflow-serverless:CreateWorkflow airflow-serverless:DeleteWorkflow airflow-serverless:GetTaskInstance airflow-serverless:GetWorkflowRun airflow-serverless:ListTaskInstances airflow-serverless:ListWorkflowRuns airflow-serverless:ListWorkflows airflow-serverless:StartWorkflowRun airflow-serverless:UpdateWorkflow iam:CreateRole iam:DeleteRole iam:DeleteRolePolicy iam:GetRole iam:PutRolePolicy iam:UpdateAssumeRolePolicy logs:CreateLogGroup logs:CreateLogStream logs:PutLogEvents airflow:GetEnvironment airflow:ListEnvironments s3:DeleteObject s3:GetObject s3:ListBucket s3:PutObject s3:Sync インターネット接続可能な Amazon Virtual Private Cloud (VPC) へのアクセス 必要な AWS サービス – MWAA Serverless に加えて、以下の AWS サービスへのアクセス権が必要です: 既存の Airflow 環境にアクセスするための Amazon MWAA ログを表示するための Amazon CloudWatch DAG と YAML ファイル管理のための Amazon S3 権限制御のための AWS IAM 開発環境 Python 3.12 以降がインストール済み ワークフロー定義を保存するための Amazon Simple Storage Service (S3) バケット YAML ファイル編集用のテキストエディタまたは IDE その他の要件 Apache Airflow の概念に関する基本的な知識 YAML 構文の理解 AWS CLI コマンドの知識 注意 : この記事を通して、お客様自身の値に置き換える必要があるサンプルの値を使用しています: amzn-s3-demo-bucket をお客様の S3 バケット名に置き換えてください 111122223333 をお客様の AWS アカウント番号に置き換えてください us-east-2 をお客様が利用する AWS リージョンに置き換えてください。MWAA Serverless は複数の AWS リージョンで利用可能です。現在の提供状況については、 リージョン別の AWS サービス一覧 を確認してください。 サーバーレスワークフローの初期作成 まず、S3 オブジェクトのリストを取得し、そのリストを同じバケットのファイルに書き込む簡単なワークフローを定義しましょう。 simple_s3_test.yaml という新しいファイルを次の内容で作成してください: simples3test: dag_id: simples3test schedule: 0 0 * * * tasks: list_objects: operator: airflow.providers.amazon.aws.operators.s3.S3ListOperator bucket: 'amzn-s3-demo-bucket' prefix: '' retries: 0 create_object_list: operator: airflow.providers.amazon.aws.operators.s3.S3CreateObjectOperator data: '{{ ti.xcom_pull(task_ids="list_objects", key="return_value") }}' s3_bucket: 'amzn-s3-demo-bucket' s3_key: 'filelist.txt' dependencies: [list_objects] このワークフローを実行するには、上記のバケットを一覧表示し、書き込む権限を持つ実行ロールを作成する必要があります。このロールは、MWAA Serverless から引き受けられる必要もあります。以下の AWS CLI コマンドで、このロールとそれに関連するポリシーを作成します。 aws iam create-role \ --role-name mwaa-serverless-access-role \ --assume-role-policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "airflow-serverless.amazonaws.com" ] }, "Action": "sts:AssumeRole" }, { "Sid": "AllowAirflowServerlessAssumeRole", "Effect": "Allow", "Principal": { "Service": "airflow-serverless.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "${aws:PrincipalAccount}" }, "ArnLike": { "aws:SourceArn": "arn:aws:*:*:${aws:PrincipalAccount}:workflow/*" } } } ] }' aws iam put-role-policy \ --role-name mwaa-serverless-access-role \ --policy-name mwaa-serverless-policy \ --policy-document '{ "Version": "2012-10-17", "Statement": [ { "Sid": "CloudWatchLogsAccess", "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" }, { "Sid": "S3DataAccess", "Effect": "Allow", "Action": [ "s3:ListBucket", "s3:GetObject", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket", "arn:aws:s3:::amzn-s3-demo-bucket/*" ] } ] }' その後、YAML DAG を同じ S3 バケットにコピーし、上記の AWS CLI コマンドの実行結果に含まれる ARN に基づいてワークフローを作成します。 aws s3 cp "simple_s3_test.yaml" \ s3://amzn-s3-demo-bucket/yaml/simple_s3_test.yaml aws mwaa-serverless create-workflow \ --name simple_s3_test \ --definition-s3-location '{ "Bucket": "amzn-s3-demo-bucket", "ObjectKey": "yaml/simple_s3_test.yaml" }' \ --role-arn arn:aws:iam::111122223333:role/mwaa-serverless-access-role \ --region us-east-2 最後のワークフローを作成する AWS CLI コマンドの出力は WorkflowARN の値を返し、この値を使用してワークフローを実行します: aws mwaa-serverless start-workflow-run \ --workflow-arn arn:aws:airflow-serverless:us-east-2:111122223333:workflow/simple_s3_test-abc1234def \ --region us-east-2 出力には RunId の値が返され、その値を使用して実行したばかりのワークフローの実行状況を確認できます。 aws mwaa-serverless get-workflow-run \ --workflow-arn arn:aws:airflow-serverless:us-east-2:111122223333:workflow/simple_s3_test-abc1234def \ --run-id ABC123456789def \ --region us-east-2 YAML を変更する必要がある場合は、S3 にコピーし直して update-workflow コマンドを実行できます。 aws s3 cp "simple_s3_test.yaml" \ s3://amzn-s3-demo-bucket/yaml/simple_s3_test.yaml aws mwaa-serverless update-workflow \ --workflow-arn arn:aws:airflow-serverless:us-east-2:111122223333:workflow/simple_s3_test-abc1234def \ --definition-s3-location '{ "Bucket": "amzn-s3-demo-bucket", "ObjectKey": "yaml/simple_s3_test.yaml" }' \ --role-arn arn:aws:iam::111122223333:role/mwaa-serverless-access-role \ --region us-east-2 Python DAGs を YAML 形式へ変換 AWS は、オープンソースの Airflow DAG プロセッサを使用して Python DAG を YAML DAG ファクトリ形式にシリアル化する変換ツールを公開しています。インストールするには、次のコマンドを実行します。 pip3 install python-to-yaml-dag-converter-mwaa-serverless dag-converter convert source_dag.py --output output_yaml_folder 例えば、次の DAG を作成し、 create_s3_objects.py という名前を付けます: from datetime import datetime from airflow import DAG from airflow.models.param import Param from airflow.providers.amazon.aws.operators.s3 import S3CreateObjectOperator default_args = { 'start_date': datetime(2024, 1, 1), 'retries': 0, } dag = DAG( 'create_s3_objects', default_args=default_args, description='Create multiple S3 objects in a loop', schedule=None ) # Set number of files to create LOOP_COUNT = 3 s3_bucket = 'md-workflows-mwaa-bucket' s3_prefix = 'test-files' # Create multiple S3 objects using loop last_task=None for i in range(1, LOOP_COUNT + 1): create_object = S3CreateObjectOperator( task_id=f'create_object_{i}', s3_bucket=s3_bucket, s3_key=f'{s3_prefix}/{i}.txt', data='{{ ds_nodash }}-{{ ts_nodash | lower }}', replace=True, dag=dag ) if last_task: last_task >> create_object last_task = create_object python-to-yaml-dag-converter-mwaa-serverless をインストールしたら、次のコマンドを実行します。 dag-converter convert "/path_to/create_s3_objects.py" --output "/path_to/yaml/" 出力は次のようになります: YAML validation successful, no errors found YAML written to /path_to/yaml/create_s3_objects.yaml 実行結果の YAML は次のようになります。 create_s3_objects: dag_id: create_s3_objects params: {} default_args: start_date: '2024-01-01' retries: 0 schedule: None tasks: create_object_1: operator: airflow.providers.amazon.aws.operators.s3.S3CreateObjectOperator aws_conn_id: aws_default data: '{{ ds_nodash }}-{{ ts_nodash | lower }}' encrypt: false outlets: [] params: {} priority_weight: 1 replace: true retries: 0 retry_delay: 300.0 retry_exponential_backoff: false s3_bucket: md-workflows-mwaa-bucket s3_key: test-files/1.txt task_id: create_object_1 trigger_rule: all_success wait_for_downstream: false dependencies: [] create_object_2: operator: airflow.providers.amazon.aws.operators.s3.S3CreateObjectOperator aws_conn_id: aws_default data: '{{ ds_nodash }}-{{ ts_nodash | lower }}' encrypt: false outlets: [] params: {} priority_weight: 1 replace: true retries: 0 retry_delay: 300.0 retry_exponential_backoff: false s3_bucket: md-workflows-mwaa-bucket s3_key: test-files/2.txt task_id: create_object_2 trigger_rule: all_success wait_for_downstream: false dependencies: [create_object_1] create_object_3: operator: airflow.providers.amazon.aws.operators.s3.S3CreateObjectOperator aws_conn_id: aws_default data: '{{ ds_nodash }}-{{ ts_nodash | lower }}' encrypt: false outlets: [] params: {} priority_weight: 1 replace: true retries: 0 retry_delay: 300.0 retry_exponential_backoff: false s3_bucket: md-workflows-mwaa-bucket s3_key: test-files/3.txt task_id: create_object_3 trigger_rule: all_success wait_for_downstream: false dependencies: [create_object_2] catchup: false description: Create multiple S3 objects in a loop max_active_runs: 16 max_active_tasks: 16 max_consecutive_failed_dag_runs: 0 DAG の解析後に YAML 変換が行われるため、DAG 内のタスクを作成する for 文が最初に実行され、結果の静的な3つのタスクリストがその依存関係とともに YAML ドキュメントに書き込まれることに注意してください。 MWAA 環境の DAG を MWAA Serverless に移行する プロビジョニングされた MWAA 環境を活用して、ワークフローを開発およびテストした後、サーバーレスで効率的にスケールして実行できます。さらに、MWAA 環境が互換性のある MWAA Serverless オペレーターを使用している場合は、その環境のすべての DAG を一度に変換できます。最初のステップは、MWAA Serverless が MWAA Execution ロールを信頼関係を介して引き受けられるようにすることです。これは MWAA Execution ロールごとに 1 回限りの操作で、IAM コンソールで手動で実行するか、または次の AWS CLI コマンドを使用して実行できます。 MWAA_ENVIRONMENT_NAME="MyAirflowEnvironment" MWAA_REGION=us-east-2 MWAA_EXECUTION_ROLE_ARN=$(aws mwaa get-environment --region $MWAA_REGION --name $MWAA_ENVIRONMENT_NAME --query 'Environment.ExecutionRoleArn' --output text ) MWAA_EXECUTION_ROLE_NAME=$(echo $MWAA_EXECUTION_ROLE_ARN | xargs basename) MWAA_EXECUTION_ROLE_POLICY=$(aws iam get-role --role-name $MWAA_EXECUTION_ROLE_NAME --query 'Role.AssumeRolePolicyDocument' --output json | jq '.Statement[0].Principal.Service += ["airflow-serverless.amazonaws.com"] | .Statement[0].Principal.Service |= unique | .Statement += [{"Sid": "AllowAirflowServerlessAssumeRole", "Effect": "Allow", "Principal": {"Service": "airflow-serverless.amazonaws.com"}, "Action": "sts:AssumeRole", "Condition": {"StringEquals": {"aws:SourceAccount": "${aws:PrincipalAccount}"}, "ArnLike": {"aws:SourceArn": "arn:aws:*:*:${aws:PrincipalAccount}:workflow/*"}}}]') aws iam update-assume-role-policy --role-name $MWAA_EXECUTION_ROLE_NAME --policy-document "$MWAA_EXECUTION_ROLE_POLICY" 正常に変換された各 DAG を順にループし、それぞれにサーバーレスワークフローを作成できます。 S3_BUCKET=$(aws mwaa get-environment --name $MWAA_ENVIRONMENT_NAME --query 'Environment.SourceBucketArn' --output text --region us-east-2 | cut -d':' -f6) for file in /tmp/yaml/*.yaml ; do MWAA_WORKFLOW_NAME=$(basename "$file" .yaml); \ aws s3 cp "$file" s3://$S3_BUCKET/yaml/$MWAA_WORKFLOW_NAME.yaml --region us-east-2 ; \ aws mwaa-serverless create-workflow --name $MWAA_WORKFLOW_NAME \ --definition-s3-location "{\"Bucket\": \"$S3_BUCKET\", \"ObjectKey\": \"yaml/$MWAA_WORKFLOW_NAME.yaml\"}" --role-arn $MWAA_EXECUTION_ROLE_ARN \ --region us-east-2 done 作成したワークフローのリストを表示するには、次のコマンドを実行します。 aws mwaa-serverless list-workflows --region us-east-2 モニタリングと可視化 MWAA サーバーレスのワークフロー実行ステータスは、 GetWorkflowRun API で返されます。結果には、その特定の実行の詳細が含まれます。ワークフロー定義にエラーがある場合、次の例のように RunDetail の ErrorMessage フィールドに返されます。 { "WorkflowVersion": "7bcd36ce4d42f5cf23bfee67a0f816c6", "RunId": "d58cxqdClpTVjeN", "RunType": "SCHEDULE", "RunDetail": { "ModifiedAt": "2025-11-03T08:02:47.625851 + 00:00", "ErrorMessage": "expected token ',', got 'create_test_table'", "TaskInstances": [], "RunState": "FAILED" } } 適切に定義されているが、タスクが失敗したワークフローは、 "ErrorMessage": "Workflow execution failed" を返します: { "WorkflowVersion": "0ad517eb5e33deca45a2514c0569079d", "RunId": "ABC123456789def", "RunType": "SCHEDULE", "RunDetail": { "StartedOn": "2025-11-03T13:12:09.904466 + 00:00", "CompletedOn": "2025-11-03T13:13:57.620605 + 00:00", "ModifiedAt": "2025-11-03T13:16:08.888182 + 00:00", "Duration": 107, "ErrorMessage": "Workflow execution failed", "TaskInstances": [ "ex_5496697b-900d-4008-8d6f-5e43767d6e36_create_bucket_1" ], "RunState": "FAILED" }, } MWAA Serverless タスクログは、CloudWatch ロググループ /aws/mwaa-serverless/<workflow id>/ に保存されます (ここで /<workflow id> は、ワークフローの ARN の一意のワークフロー ID と同じ文字列です)。特定のタスクのログストリームを取得するには、実行されたワークフローのタスクを一覧表示し、各タスクの情報を取得する必要があります。これらの操作を 1 つの CLI コマンドに組み合わせることができます。 aws mwaa-serverless list-task-instances \ --workflow-arn arn:aws:airflow-serverless:us-east-2:111122223333:workflow/simple_s3_test-abc1234def \ --run-id ABC123456789def \ --region us-east-2 \ --query 'TaskInstances[].TaskInstanceId' \ --output text | xargs -n 1 -I {} aws mwaa-serverless get-task-instance \ --workflow-arn arn:aws:airflow-serverless:us-east-2:111122223333:workflow/simple_s3_test-abc1234def \ --run-id ABC123456789def \ --task-instance-id {} \ --region us-east-2 \ --query '{Status: Status, StartedAt: StartedAt, LogStream: LogStream}' 実行結果は、次のようになります: { "Status": "SUCCESS", "StartedAt": "2025-10-28T21:21:31.753447+00:00", "LogStream": "workflow_id=simple_s3_test-abc1234def/run_id=ABC123456789def/task_id=list_objects/attempt=1.log" } { "Status": "FAILED", "StartedAt": "2025-10-28T21:23:13.446256+00:00", "LogStream": "workflow_id=simple_s3_test-abc1234def/run_id=ABC123456789def/task_id=create_object_list/attempt=1.log" } その時点で、CloudWatch の LogStream 出力を使用してワークフローをデバッグします。 Amazon MWAA Serverless コンソール で、ワークフローを表示および管理できます: AWS Lambda、Amazon CloudWatch、 Amazon DynamoDB 、 Amazon EventBridge を使用して詳細なメトリクスと監視ダッシュボードを作成する例については、 この GitHub リポジトリ の例を参照してください。 リソースのクリーンアップ このチュートリアルで作成したすべてのリソースを削除して、継続的な課金を避けるには、次の手順に従ってください。 MWAA Serverless ワークフローを削除する – すべてのワークフローを削除するには、次の AWS CLI コマンドを実行します: aws mwaa-serverless list-workflows --query 'Workflows[*].WorkflowArn' --output text | while read -r workflow ; do aws mwaa-serverless delete-workflow --workflow-arn $workflow done このチュートリアルで作成した IAM ロールとポリシーを削除します: aws iam delete-role-policy --role-name mwaa-serverless-access-role --policy-name mwaa-serverless-policy S3 バケットから YAML ワークフロー定義を削除します: aws s3 rm s3://amzn-s3-demo-bucket/yaml/ --recursive これらのステップを完了したら、AWS マネジメントコンソールで、すべてのリソースが適切に削除されたことを確認してください。CloudWatch Logs はデフォルトで保持されるため、ワークフロー実行の痕跡をすべて削除したい場合は、別途削除する必要があります。 エラーが発生した場合は、必要な権限を持っているか、リソースが存在するかを確認してから削除を試みてください。一部のリソースには、特定の順序で削除する必要がある依存関係がある可能性があります。 結論 この記事では、Apache Airflow ワークフロー管理を簡素化する新しいデプロイメントオプションである Amazon MWAA Serverless について説明しました。YAML 定義を使用してワークフローを作成する方法、既存の Python DAG をサーバーレス形式に変換する方法、ワークフローを監視する方法を実演しました。 MWAA Serverless には以下のような主要な利点があります: プロビジョニングのオーバーヘッドがありません 従量課金モデルです ワークフローの需要に基づいて自動的にスケーリングします 細かい IAM 権限によってセキュリティが強化されています YAML を使用してワークフロー定義が簡素化されています MWAA Serverless の詳細は、 ドキュメント を参照してください。 著者について John は開発者、システムアーキテクト、プロダクトマネージャーとして、スタートアップと大企業の両方で25年以上のソフトウェア経験を持ち、Amazon MWAA を担当する AWS プリンシパルプロダクトマネージャーです。