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 プリンシパルプロダクトマネージャーです。

コンタクトセンター、特にビジネスプロセスアウトソーシング (BPO) 企業では、複数の事業部門 (LOB) を運営しており、それぞれが通話録音の保持に関して異なる規制要件や契約要件を持っています。 業界規制や契約義務を遵守できなければ、罰金、法的紛争、評判を損なう可能性があります。それだけでなく、必要な期間を超えて通話録音を保持することは、不要なストレージコストや潜在的なデータプライバシーの懸念につながる可能性があります。つまり、組織は、運用コストを最適化しながら、コンプライアンス義務を満たす必要があります。 このブログ投稿では、単一の Amazon Connect インスタンス内で、事業部門全体にわたって通話録音に複数の保持ポリシーを適用する方法について解説します。 ソリューション概要 Amazon Connect は、エージェントと顧客間の会話を安全に録音するネイティブな通話録音機能を提供しています。これらの録音は、お客様のインスタンス専用に作成された Amazon S3 バケットに保存されます。 Amazon S3 ライフサイクルを設定することで 、これらの録音のライフサイクルを管理できます。つまり、この設定により、Amazon S3 内の期限切れの録音を自動的に削除するオブジェクトの有効期限ルールを定義できます。 このソリューションでは、Amazon Connect の フロー 内のカスタム 問い合わせ属性 で、各問い合わせの希望する保持期間を指定します。この問い合わせ属性は、 問い合わせレコード の残りの部分と共に Amazon Kinesis にストリーミングされ、 AWS Lambda 関数を呼び出します。Lambda 関数は Amazon S3 の オブジェクトへのタグ付け機能 を使用して、指定された問い合わせ属性値に基づいて録音オブジェクトにタグを付けます。その結果、録音オブジェクトは、バケットに設定された事前定義済みの S3 ライフサイクルルールに従って、それぞれのタグに応じて有効期限が設定されます。 この方法で、データ保持規制への準拠、ストレージコストの最小化、リソース使用率の最適化を実現する、通話録音のカスタマイズされた保持ポリシーを実装できます。 アーキテクチャの全体概要 画像 1 – アーキテクチャ図 詳細な処理の流れ 特定の事業部門 (LOB) に対応した問い合わせが Amazon Connect に到着します 問い合わせ属性の保持期間がフロー内で問い合わせに添付され、LOB に応じて属性値 (短期、長期) が割り当てられます Amazon Kinesis が問い合わせレコードを Amazon S3 にストリーミングします Amazon S3 への転送と合わせて AWS Lambda 関数が呼び出されます。この関数は、問い合わせレコードの保持期間属性 (短期、長期) に基づいて、オブジェクトの Amazon S3 ライフサイクルポリシー (オブジェクトタグ付けを使用) を更新します Amazon S3 内の各録音が、それぞれのライフサイクルポリシーに基づいて期限切れになるよう設定されます このブログでは、以下をデプロイします： 以下を提供する CloudFormation テンプレート： ソリューションのデモンストレーションとテスト用の Amazon Connect フロー Amazon Connect から 問い合わせレコード (CTR) データを運ぶコンポーネントとして機能する Amazon Kinesis Data Streams Amazon S3 ライフサイクルポリシー の設定と、関連する保持期間に応じた新しい録音のタグ付けを担当する 2 つの AWS Lambda 関数 このアーキテクチャは、既存の Amazon Connect インスタンスと、それに対応する Amazon S3 問い合わせ録音バケットに適用できます。 前提条件 このガイドのタスクを実行するために必要な権限があることを確認してください。アクセス権の問題が発生した場合は、AWS アカウントの管理者に連絡して、必要な権限をあなたの役割に合わせて調整してもらってください。 Amazon Connect インスタンスがデプロイされている AWS アカウント内で、大まかには 以下のアクションが利用可能である必要があります： CloudFormation: スタックの起動と削除 Amazon Connect: コンタクトフローの作成と設定、およびインスタンスへのアクセス IAM: IAM ロールの作成と表示 Lambda: 関数の作成、編集、イベントソースの設定、およびデプロイ Kinesis: Kinesis Data Streams の作成 手順 Amazon Connect インスタンスを既に作成済みかどうか、または初めて開始するかどうかに関係なく、このガイドを活用できます。 以下の手順では、AWS アカウントと既存の Amazon Connect インスタンスをお持ちであることを前提としています。新しい Amazon Connect インスタンスを作成するには、 Getting Started with Amazon Connect Workshop の「 Lab 1 」 や、 Amazon Connect Basic Hands-on Workshop (日本語) の 「 2. インスタンスの作成 」の手順に従ってください。AWS アカウントが必要な場合は、 前提条件の手順 に従ってください。 CloudFormation テンプレートの実行 CloudFormation テンプレートは JSON または YAML 形式で記述できる、AWS における Infrastructure as Code (IaC) のコードです。このガイド用の CloudFormation テンプレートは、以下のボタンをクリックしてダウンロードできます。 このテンプレートを使うと、 CloudFormation に以下のようなフォームが表示されます。 Stack name には分かりやすい名前を入力、その他のパラメータは、テンプレートを設定する Amazon Connect インスタンスと録音バケットに合わせて入力します。これらの情報の確認方法は次に説明します。 ステップ 1: 特定 次のステップに必要な情報を確認して書き留めます。 a) BasicQueueId 管理者、またはキューとコンタクトフローを表示するための適切なセキュリティプロファイル設定を持つユーザーとして Amazon Connect コンソールにアクセスします ルーティング から キュー を選択します 表示されるキューのリストから BasicQueue を選択します 追加のキュー情報を表示 をクリックします 表示されるARNの最後に表示されているキュー ID をコピーします キュー ID は後ほど利用するので記録しておきます b) ConnectInstanceID 同じ ARN から、Connect インスタンス ID を推測できます。先ほどの画面の ARN のinstance/ の後の部分に注目します。AWS Management Console の Amazon Connect インスタンスページの概要ページから Connect インスタンス ARN をキャプチャすることもできます これを記録するか、CloudFormation テンプレートパラメータ入力フォームの ConnectInstanceId フィールドに入力します c) KinesisDataStreamName これは事前に入力された「multiple-retention-ctr」という名前のままにするか、任意の名前に変更できます。 d) RecordingBucketName AWS Management Console の Amazon Connect サービスページから対象の Amazon Connect インスタンスを選択します インスタンスエイリアスをクリックします AWS Management Console の Amazon Connect サービスページのナビゲーションからデータストレージのセクションにアクセスします。ここで S3 バケットの名前を確認できます。完全なパスが提供されますが、必要なのはバケット名だけです これを記録するか、CloudFormation テンプレートパラメータ入力フォームを含む他のタブの RecordingBucketName フィールドに入力します ステップ 2: ソリューションのデプロイ 前のステップですべての項目を収集したら、CloudFormation テンプレートのパラメータフォームに入力します。 CloudFormation コンソールで、ダウンロードしたテンプレートを読み込み、フォームに入力します 次へ をクリックして続行します 続いて表示されるスタックオプションの設定ページでは、（変更したい設定がなければ）ページ末尾の確認事項を除く、すべての設定をデフォルトのままにして、 次へ を選択します 確認して作成 ページで最終的な詳細とパラメータを確認します。すべての設定をデフォルト値のままにしておくことができます 送信 をクリックし、作成を開始します これによりテンプレートの起動が開始されます。スタックの下に CREATE_COMPLETE ステータスメッセージが表示されます。さらにイベントタブとリソースタブにアクセスして、テンプレートによって起動されたリソースを確認することもできます ステップ 3: Amazon Connect からのデータストリーミングの有効化 注意 : Amazon Connect は CTR データを単一の Kinesis Stream にのみ送信することをサポートしています。 既に CTR データを Kinesis Stream に送信している場合は、TagS3Object Lambda 関数内のイベントトリガー設定を更新して、既存の Kinesis Stream にストリーミングレコードが到着したときに呼び出されるようにすることができます。これにより、テンプレートで指定した「multiple-retention-ctr」という名前のストリームを使用しないことができます。そのように設定することで、Lambda 関数は既存のストリームの別のコンシューマーとなり、Kinesis ストリームに依存する既存のワークロードを中断することなく動作します。この後、使用状況の検証セクションに直接進んでください。 インスタンスから CTR ストリーミングを設定していない場合は、このセクションに沿って設定を続行してください。 Amazon Connect インスタンスは、CTR データを「multiple-retention-ctr」Kinesis Data Stream に送信するように設定する必要があります。これは、AWS Management Console の Amazon Connect インスタンス設定画面の「データストリーミング」セクションにアクセスすることで実現できます。 このストリーミング動作を発生させるために、フローやキューレベルでの追加設定は必要ありません。これはインスタンスレベルの設定です。 AWS Management Console の Amazon Connect サービスページのナビゲーションからデータストリーミングのセクションにアクセスします。データストリーミングが有効になっているかどうかを確認してください チェックボックスを選択して有効にし、適切な Kinesis Stream を選択します 保存 をクリックします フロー (すでに変更済みですので、この解説は説明目的です。追加の操作は不要です) 以下の画像は、コンタクトのコンタクト属性の割り当てを示しています（以下の例では、オプション 1 を押した発信者には短期保持が割り当てられます） Lambda のコード 保持値に応じて有効期限を 30 日または 90 日に設定する Lambda 関数の一部 このコードは ‘retention’ 属性の値を抽出し、キー ‘retention’ と ‘retentionvalue’ から取得した値を持つタグを作成し、’PutObjectTagging’ API を使用してタグを Amazon S3 オブジェクトに適用します。 ここまでの手順で、ソリューションは使用準備が整いました。フローの実装において必要な箇所でコンタクト属性 retention を設定することで、適用できるようになります。 動作確認 デプロイメントが確認でき、各コンポーネントを理解したので、通話をテストすることができます。 ステップ 1:「Configure multiple retention policies」フローに電話番号を割り当てる このステップでは、CloudFormation テンプレートによってデプロイされた Contact Flow にテスト用の電話番号を関連付けます。 管理者として、またはキューとコンタクトフローの表示および電話番号の設定に適切なセキュリティプロファイル設定を持つユーザーとして Amazon Connect コンソールに移動します サイドバーセクションのチャネル下にある電話番号に移動します テストに使いたい電話番号を選択します。利用可能な電話番号がない場合は、電話番号の取得ボタンから進めてください 作成された Configure multiple retention policies から始まる名前のフローを選択します 保存をクリックして変更します ステップ 2: 電話番号に架電する さて試してみましょう。発信したら、 1 または 2 を押して保持期間の長さを設定できます。このシナリオでは、電話をかけた後、 1 を押して、保持期間ポリシーを短く設定します。保持期間ポリシーの選択の後、問い合わせは Amazon Connect 内の BasicQueue に送られます。 紐づけた電話番号にダイヤルし、希望する保持期間のオプションを選択します 問い合わせコントロールパネル (CCP) またはエージェントワークスペースから、着信した問い合わせに数秒間応答します 通話を切断します ステップ 3: Amazon S3 に保存された録音のオブジェクトタグを確認 問い合わせを切断したら、Amazon S3 オブジェクトを確認して、期待通りのタグが表示されていることを確認しましょう。タグが反映されるまで数分かかる場合があることにご注意ください。 録音が保存されている S3 バケットに移動し、オブジェクトツリーを辿って最新の録音を特定します Amazon S3 内から録音ファイルを選択します。プロパティタブ内を下にスクロールすると、retention タグが表示され、その値はテスト問い合わせ中に選択されたオプション（および設定された問い合わせ属性）に応じて「long」または「short」のいずれかを確認できます これでテストの成功が確認できました。問い合わせ属性が正しく設定され、CTR レコードが Lambda 関数にストリーミングされ、問い合わせの録音が適切にタグ付けされました。設定された S3 ライフサイクルポリシーにより、ユーザーの介入なしに適切なタイミングで録音が削除されます。S3 ライフサイクルポリシーの詳細については、 こちら をクリックしてください。 注：実際のユースケースでは、 IVR を介して録音保持ポリシーを選択する必要はありません。 各フローのコンタクト属性の設定 ブロックを使用して、バックグラウンドで適切な問い合わせ属性を自動的に設定するようにコンタクトフローデザイナーで構成できます。 クリーンアップ CloudFormation テンプレートのデプロイメントをロールバックするには、2つの手順があります。これにより、このガイドで作成されたリソースをクリーンアップできます。 ステップ 1: CloudFormation スタックの削除 このブログの中でデプロイした CloudFormation テンプレートに移動し、スタックを削除します。このステップで、IAM、Lambda、および Kinesis Data Streams リソースを正常に削除できます。唯一の例外は、サンプルのフローで、これについては次のステップで対処します。 ステップ 2: デモンストレーション用の Amazon Connect フローをアーカイブする 偶発的なコンタクトセンターの中断リスクを最小限に抑えるため、CloudFormation でコンタクトフローを削除することはできません。これを削除するには、適切なセキュリティプロファイルを持つユーザーで Amazon Connect インスタンスにアクセスし、フローをアーカイブします。 前のステップで Kinesis Stream が削除されると、Amazon Connect インスタンスのデータストリーミング設定から該当の Kinesis Stream の割り当てが自動的に解除されます。 コンタクトフローの保存に関連する料金はないため、アーカイブしても削除による残存コストは発生しません。 これらの手順で、前述の活動に関わる（通話録音を除く）すべてのリソースがクリーンアップされます。 まとめ 単一の Amazon Connect インスタンス内に複数の通話コンタクト録音保持ポリシーを実装することは、重要なビジネス上の利益をもたらします。Amazon Connect と他の AWS サービスを一緒に活用することで、組織はコンプライアンスとコスト効率性のバランスを実現できます。 このアプローチで運用を合理化し、データプライバシーを確保し、進化するビジネス要件に適応する柔軟性を提供できます。結果として、コストを最適化し、規制コンプライアンスを維持する、シームレスでカスタマイズされたソリューションが、単一のスケーラブルなプラットフォーム内で実現できます。 より詳しく知るには Amazon Connect を初めてお使いですか？ Amazon Connect ユーザーガイドの開始方法 をご覧ください 最新の Amazon Connect 機能について詳しく知りたいですか？ Amazon Connect Enablement YouTube チャンネル でオンデマンドウェビナー、ハウツー、デモをご覧ください Amazon Connect のハンズオンワークショップをお試しになりたいですか？厳選された Amazon Connect ワークショップ をご利用ください 今後の Amazon Connect イベントについて知りたいですか？ カスタマーエクスペリエンスワークショップ & イベント をご確認いただき、今後のイベントにご登録ください 筆者紹介 Mo Miah Mo Miah は Amazon Connect を専門とするシニアソリューションアーキテクトです。コンタクトセンターテクノロジーの分野で 19 年以上の経験を持っています。イギリスのロンドンを拠点とし、Amazon Connect の強力な AI/ML 機能を使用してお客様がビジネス成果を達成できるよう支援することを楽しんでいます。仕事以外では、アクティブに過ごすことを楽しんでおり、2 人の幼い娘がいて忙しい日々を送っています。 Jack Tilson Jack は、様々な AWS テクノロジーを活用して公共部門のお客様と協働するソリューションアーキテクトです。特に、優れたクラウドサービスによるセキュリティ、レジリエンス、市民体験に関心を持っています。戦略的なクラウド変革の経験を持つ彼は、旅行、写真、音楽の熱心なファンでもあります。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

本投稿は、2025年 10 月 6 日に公開、11 月 3 日に更新された Your Ultimate Guide to Cloud Financial Management sessions at re:Invent 2025: Know Before You Go を翻訳したものです。 Cloud Financial Management (CFM) の学習とネットワーキングの時間を re:Invent 2025 で最大限に活用する準備はできていますか？例年通り、今年の CFM セッションを最大限に活用し、スケジュールを計画するための包括的なガイドを作成しました。今年のカタログには、ブレイクアウト、チョークトーク、ワークショップ、ビルダーズセッション、コードトークなど、さまざまな形式のコンテンツがエキサイティングに組み合わされています。 最新情報のキャッチアップ (ブレイクアウトセッション) COP203: What’s New with AWS Cost Management 12 月 3 日（水）| 10:30 – 11:30 PST Mandalay Bay | Level 3 South | South Seas E 特別ゲスト： Corey Quinn （ Duckbill ）と Matt Cowsert （ FinOps Foundation ） COP202: What’s New with AWS Cost Optimization 12 月 4 日（木）| 14:30 – 15:30 PST MGM | Level 3 | Chairman’s 360 特別ゲスト： Delta Airlines から Bonnie Firnstahl エキスパートや仲間と学ぶ (チョークトーク) COP301: Applying AI for FinOps and FinOps for AI 12 月 1 日 (月) | 午後 2:30 – 3:30 PST Wynn | Convention Promenade | La Tache 2 12 月 3 日 (水) | 午前 8:30 – 9:30 PST Wynn | Convention Promenade | Montrachet 1 COP309: Establishing effective cost governance 12 月 3 日 (水) | 午後 3:00 – 4:00 PST Wynn | Convention Promenade | Latour 5 12 月 4 日 (木) | 午後 12:30 – 1:30 PST Wynn | Convention Promenade | Lafite 1 COP201: Estimating workload costs using AWS Pricing Calculator 12 月 1 日 (月) | 午後 5:30 – 6:30 PST Wynn | Convention Promenade | La Tache 2 COP338:Optimizing resources with AWS Compute Optimizer   12 月 3 日 (水) | 午後 4:30 – 5:30 PST MGM | Level 3 | Premier 309 COP339: Developing a cost allocation strategy 12 月 3 日 (水) | 午前 11:30 – 午後 12:30 PST Wynn | Convention Promenade | Lafite 1 HMC319: Achieve multicloud FinOps visibility 12 月 1 日 (月) | 午後 1:00 – 2:00 PST MGM | Level 1 | Boulevard 167 12 月 2 日 (火) | 午後 5:30 – 6:30 PST Caesars Forum | Level 1 | Summit 231 特別ゲスト： FinOps Foundation から J.R. Storment ハンズオンで学ぶ (ワークショップ、Builder セッション、Code トーク) ワークショップ: Exploring Multi-tenant Cost Allocation for Container Workloads 12 月 4 日木曜日 | 12:00 PM – 2:00 PM PST MGM | Level 3 | Premier 318 *ノートPCが必要です ビルダーセッション: COP306: Developing Unit Cost Metrics with Cloud Intelligence Dashboards 12 月 1 日月曜日 | 5:30 PM – 6:30 PM PST Mandalay Bay | Lower Level North | Islander H 12 月 2 日火曜日 | 11:30 AM – 12:30 PM PST Mandalay Bay | Level 2 South | Oceanside C *ノートPCが必要です コードトーク COP401: Advanced analytics with AWS Cost and Usage Reports 12 月 1 日月曜日 | 8:30 AM – 9:30 AM PST MGM | Chairman’s 356 12 月 2 日火曜日 | 2:30 PM – 3:30 PM PST Wynn | Convention Promenade | Margaux 1 コードトーク COP419: Advanced multi-cloud cost reporting with FOCUS 12 月 1 日月曜日 | 4:00 PM – 5:00 PM PST MGM | Level 3 | Chairman’s 370 12 月 2 日火曜日 | 2:30 PM – 3:30 PM PST MGM | Level 3 | Chairman’s 370 ワークショップ ARC309: The Frugal Architect GameDay 12 月 1 日月曜日 | 8:00 AM – 10:00 AM PST MGM | Level 3 | Premier 318 FinOps エキスパートや AWS プロダクトリーダーとの交流 FinOps Foundation は re:Invent 2025 で複数のアクティビティを開催するという伝統を継続します。12 月 2 日火曜日、Venetian Hotel 内の RockHouse レストランで開催される 1 日の学習とネットワーキングにご参加ください。 基調講演のウォッチパーティーから始まり、ネットワーキングランチを挟んで、午後のコンテンツとピアコネクトイベントで締めくくられます。 これは、ファンデーションと AWS CFM チームの両方からエキスパートやプロダクトリーダーと直接交流できる機会です。 参加を希望される方は こちら からお申し込みください。 計画のTips: 早めに登録してください – セッションには定員があります 会場間の移動のため、セッション間に余裕を持たせてください セッションレベルを考慮して計画を立ててください – セッション ID で判断できます。例えば、COP202 は 200 レベルのセッション、COP419 は 400 レベルのセッションです。 推奨事項 – 注目すべき主要テーマ すべてのセッションは、最大限の価値を提供できるように慎重に選定され、設計されています。ぜひ、あなたの興味や技術的な専門性に合ったセッションを選択してください。以下に、私からのおすすめをご紹介します： COP202 と COP203 を通じて、新しい CFM 製品のリリース情報を把握しましょう COP339 でコスト配分戦略を深く掘り下げ、COP410 でコンテナ固有のインサイトを学びましょう COP401 と COP419 を通じて、高度なコスト分析とマルチクラウドの可視化戦略・戦術を学びましょう AI とコスト管理の交差点を探求する COP301 をお見逃しなく 重要な注意事項 : 投稿に記載されているセッションの日時と場所は、セッションの人気度と会場の収容人数に基づいてスケジュールを最適化し続けているため、変更される可能性があります。登録済みのセッションや新規追加されたアクティビティに関する最新情報については、このブログ投稿と re:Invent セッションカタログを定期的にご確認ください。 人気のセッションはすぐに満席になりますので、早めに席の予約をお願いします。re:Invent 2025 でお会いできることを楽しみにしています！ Bowen Wang Bowenは、AWS請求およびコスト管理サービスのプリンシパルプロダクトマーケティングマネージャーです。彼女は、財務およびビジネスリーダーがクラウドの価値とクラウド財務管理を最適化する方法をより良く理解できるよう支援することに注力しています。以前のキャリアでは、テクノロジースタートアップの中国市場参入を支援していました。 本記事の翻訳はスペシャリストソリューションアーキテクト 加藤が担当しました。

本記事は 2025 年 11 月 17 日に公開された Jonathan Vogel と Dan Kiuna による “Never lose your way: Introducing checkpointing in Kiro” を翻訳したものです。 開発者なら誰もが経験したことがあるでしょう。AI コーディングアシスタントと一緒に作業していて、機能開発が順調に進んでいる。エージェントが一連の変更を行い、ファイルを更新し、コードをリファクタリングし、新しい機能を追加する。そして突然、何かがうまくいかなくなる。エージェントが要件を誤解したのかもしれない。あなたのアーキテクチャに合わない前提を置いたのかもしれない。あるいは、単に別のアプローチを試したくなったのかもしれない。 課題はコードの変更を元に戻すことだけではありません。会話のコンテキストを失うことが問題なのです。ファイルを元に戻すことはできても、AI との対話のどこにいたのかを再構築しようとすることになります。フローが途切れ、軌道に戻るには時間と精神的なエネルギーが必要になります。 恐れることなく実験できたらどうでしょうか？ AI アシスタントに大胆なリファクタリングに取り組ませても、計画通りに進まなければ即座に巻き戻せることがわかっていたらどうでしょうか？それが、チェックポイント機能が AI 支援開発にもたらす確信です。 チェックポイント機能とは？ チェックポイント機能は、開発セッション中の任意の時点まで Kiro の変更を巻き戻す機能を提供します。 Kiro がコードベースを変更すると、チャット履歴に自動的にチェックポイントマーカーが作成されます。ビデオゲームのオートセーブポイントのようなものだと考えてください。物事がうまくいかず、想定以上のダメージを受けた場合、以前のチェックポイントに戻って別のアプローチを試すことができます。 各チェックポイントは、そのセッション中に Kiro が行った特定の変更を記録します。 ワンクリックで、エージェントがそのチェックポイント以降に行ったファイルの変更を元に戻すことができ、その復元ポイントまでの会話履歴は保持されます。コンテキストを保ち、不要な変更を元に戻し、構築作業に戻ることができます。 重要: チェックポイント機能は、現在のセッション中に Kiro が行った変更のみを元に戻します。 コードベース全体を保存するわけではなく、この特定のセッションで AI エージェントが変更したファイルのみを復元できます。 注意: チェックポイントを復元すると、Kiro の変更だけでなく、Kiro が触れたファイルの 完全な状態 が元に戻ります。チェックポイント後にあなたや他のツールがそれらの同じファイルに編集を加えた場合、それらの編集も失われます。Kiro で構築しながら手動でコードを編集したり、他のシステムがファイルを変更したりしている場合は、必ずバージョン管理を使用してください。 チェックポイント機能が重要な理由 AI 支援開発は強力ですが、完璧ではありません。大規模言語モデルは本質的に確率論的です。正しい判断をすることもあれば、そうでないこともあります。重要なのは、開発者であるあなたにプロセスのコントロールを与えることです。 チェックポイント機能がなければ、AI が生成するすべての変更にはリスクが伴います。何かがうまくいかなかった場合のクリーンアップを心配して、Kiro に複雑なリファクタリングに取り組ませることをためらうかもしれません。各変更をレビューするのに、自分でコードを書くよりも多くの時間を費やすかもしれません。進捗を失うことへの恐れが、実際にあなたの作業を遅くする可能性があります。 チェックポイント機能はその状況を変えます。Kiro により大きな挑戦をさせる自信を与えます。別のアーキテクチャアプローチを試したいですか？やってみましょう。うまくいかなければ、開始地点からワンクリックで戻れます。新しいライブラリを試したいですか？問題ありません。必要なときにチェックポイントがあります。 仕組み Kiro のチェックポイント機能は、必要になるまで見えないように設計されています。チェックポイントを作成したり、手動で管理したりする必要はありません。Kiro がそれを処理します。 Kiro と作業すると、チャットインターフェースにチェックポイントラインが自動的に表示されます。タスクを開始する前にチェックポイントが作成されます。これらの視覚的なマーカーにより、開発セッションの構造を一目で簡単に確認できます。 元に戻したいときは、任意のチェックポイントラインの「復元」ボタンをクリックするだけです。Kiro はすべてを巻き戻します。エージェントが行ったすべてのファイル変更と会話履歴を元に戻し、その正確な瞬間に戻します。メッセージを入力したがまだ送信していなかった場合、それはチャットウィンドウにあり、編集または送信する準備ができています。開発セッションのタイムトラベルのようなものです。コードの状態だけでなく、どこにいて何を考えていたかの完全なコンテキストを取り戻すことができます。 チェックポイント機能と仕様駆動開発 チェックポイント機能は、Kiro の仕様駆動開発ワークフローと自然に連携します。仕様を進めているとき、特定の要件を実装するために異なるアプローチを試したいことがあるかもしれません。チェックポイント機能は、その探索をリスクフリーにします。また、チェックポイントを使用して、仕様の主要なマイルストーンの完了をマークすることもできます。認証システムの実装が完了しましたか？それがチェックポイントです。データレイヤーが完成しましたか？これもまたチェックポイントです。これらのマーカーは、進捗の明確なマップを提供し、変更を加える必要がある場合に以前の段階を簡単に戻れるようにします。 実際のシナリオ チェックポイント機能が輝くいくつかのシナリオを見てみましょう。 安全な実験 : 特定のリファクタリングがコードのパフォーマンスを向上させるかどうか気になっています。Kiro に変更を加えさせ、ベンチマークを実行します。結果が期待通りでなければ、チェックポイントに戻ります。問題ありません。リスクなしに実験できる能力は非常に解放感があります。 反復的な改善 : 適切なソリューションを見つける前に、いくつかのバリエーションを試す必要がある場合があります。チェックポイント機能を使えば、迅速に反復作業が可能です。手法を試行し、評価し、必要なら元に戻して再挑戦できます。各反復は前回の教訓を基に構築されますが、失敗した試行の残骸でコードベースが散らかることはありません。 異なる実装の探索 : 新しい API エンドポイントを構築していて、REST と GraphQL のどちらを使用するか確信が持てません。まず Kiro に REST として実装するよう依頼します。コードをレビューし、テストし、感触を確かめます。しっくりこない？チェックポイントに戻り、代わりに GraphQL を試すよう Kiro に依頼します。同じ会話、異なるアプローチ、手動クリーンアップはゼロです。 誤解からの回復 : Kiro に「ユーザーサービスに認証を追加して」と依頼します。Kiro は OAuth2 を実装しますが、実際には単純な API キーが必要でした。数十のファイル変更を手動で元に戻す代わりに、Kiro が開始する前のチェックポイントに戻り、要件を明確にします。Kiro は今度は正しいアプローチで再度試みます。 AI 支援開発における信頼の構築 チェックポイント機能の真の力は、変更を元に戻す能力だけではありません。それは、異なる働き方をする自信を与えることです。 チェックポイント機能があれば、AI 支援開発をトランザクションではなく会話のように扱うことができます。アイデアを探求し、仮説をテストし、間違っていることのコストを心配することなく迅速に反復できます。セーフティネットがあることがわかっているので、Kiro により複雑なタスクを処理させることができます。 この考え方の変化は微細ながら重要です。Kiro のあらゆる動作を細かく制御する代わりに、構築しようとしているものとその理由という大局に集中できます。「これが失敗したら」という不安に精神を消耗する代わりに、「これが成功したら」という可能性にエネルギーを注げるのです。 チェックポイント機能とバージョン管理 明確にしておきましょう: チェックポイント機能はバージョン管理の代替ではありません。開発ワークフローの一部として、Git (または好みのバージョン管理システム) を引き続き使用する必要があります。バージョン管理を長期的なプロジェクト履歴とコラボレーションツールと考え、チェックポイント機能を短期的な実験と反復ツールと考えてください。 チェックポイント機能は、Kiro とアイデアを探求し、迅速に反復しているアクティブな開発セッション中に輝きます。満足のいくアプローチに落ち着いたら、通常どおりバージョン管理にコミットします。2 つのツールは異なる目的を果たし、一緒に使うのが最適です。 自分で試してみましょう チェックポイント機能は現在 Kiro で利用可能です。何も設定したり、作業方法を変更したりする必要はありません。Kiro との会話を開始し、いくつかの変更を加えると、チェックポイントラインが表示されます。元に戻す必要があるときは、それらがあなたを待っています。 私たちは、AI 支援開発のコントロールを減らすのではなく、強化するために Kiro を構築しました。チェックポイント機能は、そのビジョンの中核をなす部分です。それは、AI を開発プロセスの真のパートナーにすることです。恐れることなく探求し、実験し、反復する自由を与えるパートナーです。 自信を持ってコーディングする準備はできましたか？ Kiro をダウンロード して、チェックポイント機能が AI との作業方法をどのように変えるかを確認してください。 チェックポイント機能について質問がありますか、または使用方法を共有したいですか？ Discord コミュニティ で会話に参加するか、 X 、 LinkedIn 、 Bluesky でフォローしてください。

こんにちは。ソリューションアーキテクトの吉村です。 本ブログは Kiroweeeeeek (X: #kiroweeeeeeek ) の第 3 日目です。昨日のブログは菅原さんの「 Amazon Q Developer の IDE プラグインから Kiro に乗り換える準備 」という内容でした。 本ブログでは、Kiro を組織で利用するにあたって気になるセキュリティとガバナンス機能についてご紹介します。Kiro の一般提供に関しての総合的な情報は「 Kiro が一般提供開始: IDE とターミナルでチームと共に開発 」をご確認ください。 Kiro の組織利用を開始 Kiro では、一般提供開始に伴い AWS IAM Identity Center を用いた認証方式を利用できる、 Kiro for enterprise の提供を開始しました。IAM Identity Center を利用することで、プレビュー時の個別にクレジットカードを登録する方法とは違い、AWS に組織として請求を 1 本化し、請求を可視化することが可能です。 マネジメントコンソールからアクセスできる Kiro コンソールを利用することで、以下のようなことが行えます。 リージョン管理 ：IAM Identity Center インスタンスを管理するリージョンとは別に、Kiro プロファイルを作成するリージョンをマネジメントコンソールで選択することができます。サポートリージョンについては後述します。 サブスクリプション管理 ：Kiro コンソールを利用して、IAM Identity Center で管理しているユーザーに対するサブスクリプションの作成・管理・設定を行うことができます。 グループ管理 ：グループは IAM Identity Center で管理しているユーザーの集合です。グループに対して Kiro をサブスクライブすると、グループに所属するユーザー全てに対してワンアクションで個別のサブスクリプションを開始することが出来、サブスクリプションの管理を簡素化することができます。 Kiro コンソールからサブスクリプションが開始された、IAM Identity Center ユーザーは、「Sign in with your organization identity」から IDE にログイン、もしくはコマンドラインで kiro-cli login コマンドを利用して IAM Identity Center の認証情報を用いて Kiro CLI にログインし、Kiro の利用を開始することができます。 IDE のログイン Kiro CLI のログイン 詳細については、「 Concepts – IDE – Docs – Kiro 」をご確認ください。 ここまで、IAM Identity Center を利用した Kiro for enterprise について説明しました。ここからは、Kiro for enterprise で気になるセキュリティとガバナンスに焦点を当てていきます。 Kiro プロファイル Kiro for enterprise を利用する場合、IAM Identity Center インスタンスの作成されたリージョンとは別に、Kiro プロファイルを作成するリージョンを選択します。現在（2025 年 11 月 21 日）では、バージニア北部とフランクフルトリージョンをご選択いただけます。Kiro による推論の実行、データの保存は Kiro プロファイルを作成したリージョンにて行われます。 IAM Identity Center インスタンスのリージョンと、Kiro プロファイルのリージョンは異なっていても問題ありません。例えば、IAM Identity Center は東京リージョンを利用しつつ、Kiro プロファイルをバージニア北部リージョンで作成いただくことも可能です。そのため、既に IAM Identity Center をご利用中のお客様も、すぐに Kiro for enterprise を開始いただけます。 Kiro プロファイルとサポートリージョンの詳細は「 Supported regions – IDE – Docs – Kiro 」をご確認ください。 プライバシーとセキュリティ このセクションでは、テレメトリやユーザーによって入力されるデータ、Kiro が生成するコンテンツ等の取り扱いについて概説します。本セクションの内容は、記事執筆当時 (2025 年 11月 21 日) の情報に基づいており、最新の情報は「 Data protection – IDE – Docs – Kiro 」よりご確認ください。 データの保存と処理 Kiro の Free Tier ユーザーと個人サブスクライバー（Google, GitHub, AWS Builder ID でログイン）の場合、プロンプトや Kiro が生成する返答などのコンテンツは、バージニア北部リージョンに保存されます。Kiro for enterprise ユーザーの場合、Kiro プロファイルが作成されたリージョンにコンテンツが保存されます。 Kiro は Amazon Bedrock を利用しています。クロスリージョン推論を利用して、高需要時にトラフィックを複数のリージョン分散し、パフォーマンスと信頼性を向上させます。そのため、推論時にクロスリージョン推論がサポートされているリージョンでデータが処理される可能性があります。ただし、データが保存されるリージョンについて影響はありません。 データの暗号化 Kiro では、データの転送中、保存時にそのデータを暗号化します。データの転送中は、TLS 1.2 以上の接続を使用して通信が保護されます。また、データの保存時は、AWS 所有の AWS Key Management Service (KMS) 暗号化キーによってデータは暗号化されます。Kiro for enterprise をご利用のお客様は、KMS のお客様管理キーを作成して利用するオプションもございます。この暗号化キーは対称鍵のみサポートしております。 サービス改善 Kiro の Free Tier ユーザーと個人サブスクライバー（Google, GitHub, AWS Builder ID でログイン）の場合、デフォルトで、特定のコンテンツやテレメトリをサービス改善のために使用する場合があります。Kiro への質問、提供されるその他の入力、Kiro が生成する応答やコードなどのコンテンツを、サービス改善のために使用する可能性があります。また、使用状況データ、エラー、レイテンシー、クラッシュレポート、その他のメトリクスといったテレメトリをサービスの改善のために収集します。これらのデータ共有をオプトアウトすることができ、お客様のコンテンツをサービスの改善を使用されないように設定することが可能です。 Kiro for enterprise をご利用のお客様は、AWS によってテレメトリとコンテンツ収集から自動的にオプトアウトされ、サービスの改善に利用されません。ユーザーアクティビティレポートのテレメトリ収集設定は、Kiro コンソールで管理者によって制御され、ユーザーが直接設定、修正することはできません。 コードリファレンス Kiro は、一部オープンソースプロジェクトから学習を行っています。時折 Kiro が提案するコードが、公開されたコードに似ている場合があります。コードリファレンスログを使用することで、公開されているコードに似たコード推奨事項への参照を表示することができます。コードリファレンスは設定から ON/OFF を切り替えることができます。 Kiro for enterprise の管理者は、すべてのユーザーに対してリファレンス付きのコード提案を受け取らないようにオプトアウトすることができます。この設定は管理者によって制御され、ユーザーが直接設定、修正することはできません。 コードリファレンスの詳細は「 Code references – IDE – Docs – Kiro 」をご確認ください。また、コードリファレンスに伴う補償については、 サービス規約の 50.10 をご確認ください。 利用状況と統制 利用状況の確認 Kiro コンソールのセッティングにて、Kiro usage dashboard を有効化することができます。 この設定を有効にすることで、Tier ごとの総サブスクリプション数、アクティブなサブスクリプション数、保留中のサブスクリプション数、アクティブなユーザー数、クレジットの消費量を Kiro コンソールのダッシュボードで可視化できます。 Kiro のダッシュボードとメトリクスの詳細は「 Viewing Kiro usage on the dashboard – CLI – Docs – Kiro 」をご確認ください。 Overage と MCP の統制 Kiro では、月のクレジット制限を超えて Kiro を利用可能にする Overage（超過料金）がサポートされています。Kiro の月の制限に達した場合、Overage が有効化されていると、0.04 USD/クレジットで制限を超えて Kiro の機能を引き続き利用することができます。デフォルトで Overage は無効化されています。 Kiro for enterprise をご利用の場合、管理者は Kiro コンソールを利用して、Kiro プロファイルに対して Overage 機能をオプトインすることができます。また、MCP（Model Context Protocol）の利用可否もこちらの設定画面で ON/OFF を切り替えることが可能です。 ネットワーク設定 ファイアウォールとプロキシ 組織のネットワークセキュリティによって、ファイアウォールやプロキシ経由で Kiro へ接続を行う必要が生じる場合があります。このような場合に、ホワイトリストに登録していただく必要のあるエンドポイントを以下の表にまとめます。 URL 目的 <idc-directory-id-or-alias>.awsapps.com 認証 oidc.<sso-region>.amazonaws.com 認証 *.sso.<sso-region>.amazonaws.com 認証 *.sso-portal.<sso-region>.amazonaws.com 認証 *.aws.dev 認証 *.awsstatic.com 認証 *.console.aws.a2z.com 認証 *.sso.amazonaws.com 認証 https://aws-toolkit-language-servers.amazonaws.com/* Kiro, 言語処理 https://aws-language-servers.us-east-1.amazonaws.com/* Kiro, 言語処理 https://client-telemetry.us-east-1.amazonaws.com Kiro, テレメトリ cognito-identity.us-east-1.amazonaws.com Kiro, テレメトリ ここで、 idc-directory-id-or-alias は、IAM Identity Center のディレクトリ ID もしくはエイリアス、 sso-region は、IAM Identity Center インスタンスが作成されているリージョンに読み替えます。 詳細は「 Configuring a firewall, proxy server, or data perimeter for Kiro – IDE – Docs – Kiro 」をご確認ください。 プライベートネットワークアクセス Kiro では、インターフェース型 VPC エンドポイントを提供しているため、PrivateLink を利用して Kiro へプライベート接続できます。マネジメントコンソールや AWS CLI を利用して、以下のサービス名で VPC エンドポイントを作成することができます。 com.amazonaws.us-east-1.q com.amazonaws.eu-central-1.q com.amazonaws.us-east-1.codewhisperer これにより、インターネット経由でデータを送受信できないような制約下でも、プライベートネットワークを介して、Kiro をご利用頂くことが可能です。 詳細は「 Kiro and interface endpoints (AWS PrivateLink) – IDE – Docs – Kiro 」をご確認ください。 まとめ このブログでは、Kiro を組織で利用するために利用可能な Kiro for enterprise とそれを取り巻くセキュリティとガバナンスに関する内容について触れてきました。皆様の組織全体で Kiro を利用して、新しいものを生み出すための一助になれば幸いです！ 引き続き X で #kiroweeeeeeek をつけて様々な角度からの投稿をお待ちしています！ 著者 Hiroaki Yoshimura AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。Go や TypeScript などの静的型付け言語が好きです。

本ブログは三遠ネオフェニックス様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。バスケ大好き AWS ソリューションアーキテクトの鈴木です。 休日は推しのチーム（ニューヨークの NBA チームが好きです）の直近の負け試合を何度も見て、敗因の仮説を考えてはそれを裏付けるデータを探すことに奔走しています。最近のバスケットボールに関するデータは多種多様でとても興味深いです。単純な 2 点、3 点シュートの成功率に留まらず、どれだけ難しいシュートを決め切ったか、逆にどれだけ難しいシュートを打たせたか、などかなり多くの定量的指標が収集され試合の分析に役立っています。 しかし、多くの指標が取られれば取られるほど扱うデータ量が大きくなり、分析が複雑化してしまうこともまた事実です。私のような個人の趣味で扱っている人間でも大変だと感じるので、さらに多くのデータを扱っているプロのアナリストの皆さんはもっと苦労しているのではないでしょうか？ 三遠ネオフェニックス 様は、 AWS Step Functions と Amazon Bedrock を組み合わせることで、膨大なデータから客観的かつ網羅的な分析を生成するシステムを構築されました。生成 AI が自動的に重要な指標を抽出してレポートを生成することで、新たな戦術的インサイトを発見できるようになりました。 お客様の状況と検証に至る経緯 三遠ネオフェニックス様は、B リーグに所属し、豊橋市をホームタウンに、三遠地域（東三河・遠州）をホームエリアに活動するプロバスケットボールクラブです。チームのアナリストは、対戦相手の分析や自チームのパフォーマンス評価のため、膨大な試合データを処理し、コーチ陣に向けたスカウティングレポートを作成する重要な役割を担っています。 しかし、以下のような課題に直面していました。 Bリーグ全体でのビッグデータ化への対応：Bリーグ発足から 10 年が経過する中で、シーズンごとに蓄積されるデータ量が年々増加すると同時に、取得できるデータの種類も拡張され、人力で全データを確認・解釈することが困難に 分析の属人化：アナリストの経験や視点に依存する部分が大きく、重要な情報を見逃すリスク 過密スケジュールでのレポート作成が困難：試合スケジュールが過密な中、毎回の詳細なレポート提供が大きな負担に そこで、AWS Step Functions と Amazon Bedrock を中心としたサーバーレスアーキテクチャを採用し、AI を用いて分析からスカウティングレポート作成までを自動化する仕組みを開発しました。 お客様が開発された生成 AI を活用した AI Analyst 機能 三遠ネオフェニックス様が開発された AI Analyst 機能の全体像は以下の画像が示すようになっています。まず、Synergy Sports Technology 社の提供するバスケットボール専用の分析ツール「 Synergy 」からスタッツデータをAPIで取得します。そのデータを三遠ネオフェニックス様のローカル環境の機械学習プログラムで処理し、AWS 上で構成されたサーバーレスアーキテクチャで分析、レポート作成を行い、その出力結果を Slack に通知する仕組みを構築されています。 図1. AI アナリスト機能の全体図 AWS Step Functions での処理は、図1 が示すとおり、3 つのステップで構成されています。 ステップ 1 ：主要な分析切り口の抽出 このステップではローカル環境の機械学習プログラムから出力されたスタッツごとの重要度のデータを Amazon S3 に配置し、その後 Step Functions から Amazon Bedrock を呼び出して、分析の切り口を 3 つ抽出しています。スタッツごとの重要度のデータは対戦相手ごとに動的に変わるため、アナリストごとの分析の属人化がなく客観的に分析の切り口を選定できることが工夫点となっています。 ステップ 2 ：各切り口で生成AIを活用した深掘り分析 このステップではステップ 1 で作成した切り口を元に、3 つの切り口での深掘り分析を Amazon Bedrock を用いて行っています。各切り口ではその切り口に関連する詳細なスタッツデータを Amazon S3 から取得し、そのデータを元に Amazon Bedrock で深掘り分析を行っています。このように3つの切り口に分けることで、まとめて分析するのに比べて、切り口ごとに扱うデータ量が絞られ、回答精度の向上を図っています。 ステップ 3 ：生成 AI を活用した各分析のサマリ生成 最後のステップではステップ 2 までの深掘り分析結果をまとめてサマリを生成します。サマリには Amazon Bedrock を活用しており、各切り口の分析結果をわかりやすい形式でまとめています。レポートには分析の根拠となるような定量的な数値も示すことで、データに基づいた報告を実現しています。生成されたレポートは、 AWS Lambda を用いて Slack にレポートとして送信されます。 Slack に通知されるレポートの例が図 2 のようになっています。 レポート内では次の対戦相手に対しての主要なプラン、その分析の根拠、主要なプレイタイプなどを定量的な数値と共にレポートしています。このレポートによって対戦相手の分析を行うことができ、次戦のチーム戦略立案に役立っています。 図 2. 図2.Slackに通知されるレポートの例 導入効果 AI Analyst 機能を導入した結果、以下の効果が得られました。 膨大なデータ全体の活用：生成 AI の活用により、人間では扱うのが難しい幅広いデータを元にした分析が可能に AI による属人化の脱却： AI が機械学習の結果から 3 つの重要な指標を抽出し、それを元にレポートを作成するために分析の観点の属人化から脱却し、客観的な分析が可能に 新たな気づきとアイデアの創出：新たな観点やアイデアを提示してくれるため、まるでもう一人のアナリストがそばにいて、新しい発見をもたらしてくれるような価値を実感できた 機械学習結果の即時解釈が可能に：生成 AI が機械学習の結果を自動で要約・深掘りすることで、人では難しかった複雑な結果の理解が容易になり、実務レベルで活用できるようになった 従来までのスポーツアナリティクスは、アナリストの経験や独自のフレームワークに基づく分析が中心であり、扱えるデータ量や観点に限界がありました。 これに対して今回のシステムは、生成 AI を用いて膨大なデータを高速かつ客観的に分析し、レポート作成までを自動化できる点 で非常に特徴的な取り組みとなっています。 さらに、生成 AI を活用することで、これまで難しかった機械学習結果の解釈が実務レベルで可能となり、プロスポーツの現場における生成 AI の実用性を明確に示すことができました。 まとめ 今回は、三遠ネオフェニックス様が開発されたAI Analyst 機能をご紹介いたしました。本検証を通じて、お客様から以下のコメントを頂いております。 今後は、プロンプトの更なる最適化、他のデータソースとの連携、機械学習モデルの精度向上など、継続的な改善を予定されています。また、今シーズンの成果を踏まえ、より高度な分析機能の追加も検討されています。 本事例は、データ量の増大に悩むスポーツチームだけでなく、大量のデータからインサイトを抽出する必要がある様々な業界の皆様にとって、参考になるのではないでしょうか。AWS の生成 AI サービスを活用した業務効率化にご興味をお持ちの方は、ぜひお気軽にご相談ください。 三遠ネオフェニックス：代表取締役社長 岡村 秀一郎様（右から 2 番目）、ゼネラルマネージャー 北郷 謙二郎様（右端）、ビデオアナリスト 木村 和希様（中央） Amazon Web Services Japan : アカウントマネージャー 木下 美智子（左から 2 番目）、ソリューションアーキテクト 山澤 良介（左端） 著者について

AWS re:Invent まであと数週間、私のチームはカンファレンスのコンテンツの準備を全力で進めています。私が行う「 CMP346 : Supercharge AI/ML on Apple Silicon with EC2 Mac」、「 CMP344 : Speed up Apple application builds with CI/CD on EC2 Mac」、「 DEV416 : Develop your AI Agents and MCP Tools in Swift」の 3 つの講演のいずれかで皆さんにお会いできるのを楽しみにしています。 11 月 10 日週、 AWSは 3 人の新しい AWS ヒーローを発表しました。 AWS ヒーロープログラム は、知識を共有したいという熱意によってコミュニティ内に真の影響をもたらしている、活気に満ちた世界中の AWS エキスパートグループを表彰するプログラムです。Dimple、Rola、Vivek、コミュニティへようこそ。 また、 イスラエル、テルアビブでの GenAi Loft も始まりました。 AWS GenAI Loft は、スタートアップや開発者にコラボレーションスペースと没入型の体験を提供します。Loft のコンテンツは、スタートアップ、エンタープライズ、公共部門など、地域のさまざまなお客様のニーズに対応するようにカスタマイズされており、開発者、投資家、業界エキスパートが一堂に会します。 テルアビブの Loft は、11 月 19 日 (水) まで開催されています。この地域にお住まいならば、 セッション、ワークショップ、ハッカソンのリストを今すぐご覧ください。 11 月 10 日週は、サーバーレス開発者の皆さんにとってすばらしいニュースが盛りだくさんの 1 週間でした。これらのニュースから始めましょう。 11 月 10 日週のリリース 私が 11 月 17 日週に注目したリリースをご紹介します。 AWS Lambda が Rust を正式にサポート 、 AWS Lambda が Java 25 をサポート 、 AWS Lambda が Swift 向けの実験的なランタイムインターフェイスクライアントを追加 – Lambda サービスチームは大忙しだったと思います! Rust プログラミング言語のサポートが一般提供されました。ランタイムインターフェイスクライアントは何年も前から存在していましたが、今回ようやくバージョン 1.0.0 に移行しました。私の同僚である Julian と Darko が、 Lambda 関数に Rust を使用するメリットを紹介するブログ記事を書きました 。Java 25 にも、Java で記述される Lambda 関数をより効率的にするための変更点があります。私の同僚である Lefteris が、 これらのメリットを説明するブログ記事 を書きました。 AWS Lambda が SQS イベントソースマッピングのためのプロビジョンドモードを発表 – このモードは、イベントポーリングリソースをプロビジョニングすることで、スループットを最適化し、トラフィックの急増に対処するというメリットを提供します。 Amazon EventBridge が強化されたビジュアルルールビルダーを導入 – Amazon EventBridge の強化されたビジュアルルールビルダーは、直感的なインターフェイス、包括的なイベントカタログ、 EventBridge Schema Registry との統合を通じてイベント駆動型アプリケーションの開発を簡素化します。 AWS サービスリファレンス情報が SDK オペレーションからアクションへのマッピングのサポートを開始 – 私に言わせれば、このニュースはサーバーレスニュース以外での今週最大のニュースです。サービスリファレンス情報に、AWS サービスでサポートされているオペレーションと、所定のオペレーションを呼び出すために必要な IAM 許可が含まれるようになりました。これは、「特定の AWS サービスオペレーションを呼び出したいが、どの IAM 許可が必要なのか」といった質問の回答を得るために役立ちます。 サービスリファレンス情報の取得は、シンプルな JSON ベースの API を使用することで自動化できます 。 AWS Network Load Balancer (NLB) がパススルーモードでの QUIC プロトコルのサポートを開始 – このサポートにより、QUIC 接続 ID を使用してセッションスティッキネスを維持する超低レイテンシーのトラフィック転送が可能になります。この機能は、最小限のハンドシェイクと接続レジリエンスを通じて、モバイルファーストアプリケーションのアプリケーションレイテンシーを 25～30% 削減します。NLB はパススルーモードで動作し、TLS 証明書とエンドツーエンドの暗号化に対するお客様の制御能力を維持しながら、QUIC トラフィックをターゲットに直接転送します。 ブログ記事で詳細をご覧ください 。 Application Load Balancer (ALB) が JWT 検証によるクライアント認証情報フローをサポート – このニュースも、API 開発者にとって重要なニュースです。このサポートにより、セキュアな M2M (マシンツーマシン) 通信と S2S (サービスツーサービス) 通信のデプロイが簡素化されます。これは、JWT を検証する機能を ALB に提供することで、アーキテクチャ面の複雑性を軽減し、セキュリティ実装を簡素化します。 AWS KMS が エドワーズ曲線デジタル署名アルゴリズム (EdDSA) のサポートを開始 – NIST P-256 と同等の 128 ビットセキュリティを提供するこの機能は、より高速な署名パフォーマンスを備え、サイズがコンパクトになっています (64 バイトの署名、32 バイトのパブリックキー)。Ed25519 は、小規模サイズのキーと署名を必要とする IoT デバイスやブロックチェーンアプリケーションに最適です。 Amazon DCV が Amazon EC2 Mac インスタンスのサポートを開始 – このサポートは、4K 解像度と 60 FPS パフォーマンスによる高性能リモートデスクトップアクセスを実現します。Windows、Linux、macOS、またはウェブクライアントから接続でき、タイムゾーンリダイレクトや音声出力などの特徴量を備えています。 Amazon Linux 2023 バージョン 2025110 のリリース – Mountpoint for Amazon S3 、 Swift 6.2.1 ツールチェーン 、および Node.js 24 向けのパッケージが含まれるようになりました。Amazon Linux 2023 仮想マシンやコンテナでの Swift のインストールが、 sudo dnf install-y swiftlang と同じくらい簡単になりました。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 Amazon Elastic Kubernetes Service gets independent affirmation of its zero operator access design – Amazon EKS はゼロオペレーターアクセス体制を提供します。AWS の従業員はお客様のコンテンツにアクセスできません。この体制は、 AWS Nitro System ベースのインスタンス、制限された管理 API、エンドツーエンドの暗号化の組み合わせによって実現されます。NCC グループによる独立評価により、これらのセキュリティ対策の有効性が確認されました。 Make your web apps hands-free with Amazon Nova Sonic – Amazon Bedrock からの基盤モデルである Amazon Nova Sonic は、アプリケーションのために自然で低レイテンシーの双方向スピーチ会話を作成する機能を提供します。この機能は、音声や埋め込みインテリジェンスを通じてアプリケーションと連携する能力をユーザーに提供することで、新たなインタラクションパターンを可能にし、使いやすさを向上させます。このブログ記事では、リファレンスアプリである Smart Todo アプリのデモを紹介し、タスク管理用のハンズフリーエクスペリエンスを提供するために音声をどのように統合できるかを説明しています。 AWS X-Ray SDKs & Daemon migration to OpenTelemetry – AWS X-Ray は、アプリケーショントレーシングのためのプライマリ計装標準として、OpenTelemetry に移行しています。OpenTelemetry ベースの計装ソリューションは、アプリケーションからのトレースの生成と、それらの AWS X-Ray への送信に推奨されます。X-Ray の既存のコンソールエクスペリエンスと機能性も引き続き完全にサポートされ、今回の移行によって変更されることはありません。 Powering the world’s largest events: How Amazon CloudFront delivers at scale – 2025 年 11 月 1 日、Amazon CloudFront は大規模なゲーム配信ワークロードで 1 秒あたり 268 テラバイトの記録的なピークを達成しました。これは、ライブスポーツを HD で約 4,500 万人の視聴者に同時配信するために十分な帯域幅です。このマイルストーンは、世界中 440 以上の都市にある 750 以上のエッジロケーションと、100 以上の ISP 内にある 1,140 以上の埋め込み PoP を活用する CloudFront の巨大な規模を実証するもので、最新世代は以前のバージョンの 3 倍のパフォーマンスを実現しています。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Builder Loft – エキスパートセッションから学び、ハンズオンワークショップに参加して、AI や新興テクノロジーを検証するとともに、他のビルダーとのコラボレーションを通じてアイデアを加速させることができる、米国サンフランシスコのコミュニティテクノロジースペースです。 開催予定のセッション を閲覧して、関心のあるイベントにぜひご参加ください。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。 コンゴ民主共和国のキンシャサ で 11 月 22 日に開催される今年最後の Community Day では、私がオープニング基調講演を行います。次回の Community Day は、2026 年 4 月に ルーマニアのティミショアラ で開催される予定です。 Call for Papers (CFP) 募集が始まっています 。 AWS Skills Center Seattle 4 周年記念イベント – 11 月 20 日に開催される、基調講演、専門家パネル、採用担当者によるインサイト、抽選会、仮想参加オプションなどが盛りだくさんの無料公開イベントです。 AWS Builder Center に参加して、AWS コミュニティのビルダーを学び、構築し、交流しましょう。こちらで 近日開催予定の対面イベント 、 開発者に焦点を当てたイベント 、 スタートアップ向けのイベント をご覧ください。 11 月 17 日週のニュースは以上です。11 月 24 日週にお届けする次回の Weekly Roundup もお楽しみに! – seb この記事は、Weekly Roundup シリーズの一部です。AWS からの興味深いニュースやお知らせを簡単にまとめた記事を毎週ご紹介します! 原文は こちら です。

2025 年 11 月 14 日、 Amazon Simple Queue Service (Amazon SQS) の イベントソースマッピング (ESM) を使用した AWS Lambda のプロビジョニングモードの一般提供についてお知らせいたします。これは、お客様が専用のポーリングリソースを設定して、イベント駆動型アプリケーションのスループットを最適化するために使用できる新特徴量です。3 倍速いスケーリングと、16 倍の同時実行数を実現するこの新機能を使用すると、より低いレイテンシーでイベントを処理し、突然のトラフィックの急増をより効果的に処理して、イベント処理リソースを正確に制御できます。 現代のアプリケーションでは、サービスがイベントやメッセージを通じて通信するイベント駆動型アーキテクチャへの依存度が高まっています。Amazon SQS は Lambda 関数のイベントソースとして一般的に使用されるため、開発者は疎結合でスケーラブルなアプリケーションを構築できます。SQS ESM はキューのポーリングと関数呼び出しを自動的に処理しますが、パフォーマンス要件が厳しいお客様からは、急増するトラフィックパターンに対処し、低い処理レイテンシーを維持するために、ポーリング動作をより細かく制御したいというご要望をいただいていました。 SQS ESM のプロビジョニングモードは、イベントポーラーを導入することでこうしたニーズに応えます。イベントポーラーとは、予想されるトラフィックパターンを処理できる専用リソースです。これらのイベントポーラーは、1 分あたりの同時実行回数につき最大 1,000 件まで自動でスケールアップできます。つまり、以前と比較してイベントトラフィックの急増への対応を 3 倍以上高速化し、最大 20,000 回の同時実行を可能にします。これにより、Lambda 関数を使用して数百万のイベントを処理する処理能力が 16 倍に向上しました。この拡張されたスケーリング動作により、トラフィックが急増しているときでも、お客様は予測可能な低レイテンシーを維持できます。 金融サービス会社からゲーム会社まで、さまざまな業界の企業が AWS Lambda と Amazon SQS を併用して、ミッションクリティカルなアプリケーションのリアルタイムイベントを処理しています。大規模なオンラインゲームプラットフォームや金融機関を含むこれらの組織では、特に使用量がピークの時期には、イベント駆動型のワークロードに対して 1 秒未満の処理時間を一貫して維持する必要があります。SQS ESM のプロビジョニングモードは、コスト管理を維持しながら厳しいパフォーマンス要件を満たすために使用できる機能です。 制御とパフォーマンスの強化 プロビジョニングモードでは、SQS ESM のイベントポーラーの最小数と最大数の両方を設定できます。各イベントポーラーは、Lambda 関数を呼び出す前にキューのポーリング、イベントのバッチ処理、フィルタリングを処理するコンピューティングユニットを表します。各イベントポーラーは、1 秒あたり最大 1 MB/秒のスループット、最大 10 回の同時呼び出し、または 1 秒あたり最大 10 回の SQS ポーリング API コールを処理できます。イベントポーラーの数を最小限に設定することで、アプリケーションがベースラインの処理能力を維持し、トラフィックの急増に即座に対応できるようになります。既知のピーク時のワークロード要件を処理するのに必要となる最小限のイベントポーラーを設定することをお勧めします。オプションの最大値設定は、全体の処理スループットを制限することで、ダウンストリームシステムの過負荷を防ぐのに役立ちます。 この新しいモードでは、イベント駆動型アプリケーションがさまざまなワークロードを処理する方法が大幅に改善されています。トラフィックが増加すると、ESM は増加するバックログを数秒以内に検出し、設定した最小値と最大値の間でイベントポーラーを以前の 3 倍の速さで動的にスケーリングします。このスケーリング機能の強化は、処理能力の大幅な向上によって補完され、合計トラフィックは最大 2 GBps、同時リクエスト数は最大 2,000 件までサポートします。これは以前の 16 倍にあたります。すぐに使用できるイベントポーラーの数を最小限に抑えることで、アプリケーションは予測可能なパフォーマンスを実現し、リソースのスケールアップに通常伴う遅延なしで、突然のトラフィックの急増を処理できます。トラフィックが少ない時期には、ESM は設定されたイベントポーラーの最小数に自動的にスケールダウンします。つまり、応答性を維持しながらコストを最適化することができます。 試してみましょう プロビジョニングモードの有効化は、 AWS マネジメントコンソール で簡単に行えます。SQS キューと Lambda 関数があらかじめ設定されている必要があります。まず、Lambda 関数の [設定] タブで [トリガー] を選択してから [トリガーを追加] を選択します。これにより、トリガーを設定できるユーザーインターフェイスが表示されます。ソースのドロップダウンメニューから [SQS] を選択し、使用する SQS キュー を選択します。 [イベントポーラー設定] に、 [プロビジョニングモード] という新しいオプションが表示されるようになりました。 [設定] を選択すると、 [最小イベントポーラー] と [最大イベントポーラー] の設定が表示されます。それぞれにデフォルト値と最小値および最大値が表示されます。 プロビジョニングモード を設定したら、トリガーを保存できます。後で変更を加える必要がある場合は、AWS Lambda 設定セクションの [トリガー] タブで現在の設定を表示し、そこで現在の設定を変更できます。 モニタリングとオブザーバビリティ Amazon CloudWatch メトリクスを通じてプロビジョニングモードの使用状況をモニタリングできます。ProvisionedPollers メトリクスは、イベントを処理しているアクティブなイベントポーラーの数を 1 分単位で表示します。 今すぐご利用いただけます Lambda SQS ESM のプロビジョニングモードは、現在すべての商用 AWS リージョン でご利用いただけます。この特徴量は、AWS マネジメントコンソール、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK 経由で使用を開始できます。料金は、プロビジョニングされたイベントポーラーの数とプロビジョニング期間に基づいており、イベントポーラーユニット (EPU) で測定されます。各 EPU は、ESM あたり最低 2 つのイベントポーラーを使用して、イベントポーラーあたり 1 秒につき最大 1 MB のスループットキャパシティをサポートします。EPU 料金の詳細については、 AWS 料金ページ をご覧ください。 SQS ESM のプロビジョニングモードの詳細については、AWS Lambda ドキュメント をご覧ください。イベント処理リソースの制御を強化して、応答性が高いイベント駆動型アプリケーションの構築を今すぐ始めましょう。 原文は こちら です。

2025 年 11 月 13 日、 AWS IoT Core Device Location サービス を使用して Amazon Sidewalk 対応デバイスの位置データを解決する新機能を発表いたしました。この特徴量により、GPS モジュールを Sidewalk デバイスにインストールする必要がなくなると同時に、開発者は位置データを簡単に解決できるようになります。スマートホームのセンサートラッカーなど、小型のコイン電池で駆動するデバイスは、Sidewalk を使用して接続します。動き回る製品での内蔵 GPS モジュールのサポートは、高価なだけでなく、最適なバッテリー性能と寿命を確保する上で課題となる可能性があります。 今回のリリースにより、モノのインターネット (IoT) デバイスメーカーとソリューション開発者は、Bluetooth Low Energy (BLE)、Wi-Fi、または全球測位衛星システム (GNSS) の情報を AWS IoT に送信して位置を解決することで、Sidewalk 対応デバイスを使用してアセット追跡および位置監視ソリューションを構築できます。その後、解決された位置データを MQTT トピック または AWS IoT ルール に送信し、そのデータを他の Amazon Web Services (AWS) サービスにルーティングできるため、AWS IoT Core を通じて AWS クラウドのさまざまな機能を使用できます。これにより、ソフトウェア開発が簡素化され、最適なロケーションソースを選択するためのオプションが増え、製品のパフォーマンスが向上します。 このリリースによって、 これまでの課題とアーキテクチャの複雑性 が解消されます。Sidewalk ネットワークインフラストラクチャ自体を使用してデバイスの位置を特定する場合、ネットワークベースのデバイスで位置を検知する必要はありません。そのため、電力を大量に消費する高価な GPS ハードウェアをデバイスに搭載する必要がなくなります。また、デバイスはこの特徴量を使用して GNSS や Wi-Fi からの位置データを効率的に測定し、報告できるため、製品のバッテリー寿命が延びます。したがって、これらの機能強化により、アセット追跡および位置認識型 IoT アプリケーション向けのより魅力的なソリューションを構築できます。 Amazon Sidewalk と AWS IoT Core Device Location サービスについて詳しくご存知ない方のために、その歴史と背景について簡単にご説明します。既にご存知の方は、開始方法のセクションまでスキップしてください。 AWS IoT Core と Amazon Sidewalk の統合 Amazon Sidewalk は、接続オプションを改善することでデバイスの動作を向上させる共有ネットワークです。ペットや貴重品の位置確認から、スマートホームのセキュリティや照明制御、電化製品やツールのリモート診断まで、多様な機能を備えており、お客様のさまざまなデバイスをサポートするように設計されています。 Amazon Sidewalk は、互換性のある Amazon Echo デバイスや Ring デバイスなどの Amazon Sidewalk Gateway (Sidewalk Bridge とも呼ばれます) を使用して IoT エンドポイントデバイスにクラウド接続を提供する安全なコミュニティネットワークです。Amazon Sidewalk では、短距離通信には BLE を使用し、長距離通信には LoRa および周波数偏移変調 (FSK) 無線プロトコルを使用して、長距離での通信に対応する 900 MHz 周波数での低帯域幅および長距離接続を可能にします。 Sidewalk は現在、 米国人口の 90% 以上にサービスを提供 しており、コミュニティや企業向けの長距離接続ソリューショーンをサポートしています。Sidewalk Bridge として機能する Ring カメラまたは Alexa デバイスを所有しているユーザーは、インターネット帯域幅のごく一部を寄付することを選択できます。帯域幅はプールされ、コミュニティ内のすべての Sidewalk 対応デバイスに利益をもたらす共有ネットワークが構築されます。 2023 年 3 月、 AWS IoT Core は Amazon Sidewalk との統合を強化 し、認定済みの Hardware Development Kit (HDK)、SDK、サンプルアプリケーションを使用して Sidewalk デバイスのプロビジョニング、オンボーディング、モニタリングをシームレスに行えるようになりました。この記事の執筆時点では、AWS IoT Core はお客様が Sidewalk ネットワークに接続する唯一の方法です。 AWS IoT Core コンソール では、Sidewalk デバイスの追加、デバイスのプロビジョニングおよび登録、Sidewalk エンドポイントのクラウドへの接続を行うことができます。Sidewalk デバイスのオンボーディングの詳細については、AWS IoT Wireless デベロッパーガイドの「 AWS IoT Core for Amazon Sidewalk の開始方法 」をご覧ください。 2022 年 11 月、当社は AWS IoT Core Device Location サービス を発表しました。これは、デバイスに GPS モジュールが搭載されていない場合でも、IoT デバイスの地理座標を取得できる新特徴量です。Device Location サービスは、単純なリクエストおよびレスポンス HTTP API として使用することも、MQTT、LoRaWAN などの IoT 接続パスウェイで使用することもできます。そしてこの度、Amazon Sidewalk でも使用できるようになりました。 AWS IoT Core コンソール では、デバイスペイロードデータをインポートすることで Device Location サービスをテストして、デバイスの位置を解決できます。リソースの場所は GeoJSON ペイロードとして報告されます。詳細については、AWS IoT Core デベロッパーガイドの「 AWS IoT Core Device Location 」をご覧ください。 自動車、サプライチェーン、産業用ツールなど、複数の業界のお客様から、Sidewalk 製品から位置データを抽出するための Device Location サービスのようなシンプルなソリューションがほしいというご要望をいただいてきました。今回のリリースにより、お客様のソフトウェア開発が合理化され、最適なロケーションソースを選択するためのオプションが増え、製品の改善につながります。 Device Location と Amazon Sidewalk の統合を開始する Sidewalk デバイスの Device Location を有効にするには、 AWS IoT Core コンソール の [LPWAN デバイス] で [AWS IoT Core for Amazon Sidewalk] セクションに移動します。 プロビジョニングデバイス または既存のデバイスを選択して設定を編集し、Sidewalk デバイスの作成および更新時に [位置情報] オプションで [位置情報を有効にする] を選択します。 位置情報を有効にする際に、位置データの送信先を指定する必要があります。送信先は AWS IoT ルールでも MQTT トピックのどちらかを指定できます。 新しい Sidewalk デバイスのプロビジョニング中に位置情報を有効にする AWS コマンドラインインターフェイス (AWS CLI) コマンドの例を次に示します。 $ aws iotwireless createwireless device --type Sidewalk \ --name "demo-1" --destination-name "New-1" \ --positioning Enabled Sidewalk デバイスが Amazon Sidewalk ネットワークへの接続を確立すると、デバイス SDK は GNSS、Wi-Fi、または BLE ベースの情報を AWS IoT Core for Amazon Sidewalk に送信します。お客様が位置情報を有効にしている場合、AWS IoT Core Device Location は位置データを解決し、位置データを指定された送信先に送信します。Sidewalk デバイスが位置計測データを送信すると、選択したデバイスの [位置] セクションに、解決された地理座標とマップピンも表示されます。 また、次の例に示すように、位置情報が GeoJSON 形式で送信先に送信されます。 { "coordinates": [ 13.376076698303223, 52.51823043823242 ], "type": "Point", "properties": { "verticalAccuracy": 45, "verticalConfidenceLevel": 0.68, "horizontalAccuracy": 303, "horizontalConfidenceLevel": 0.68, "country": "USA", "state": "CA", "city": "Sunnyvale", "postalCode": "91234", "timestamp": "2025-11-18T12:23:58.189Z" } } Amazon CloudWatch Logs for AWS IoT Core を有効にすることで、Sidewalk デバイスと AWS クラウド間の Device Location データをモニタリングできます。詳細については、AWS IoT Wireless デベロッパーガイドの「 AWS IoT Core for Amazon Sidewalk 」をご覧ください。 今すぐご利用いただけます AWS IoT Core Device Locationと Amazon Sidewalk の統合は、米国東部 (バージニア北部) リージョンで一般提供を開始しました。ユースケース、ドキュメント、サンプルコード、パートナーデバイスの詳細については、 AWS IoT Core for Amazon Sidewalk 製品ページ をご覧ください。 AWS IoT Core コンソール でお試しいただいた後、 AWS re:Post for AWS IoT Core または通常の AWS サポート窓口までフィードバックをお寄せください。 – Channy 原文は こちら です。

本ブログは、NTT西日本グループ 吉田 健哉氏、同 中井 智絵氏、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 川岸 が共同で執筆しました。 はじめに NTT西日本株式会社 （以下、NTT西日本）では、 ビジネスチャット『elgana』（エルガナ） をサービス提供しています。 2022 年 7 月にアマゾン ウェブ サービス (AWS) へプラットフォーム を移行し、生成 AI による新機能開発も加速しています。 elgana Project 「AI Lab.チーム」では、生成 AI を実際の業務にどう活かせるかをテーマにトライアル開発を進めています。本記事では、営業担当者支援を目的として Amazon Bedrock Knowledge Bases を活用した RAG を構築し、そのトライアルを実施した取り組みについて紹介します。 取り組み背景 elgana は一般の企業様を中心にご利用いただいているサービスですが、生成 AI による新機能開発は社内向けに検証を開始しました。NTT西日本グループにおいて営業担当者は日々多様な商材を扱い、膨大なマニュアルや資料を参照しています。しかし実際には、情報が複数のシステムに散在しており、必要な情報を探し出すのに時間がかかる・属人化してしまうといった課題がありました。加えて、商材の問い合わせ窓口である社内ヘルプデスクは限られた対応時間の中で運用されており、すべての問い合わせに即時対応することは難しい状況でした。そこで、生成 AI に社内ナレッジを組み合わせる RAG を活用し、効率的に「聞ける・探せる・使える」仕組みを提供できないか検証することにしました。AWS サービスとの親和性、日本語対応、セキュリティ設計の容易さから、Amazon Bedrock Knowledge Bases を採用しました。 営業支援 AI ボット 営業支援 AI ボットは elgana 上に構築しました。トークルーム上で営業支援 AI ボットに対して商材に関する質問を入力すると、AI ボットが即時に回答を提示する仕組みです。また、AI ボットからの回答には、補足情報として関連するマニュアルページへのリンクを設けることで、裏付けとなる情報を容易に確認できる設計としました。 さらに、回答後には「解決した／解決していない」の簡易アンケートを設け、解決率を収集するとともに、未解決のユーザーをヘルプデスクに誘導する流れを設けています。これにより、AI の強みと有人対応を組み合わせた実用的なサポート体験を実現しています。 アーキテクチャ 本システムでは、AWS のマネージドサービスをフル活用して構成し、最新技術の活用、インフラ運用の負担軽減とアプリレイヤの改善への集中を実現しています。elgana 上で営業支援 AI ボットに質問すると、Amazon API Gateway と AWS Lambda で実装したアプリケーションがメッセージを受信し、Amazon Bedrock Knowledge Bases を呼び出して質問に回答します。ナレッジのドキュメントの保存先のベクトルストアとして Amazon OpenSearch Serverless を利用しています。 営業支援 AI ボットでは、利用者体験を向上させるため、回答生成に利用したマニュアルのページ番号まで案内すること、関連するサービスマニュアルのナレッジだけを参照するよう メタデータフィルタリング を活用して検索対象を絞り込むことで回答精度を向上させる工夫をしています。 具体的な処理内容としては、運用者が Amazon S3 にアップロードしたマニュアルの pdf ファイルは AWS Lambda (pre-processing) を通じて、(A) ページ分割した上で、Markdown 形式に変換、(B) マニュアルに付与するメタデータを作成、の 2 つの処理が行われた後、Amazon S3 に格納されます。(A) の処理では、ページ分割することで RAG 回答で参照したマニュアルのページ番号をファイル名から特定できるようにしています。また、マニュアルに含まれる表データの抽出精度向上のため、pdf 文書をテキスト化するための python ライブラリである pdfminer を用いて HTML 化し、その後 Claude 3.5 Sonnet で Markdown 形式に変換しています。なお、Claude 3.5 Sonnet はマルチモーダル対応 LLM であるため、画像認識による情報抽出も可能ですが、検証時点では pdfminer を介す方法の方が優れていると判断しました。(B) の処理では、S3 のオブジェクトキー情報からカテゴリ情報等を抽出して、 .metadata.json メタデータファイルを作成しています。 以下はメタデータファイルの中身の例です。 { "metadataAttributes": { "original-s3-key": "docs/商材A/pdf/manualA.pdf", "file-type": "pdf", "category": "商材A" } } このメタデータは、ベクトルストアからドキュメント検索する際に、メタデータに基づき事前にフィルタリングした上で、関連するドキュメントを検索できます。上記の例では、単一の Knowledge Base に複数の商材のマニュアルを格納していた場合にも、 category = 商材A でフィルタリングすることで関連する情報を取得できるため、検索精度向上に寄与します。 トライアル結果 今回の取り組みでは、実際の営業担当者に数週間トライアル利用していただき、その後、ユーザーアンケートを実施し様々な評価を得ました。利用者からは「知りたい情報に素早くアクセスできる」「マニュアルを探す時間が減った」といった声が多く寄せられ、業務効率化につながる手応えを実感していただいており、現場での実用性を確認する結果となりました。一方で、「回答速度を上げてほしい」や「回答の幅（サービスの種類）を広げてほしい」などの改善意見もポイントも挙げられました。こうした声を踏まえ、今後も更なる機能改善を繰り返し利用者がさらに安心して業務に取り入れられるよう、進化させていく予定です。 今後の展望 今回のトライアルで得られた成果をもとに機能改善を重ねて実運用を目指していく予定です。 また、開発した RAG 基盤は Amazon S3 にナレッジドキュメントを格納するだけで対象商材に特化した検索基盤を自動的に構築できる仕組みであり、幅広い業務で活用できる柔軟な基盤へ発展させることも視野に入れています。将来的には Amazon Bedrock AgentCore 等を活用することで、単なる検索や回答にとどまらずタスク実行まで支援できる「Agentic RAG」へ時代に即した価値創出を目指します。 まとめ 本ブログでは、NTT西日本グループによる、 Amazon Bedrock Knowledge Bases を活用した営業支援 AI ボットによる情報検索効率化の取り組み事例をご紹介しました。生成 AI の業務利用にあたっては、ハルシネーションのような不確実性を課題視されるお客様もいらっしゃると思います。本事例では、関連マニュアルのページ番号まで明示することで情報の正確性を迅速に確認できる仕組みを構築するとともに未解決の場合にはヘルプデスクに誘導する仕組みを設け、AI の強みと有人対応を組み合わせた実用的なサポート体験を実現しています。皆様の生成 AI 活用の参考になれば幸いです。 著者 吉田 健哉 NTTビジネスソリューションズ株式会社 バリューデザイン部 システム開発部門 中井 智絵 NTT西日本株式会社 ビジネス営業本部 バリューデザイン部 DXプラットフォーム部門 川岸 基成 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト