こんにちは、ソリューションアーキテクトのいなりくです。 ついに来ました、 Kiro 一般提供開始 ！ このタイミングに合わせて、日本のお客様に向けた特別企画として、11 月 18 日（火）から 11 月 28 日（金）まで、AWS JP Blog 連載イベント「Kiroweeeeeeek in Japan」を開催します！Week と言いながら 1 週間限定じゃないんか！というツッコミは禁止です。その代わり、e は一週間にちなんで 7 つにしています。 AWS Japan 社員が、日本の開発現場の皆さまに、生成 AI／エージェント時代における “仕様駆動から実装・運用までの道筋” を、日本語で丁寧にお届けします。 Kiro が一般提供開始！＆ Kiro CLI 公開のご案内 7 月に Kiro がプレビュー版としてローンチ してから約 4 ヶ月が経ちました。日本のお客様からは「まだプレビューなのですか？」と何回も質問をいただいていました。そして晴れて、 11 月 18 日より、Kiro が一般提供開始されます 。同時に、 Kiro CLI が公開され 、CLI ベースでのワークフロー支援もスタートします。 この 2 つを契機に、Kiro は “エージェント支援開発” を次のフェーズへと押し上げるツールとなります。AWS Japan チームとして、日本のお客様がいち早くこの新しい開発パラダイムを活用できるよう、実践的な情報をお届けいたします。 イベント概要 期間： 2025 年 11 月 18 日（火）〜11 月 28 日（金）平日のみ（8 回） 連載の特徴：この連載は、日本のお客様から実際にいただいたご質問やご相談を中心に構成いたします。Kiro の導入背景から CLI を含む新ワークフローの解説、仕様駆動開発とエージェント設計の実践、プロパティベーステストによる品質保証、カスタムエージェントを活用した専門特化開発、チーム開発での Kiro 戦略、そして日本のお客様の様々な業界・現場での活用事例まで、実際のニーズに基づいた内容で幅広くカバーします。基本は 1 日1 本の公開を予定しておりますが、日本のお客様から質問が多い場合は、記事の本数が増えるかもしれません。いわゆる元気玉方式 (?) です。また、X（旧Twitter）で #kiroweeeeeeek を付けて投稿された読者の質問・悩みを可能な限り記事で取りあげさせていただきます。また、連載記事をこのブログから一覧できるよう、各回リンク・目次機能を設けます。 今すぐできること 事前に Kiro の公式サイト をご覧になり、概要を掴んでおいてください。”自分たちならこう使う” という視点で、Kiro の可能性を少しだけでも考えてみてください。X で #kiroweeeeeeek をつけて様々な角度からの投稿をお待ちしています！ Kiro に関する質問・悩み・感想 現在の開発フローでの課題や成功事例 AI 開発支援ツールへの期待や懸念点 チーム開発での AI 活用アイデア 業界固有の開発課題 連載で取り上げてほしい具体的なトピック Kiro を試してみた感想やレビュー どんな業界・規模・開発スタイルのお客様からの投稿も大歓迎です。 それでは、11 月 18 日（火）からの連載を通じて、日本のお客様の実際のご質問にお答えしながら、Kiro を使った仕様駆動開発の知見を日本のお客様とともに深めていきましょう！ 皆さまのご参加・ご反響を心よりお待ちしています！ 著者 稲田 大陸 – いなりく AWS Japan で働く筋トレが趣味のソリューションアーキテクト。2022 年から三菱電機グループをご支援させていただいています。最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。

深夜 2 時、本番サーバーに接続してバグをデバッグしています。この一週間、IDEでAIエージェントを使って効率よく開発を進めてきたあなたなら、こんな時こそAIの力を借りたいと思うでしょう。しかし、コンテキストを切り替えるとすると、ターミナルセッションが切れ、SSH 接続も失われ、作業の流れが途切れてしまいます。結局、手動でログを確認し、構文を検索して、一人で格闘することになります。AI が使える IDE で作業するか、実用的だけれど AI サポートのないターミナルで作業するか。本来なら、こんな選択を迫られる必要はないはずです。 今回、私たちはそのギャップを解決しました。Kiro CLI なら、AI エージェントを直接ターミナルで使えます。同じエージェント、同じ機能を、どこでコーディングしていても利用できます。 Kiro CLIとは？ Kiro CLI は Amazon Q Developer CLI の高度なエージェント機能（エージェントモード、MCP、ステアリング、カスタムエージェントを含む）をベースに、ソーシャルログイン、Haiku 4.5、そしてパフォーマンス、効率性、出力品質のバランスを自動調整する Auto エージェントを追加したツールです。プロジェクトの構築、本番環境の問題のデバッグ、インフラコードの作成など、すべてシェルを離れることなく行えます。必要なことを自然言語で説明するだけです。 この強力さの秘密は専門化にあります。あなたのコードベースに合わせたカスタムエージェントを作成できます。API パターンを熟知するバックエンドスペシャリスト、コンポーネントに精通したフロントエンドエキスパート、インフラを理解する DevOps エージェントなどです。各エージェントは、担当するワークフローに関連する情報にコンテキストウィンドウを集中させます。 すでに Kiro IDE を使用していますか？あなたの .kiro フォルダ設定は両方の環境で動作します。Kiro CLI は同じステアリングファイル（プロジェクト全体で AI の動作を制御するルール）と同じ MCP サーバーを利用できます。一度設定すれば、どこでも使えます。 なぜ Kiro CLI？ ターミナルから離れる必要がありません – コンテキストを切り替えたり構文を調べたりする手間が省けます AI ワークフローを体系化 – カスタムエージェントで異なるタスクに最適化された環境を瞬時に切り替えられます 一度の設定で両環境に対応 – MCP サーバーや設定ルール、プロジェクトドキュメントがKiro IDEとKiro CLI両方で使えます 実際の作業スタイルに対応 – インフラ管理、コードレビュー、デバッグなど、特定のワークフロー用エージェントを作成・共有できます 高速な自動化を実現 – コードフォーマット、テスト実行、ログ管理などを自動化されたシェルコマンドで処理できます 始め方 インストール Kiro CLI は macOS と Linux で利用可能です。 インストール は簡単です。 curl -fsSL https://cli.kiro.dev/install | bash 最初のステップ 1. 認証：あなたの資格情報でサインイン kiro-cli 2. コマンドを探索：いつでもヘルプを取得 /help 主要機能 1. カスタムエージェント：ターミナルでのAIコーディングの構造化 カスタムエージェントは、AI が異なるタスクに対してどのように動作すべきかを正確に定義できるようにすることで、AIを活用したターミナルワークフローに構造をもたらします。 事前承認されたツール – 毎回許可を求めることなく、信頼できるツールを自動実行できます 永続的なコンテキスト – プロジェクトファイルやドキュメント、標準設定を自動的に読み込みます アクセス制御 – 利用可能なツールを制限して、焦点を絞り、安全を確保します ワークフロー固有の設定 – 用途に応じた異なるエージェント：AWS オペレーション用、コードレビュー用、デバッグセッション用など エージェント設定の例： { "name": "backend-specialist", "description": "Expert in building Express.js APIs with MongoDB", "prompt": "You are a backend developer specializing in Node.js and Express. You write secure, well-tested APIs with proper error handling, input validation, and RESTful design.", "tools": ["fs_read", "fs_write", "execute_bash"], "toolsSettings": { "fs_write": { "allowedPaths": ["src/api/**", "tests/api/**", "server.js", "package.json"] } }, "resources": [ "file://.kiro/steering/backend-standards.md“ ] } この構造化されたアプローチにより、プロジェクト設定を常にコンテキスト切り替えしたり再説明したりする必要がなくなります。AI は必要なことを把握しており、あなたは作業の流れを維持できます。 この例のエージェントは、バックエンド開発に特化したスペシャリストです。フロントエンドや DevOps など無関係なトピックに時間や精神的エネルギーを費やすことがありません。ファイルパスの制限により、バックエンドファイル（ src/api/** や server.js など）のみを扱うことができ、フロントエンドや設定ファイルを誤って破損することを防ぎます。バックエンド標準の md ファイルを自動的に読み込むため、async/await、エラー処理、API 設計に関するチームのルールを毎回思い出させる必要がありません。結果として、エージェントが無関係な情報に惑わされることがないため、より速く、より正確で、一貫して標準に従った回答が得られます。 個々のツール制限を超えて、Kiro CLI はさらに柔軟性を高めるための幅広い許可パターンもサポートしています。 @builtin ネームスペースを使用することで、すべての組み込みツールを一度に事前承認するか、正確な制御のために個々のツールを指定するなどきめ細かいツール許可を行うことができます。 { "allowedTools": ["@builtin", "my_custom_tool"] } 2. ビジュアルインジケータによるスマートなコンテキスト管理 Kiro CLI は 3 つの柔軟なアプローチでコンテキストを提供します。 エージェントリソース ：重要なプロジェクトファイル用のセッション間で永続的なコンテキスト セッションコンテキスト ：クイック実験用の一時ファイル ナレッジベース ：コンテキストウィンドウのスペースを消費せずに大規模なコードベース（PDF もサポート！）のセマンティック検索 コンテキスト使用率 ：kiro-cli chat を開いた状態で、 /context と入力するとビジュアルインジケータが表示されます。これにより、コンテキスト消費を意識し、長い会話中にそれを積極的に管理するのに役立ちます。 3. 柔軟な認証オプション Kiro CLI はあなたのワークフローに合わせて複数の認証方法をサポートしています。 GitHub ：GitHub アカウントとのシームレスな統合 Google ：Google の資格情報でサインイン AWS Builder ID ：AWSデベロッパー向けの迅速なセットアップ AWS IAM Identity Center ：集中管理による企業グレードの認証 IAM Identity Center を使用しているチームでは、管理者は AWS マネジメントコンソールからすべてを管理できます。例えば、サブスクリプション層の割り当て、MCP サーバーの設定、支出の追跡、組織全体の請求の統合などです。追加のアイデンティティプロバイダーのサポートはまもなく提供される予定です。 4. Kiro IDE との統合 すでに Kiro IDE を使用していますか？既存の設定はそのまま機能します。すべてを最初から再設定する必要はありません。Kiro IDE の設定は Kiro CLI にシームレスに適用されます。 MCP サーバー： .kiro/settings/mcp.json をコピーすれば、MCP ツールの準備が整います ステアリングルール： .kiro/steering/*.md ファイルは Kiro CLI で同じプロジェクト標準、同じコンテキストで機能します プロジェクトドキュメント：すべての .kiro ドキュメントと設定が引き継がれます つまり、コンテキストを失ったり AI アシスタントを再設定したりすることなく、IDE とターミナルの間を行き来できます。同じ Kiro の使い心地が、異なる環境で利用できるのです。 5. 最新のエージェント CLI 体験に期待されるその他の機能 ターミナルでのインタラクティブAIチャット コマンドラインから直接 Kiro との会話を開始できます。 kiro-cli 新しいプロジェクトをゼロから構築し、インフラストラクチャーをコードとして記述し、既存のコードベースに機能を追加できます。これらすべてをターミナルを離れることなく行えます。Kiro はプロジェクトのコンテキストを理解し、複数のファイルにわたって意味のある変更を加えることができます。 > PostgreSQL、Redis キャッシング、Docker セットアップを備えた新しい FastAPI プロジェクトを作成 > JWT を使用して私の Express アプリに認証ミドルウェアを追加 > RDS と ElastiCache を使用した 3 層の AWS アーキテクチャ用の Terraform 設定を作成 より長く詳細なプロンプトを作成する必要がありますか？ /editor を使用して好みのテキストエディタを開き、複数行で詳細な指示を書くことができます。 マルチモーダル入力：画像を直接参照 スクリーンショット、図、またはエラーメッセージを共有する必要がありますか？ Kiro CLI は自動的に処理します。UIの問題のデバッグ、アーキテクチャ図の共有、視覚的なコンテンツの助けを得るために画像を渡すことができます。 Model Context Protocol （MCP）のサポート Kiro CLI は Model Context Protocol （MCP） をサポートしており、外部ツールやサービスでその機能を拡張できます。最も良い点は？既に Kiro IDE で MCP サーバーを使用している場合、それらは Kiro CLI でもシームレスに動作します。MCP の詳細については、「 Kiro : リモート MCP サーバーの紹介 」をご覧ください。 クレジット使用量 IDE と同様に、Kiro は使用に応じて使用したクレジット数を表示するので、追跡することができます。 Autoエージェント Kiro CLI には、Kiro IDE を強化するのと同じインテリジェントな Auto エージェントが含まれています。Auto は各タスクに最適なモデルを動的に選択し、速度、コスト、品質のバランスを取ります。その結果、優れた効率性—Autoモードで使用するとXクレジットかかるタスクが、手動で Sonnet 4 または Sonnet 4.5 を選択すると 1.3X クレジットかかるでしょう。どのモデルを使用するか考えることなく、より良い価格でより良い結果を得るために Auto に任せましょう。 Auto はデフォルトで有効になっており、Kiro CLI で /model コマンドを使用してモデルを選択することもできます。 実世界のユースケース 上記の backend-specialist の例を思い出してください？以下は Kiro でそれを活用する方法です。エージェントの設定を実装した後、それを使う準備ができています。以下の例は、このエージェントを呼び出す方法と、実世界でそれを活用するためのサンプルプロンプトを示しています。 kiro-cli chat --agent backend-specialist > 認証されたユーザーがプロフィール情報を更新できる新しい /api/users/profile エンドポイントを追加してください。メールフォーマットとパスワード強度の検証、データベース障害に対する適切なエラー処理、そして単体テストを含めてください。 > メッセージ、既読ステータス、タイムスタンプのフィールドを持つユーザー通知用の新しい MongoDB スキーマを作成してください。RESTful の規約に従って CRUD エンドポイントを追加し、パフォーマンスのための適切なインデックスを含めてください。 > /api/orders エンドポイントで断続的に 500 エラーが発生しています。より良いエラーログを追加し、注文処理ロジックの潜在的な競合状態を特定するのを手伝ってください。 あらゆるワークフローに特化したエージェントを作成できます。例えばリントツールとチームのスタイルガイドを備えたコードレビューエージェント、インフラアクセスとデプロイメントスクリプトを持つ DevOps エージェント、またはログユーティリティと一般的なトラブルシューティング手順が事前ロードされたデバッギングエージェントなどです。各エージェントはそれぞれの特定のタスクに関連することにコンテキストを集中させ、AI とのやり取りをより速く、より関連性の高いものにします。 Kiro コミュニティに参加しよう ぜひあなたのご意見をお聞かせください！フィードバックの共有、エージェント設定の交換、そして他の Kiro ユーザーとの交流をお待ちしています。 Kiro Discord コミュニティ に参加して、チームメンバーや他の開発者と交流しましょう。 今すぐ始めよう Kiro をあなたのターミナルにインストールする準備はできましたか？ Kiro CLI をインストール して、実際に使いやすい AI を活用したコマンドラインワークフローを体験しましょう。 curl -fsSL https://cli.kiro.dev/install | bash 既存の Kiro IDE ユーザーであれ、Kiro を初めて使用する方であれ、AI のサポートを受けながらターミナルで作業することができます。

本記事は米国時間 11 月 17 日に公開された「 Kiro is generally available: Build with your team in the IDE and terminal 」の日本語抄訳版です。Kiro の最新情報は、 https://kiro.dev/ をご覧ください。 7 月に Kiro プレビュー版としてローンチして以来、AI を使った構造化された開発手法として仕様（Specs）駆動開発が広く採用されてきました。私たちは、仕様駆動開発を AI コーディングツールに初めて導入し、業界全体がその価値を認識しています。計画こそが AI エージェントと共に作業する正しい方法です。 この数か月間、リモート MCP（Model Context Protocol）、グローバルステアリングファイル、開発サーバーサポート、Auto エージェントなどの機能を追加し、仕様駆動開発をより柔軟にしてきました。 本日、Kiro の一般提供を開始するにあたり、新しい機能の提供を開始します。これには、1/ 仕様の正確性を検証するプロパティベーステスト、2/ Kiro での開発の進捗を検証する新しい方法、3/ カスタムエージェントを備えたターミナル用の新しい Kiro CLI、そして 4/ 集中管理機能を持つチームプランが含まれます。 Kiro IDE Kiro IDE は 3 つの新機能を導入します。 プロパティベーステストによる「仕様の正確性」の測定 AI コード生成には根本的な問題があります。コードが実際に仕様通りに動作しているかをどうやって知るのでしょうか？従来のユニットテストは特定の例のみをチェックします。さらに悪いことに、テストを書く人（人間でも AI でも）は自身のバイアスに制限されます。コードをテストするためには、様々な具体的なシナリオをすべて考慮しなければなりませんが実装とテストを同じ存在が書いた場合、思いつかなかったエッジケースを見逃します。AI モデルはしばしば表面的な解決策に走ったり、テストを修正するために無限ループに陥ったりします。 プロパティベーステスト (PBT) は、コードが Spec で定義した動作と一致するかを測定することで、この問題に対処します。特定の例をテストする代わりに、PBT はプロパティ（要件から抽出された一般的なルール）をチェックします。 プロパティとは？ ：プロパティは普遍的な記述です。任意の入力セットに対して、特定の前提条件が成立する場合、ある述語（期待される動作）が真であるということです。例えば、「任意の認証済みユーザーと任意のアクティブなリストに対して、ユーザーはそのリストを閲覧できる」などです。 どのような仕組みなのか？ ： Kiro は EARS（Easy Approach to Requirements Syntax）形式を使用した仕様の記述を支援します（例：システムは認証済みユーザーが有効な車のリストを閲覧できるようにしなければならない）。Kiro はこれらの要件からプロパティを抽出し、論理的にテスト可能なものを判断し、数百から数千のランダムなテストケースを生成してコードをチェックします。 例えば、車の販売アプリを開発する場合を考えてみましょう。 従来の単体テスト：「ユーザーが車#5をお気に入りに追加したら、お気に入りリストに車#5が表示される」 プロパティベーステスト：「どのユーザーでも、どの車でも、お気に入りに追加した車は必ずお気に入りリストに表示されるべき」という性質を定義します。すると、PBT が自動的に様々なパターンでテストを実行します。例えば、ユーザー A が車#1を追加するケース、ユーザー B が車#500を追加するケース、ユーザー C が複数台まとめて追加するケース、特殊文字を含むユーザー名のケース、新車・中古車・認定中古車など異なるステータスの車のケースなど、数百通りもの組み合わせを自動生成してテストします。これにより、想定外のエッジケースも発見でき、実装が設計意図通りに動作することを確認できます。 このプロセス全体を通じて、PBT は「縮小」を通じて反例を見つけるために探索し、失敗の境界を特定します。—あたかもあなたのコードを壊そうとするレッドチームのようにです。違反や反例を見つけると、Kiro は自動的に実装を更新するか、Spec、実装、または PBT 自体を修正するオプションを提示します。 重要性 ： PBT は検証や証明ではありませんが、手動では決して書かないようなシナリオ全体で正確性の証拠を提供し、実装が定義した通りに動作するかを示します。 プロパティベーステストの技術的詳細を読む → チェックポイント エージェント実行フロー内の以前の変更に戻ることができます。Kiro は、エージェントが変更を加えたりアクションを実行したりするたびにチェックポイントを生成します。進捗を失うことなく、任意のステップをロールバックできます。これは、タスクの実装が進んでいて、進捗を失いたくない場合や、クレジットを使って作業をやり直したくない場合に便利です。 チェックポイントの詳細を読む → マルチルートワークスペースサポート Kiro は、複数のプロジェクトルートを同時に扱えるようになりました。複数の git サブモジュールや単一プロジェクト内の複数のパッケージを持つチームは、AI エージェントを使ってそれらすべてを横断して作業できます。典型的な Kiro ワークスペースには、単一の「ルート」フォルダ（例： /users/bob/my-project） が含まれます。マルチワークスペースサポートにより、単一の kiro ワークスペースが複数のルートを持つことができます。例えば、 /users/bob/my-project と /shared/utils/auth の両方をトップレベルフォルダとして含む単一のワークスペースです。 マルチルートワークスペースの詳細を読む → Kiro CLI の導入 Kiro エージェントがターミナルで利用可能になりました。CLI を使用して、機能の構築、ワークフローの自動化、エラーの分析、バグの追跡、修正の提案を、選択したターミナルで数秒で実行できます。フローを維持する高度にインタラクティブなループで作業できます。 何が含まれるのか？ ： CLI は、Kiro の全機能をターミナルにもたらします。Claude Sonnet 4.5、Claude Haiku 4.5、Auto、ステアリングファイル、高度なコンテキスト管理、ローカルでファイルを読み書きし、API を呼び出し、bash コマンドを実行する MCP ツールが含まれます。Spec 作成サポートは間もなく提供されますが、CLI で既存の spec を使って作業することもできます。 CLI はまた、特定のタスク用にカスタマイズされた専門的な AI アシスタントであるカスタムエージェントもサポートしています。事前承認されたツール権限、コンテキストファイル、カスタムプロンプトで最適化されています。例えばバックエンドスペシャリストは API パターンとスキーマのみに焦点を当てます。フロントエンドエージェントはコンポーネントのみを知っています。各エージェントは、重要なことだけにコンテキストウィンドウを使用します。カスタムエージェントは、繰り返しやコンテキストの劣化のリスクなしに、Kiro がその分野の専門家として機能するように、専門知識を非常に正確にパッケージ化する方法と考えてください。 過去数週間 CLI を使用しているユーザーからは、そのスピードとインタラクティブ性を気に入っているとの声をいただいています。IDE で使用しているのと同じ Kiro サブスクリプションとログインで CLI を使用でき、クレジット制限と超過分は両方のツールで共有されます。 以下のコマンドで macOS または Linux にインストールしてください。 curl -fsSL https://cli.kiro.dev/install | bash Kiro CLI とカスタムエージェントの詳細を読む → チーム向け Kiro チームは、AWS にログインするのと同じ方法で、AWS IAM Identity Center 経由で Kiro にサインアップできるようになりました。管理者は AWS Management Console からアクセスを管理でき、Pro、Pro+、または Power サブスクリプションを割り当てることができます。また、超過分をオンにし、コストを監視し、MCP をセットアップおよび制御し、組織全体で単一の請求書を管理できます。新しい管理ダッシュボードは、チーム、スタートアップ、またはエンタープライズ向けに Kiro を管理するために必要なすべてのツールを 1 か所で提供します。ユーザーとしては、「組織の ID でサインイン」をクリックしてプロセスに従うだけです。 スタートアップ向け Kiro Pro+ 本日から、スタートアップ向けオファーも提供します。 世界のほとんどの地域で 1 年間の Pro+ ティアアクセスを提供します 。シリーズ B までの適格なスタートアップに提供され、2025 年 12 月 31 日まで、クレジットの在庫がある限り利用可能です。既存の AWS Activate クレジットは Kiro に使用でき、両方のオファーは重複適用できます。 こちらから申し込む → チーム、ツール、テスト全体で、Kiro は、AI 駆動型開発に適切なレベルのコンテキストと構造をもたらすことで、あなたが望む働き方をより良くサポートします。これは始まりに過ぎません。 IDE を始める | CLI を始める

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。　だんだんとAWS re:invent 2025 が近づいてきました。そして毎年おなじみ怒濤の1時間。「AWS Black Belt Online Seminar 2025 年 AWS re:Invent 速報」を今年も開催いたします。ぜひ こちらのページ より事前登録をお願いします。 最近AWSのトレーニングサイトのAWS Skill builderで面白いトレーニングを発見しました。 Meeting Simulator という、実際の会議や現場を模した仮想シナリオ上でコミュニケーションスキルや説明力を実践的に鍛えるトレーニングコースです。経営層・ビジネスリーダー・技術担当者など現実に近い複数の立場や性格を持つAIキャラと会議をシミュレーションして、現実的なビジネス課題に対してディスカッションします。AI英語学習のAWS版みたいなものです。会話がまだ英語しか対応していないようですが、面白いので興味がある方は覗いてみてください。 そして、AWS認定全冠ホルダーの皆様、もうすぐ AWS Certified Generative AI Developer – Professional のベータが開始されるようです。最新情報をチェックしてみてください。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に引き続き募集中ですのでよろしくお願いします。 では今週も生成 AI with AWS界隈のニュースを見ていきましょう！ さまざまなニュース AWS生成AI国内事例ブログ「[対談記事] 「その AI の精度が 1% 上がったとき、顧客価値は？」 freee が語る、価値創出論と AI ネイティブ組織への変革」を公開 フリー株式会社は創業時から「AI CFO」というビジョンを掲げ、LLMの登場を機にAIネイティブ組織への本格的な変革を開始しました。同社は「AIラボ」という横串組織を設立し、機械学習の専門家が各プロダクトチームと協働してAI機能を実装する体制を構築しています。「成功基準」という独自フレームワークの確立で、AI投資のROIを適切に評価し、真の顧客価値創出に繋げる実践的な方法論を示しています。特に「確認コスト」と「修正コスト」を分離した業務フロー設計により、AI導入後の総コストを正しく把握し、業務効率化の実効性を高める手法は皆様にとって参考になります。技術的な精度向上だけでなく、それがどれだけの顧客価値を生み出すかを定量化する「成功基準」フレームワークと、AI専門組織による全社支援体制の構築方法は、AI活用をPoCレベルから実際のビジネス価値創出へと発展させるための具体的な組織運営手法として大変有益な知見となります。 AWS生成AI国内事例ブログ「株式会社 Berry 様の AWS 生成 AI 活用事例「Amazon Bedrockで医療機器のQMS業務を効率化」」を公開 医療機器メーカーである株式会社Berry様が、Amazon Bedrockを活用してクラウド型eQMS「QMSmart」に3つのAI機能を導入した事例を紹介しています。医療機器業界では、QMS省令やISO 13485などの厳格な規制要件への対応、膨大な文書管理、品質イベント処理が大きな負担となっていましたが、Amazon BedrockのGuardrails機能により高いセキュリティレベルを確保しながら、AI文章チェック機能（規制適合性の自動判定）、AI根本原因分析支援機能（なぜなぜ分析支援）、AIテスト生成機能（文書から理解度測定問題を自動生成）を実装しました。当初はRAGやファインチューニングが必要と考えていましたが、システムプロンプトの工夫だけで専門性の高い回答を生成できることを検証で確認し、開発期間を約1か月から約1週間に短縮できました。 ブログ記事「Kiro : リモート MCP サーバーの紹介」を公開 Model Context Protocol（MCP）は、AIエージェントがツールや外部システムに接続するための標準プロトコルとして、AIコーディングアシスタントで広く活用されています。これまではローカル環境で動作するMCPサーバーが主流でしたが、Kiroは新たにリモートMCPサーバーサポートとワンクリックMCPインストール機能を発表しました。リモートMCPサーバーを利用することで、エージェントの機能をローカル環境の枠を超えて拡張でき、データソースやインターネット上のツール、各種サービスにより簡単に接続できるようになります。従来のローカル環境に限定されていたAIアシスタントの機能が、インターネット上の豊富なリソースやサービスと連携できるようになることで、より柔軟で強力な開発支援環境の構築が可能となり、AIを活用したソフトウェア開発の可能性が大きく拡がることになります。 ブログ記事「繰り返すのをやめよう：あなたが見逃していた AI コンテキストレイヤー、グローバルステアリングとは」を公開 Kiroの新機能「グローバルステアリング」は、AIアシスタントに毎回同じプロンプトや設定を繰り返し説明する必要性を解決するAIコンテキストレイヤーです。開発者はグローバルステアリング機能により新しいプロジェクトを開始するたびに発生していた設定の繰り返し作業が不要になり、時間節約と一貫性のあるコード品質の維持が実現できます。特に複数のプロジェクトやチームで作業する開発者は、個人の好み、チームの規約、組織の基準を階層的に適用できるため、効率性と標準化の両立が可能になります。AIアシスタントが初回から開発者の意図やチームの基準を完全に理解した状態で作業を開始できるため、より高品質で一貫性のあるコード生成と、プロジェクト間での技術的負債の削減が実現され、AI支援開発の生産性が向上することになります。 ブログ記事「【開催報告】セキュリティと生成AI について学ぶ GameDay with AWS Partners」を公開 2025年10月14日に「セキュリティと生成AIについて学ぶGameDay with AWS Partners」を開催し、24社70名が参加してセキュリティインシデント疑似体験に取り組みました。AWS GameDayは実際のAWS環境で発生しうるセキュリティインシデントをシミュレーションし、参加者がチーム単位で不正アクセスの検知やデータ漏洩調査、マルウェア感染対処など現実世界の技術課題に取り組む実践的なトレーニングプログラムです。参加者はAWS SecurityHubなどの実際のAWSセキュリティサービスを駆使しながら、制限時間2時間でインシデント対応を体験し、ゲーミフィケーション要素により競い合いながら学習を進めました。イベント後半では、Palo Alto Networks、CyberArk、Weights&Biases、KnowBe4の4社パートナーによるAgentic AIの時代におけるセキュリティソリューションの紹介があり、AWS Well-Architected Frameworkを活用したセキュリティ強化の重要性も説明されました。 ブログ記事「re:Invent 2025 における AI 駆動のオペレーションとオブザーバビリティの活用」を公開 2025年12月1日から開催されるAWS re:Invent 2025のクラウドオペレーショントラックでは、5つの主要テーマにわたる30のセッションを通じて、監視とオブザーバビリティのモダナイゼーションに関する知見を提供します。特に注目されるのは生成AIとインテリジェントな運用分野で、Amazon CloudWatchの自動分析によるインシデント対応の加速化、Amazon Bedrock Agentsを活用したクラウドオペレーション自動化、AI エージェントによるテレメトリーデータの実用的情報変換など、従来の手動トラブルシューティングを数分で解決する効率的なAI駆動ソリューションを紹介します。 ブログ記事「AgentCore Gateway の MCP サーバー統合による MCP アーキテクチャの変革」を公開 このブログでは、Amazon Bedrock AgentCore GatewayにMCPサーバーをターゲットタイプとして直接サポートする新機能を紹介しています。この機能により、複数のドメイン特化MCPサーバーを単一のゲートウェイインターフェースの背後に統合することが可能になり、従来の課題であった組織全体でのツール発見・共有の困難さ、複数MCPサーバー間での認証管理の複雑さ、個別ゲートウェイ維持の管理工数を中央集約型アプローチで解決する方法が説明されています。具体的には、ショッピングカート、製品カタログ、プロモーションといった異なるチームが運用する特化MCPサーバーを、ルーティング、認証、ツール管理のための単一制御ポイントとして統合し、REST APIやAWS Lambda関数と同等に扱う実装手順が詳しく紹介されています。 ブログ記事「金融機関向け生成 AI 活用のリファレンスアーキテクチャとユースケースを公開（金融リファレンスアーキテクチャ日本版 2025）」を公開 このブログでは、AWS金融リファレンスアーキテクチャ日本版に新たに追加された生成AI関連コンテンツとして、金融機関のセキュリティ要件に対応した生成AIワークロードのリファレンスアーキテクチャと、実践的な活用例を紹介しています。リファレンスアーキテクチャでは、オープンソースの「Generative AI Use Cases（GenU）」の閉域版をベースに、金融機関向けの閉域ネットワーク構成、AWS KMSカスタマーマネージドキーによる暗号化強化、Amazon Bedrock Guardrailsの設定強化、監視・ガバナンス機能を実装したサンプルが提供されています。また、具体的なユースケースとして、文書・コンテンツ審査（AIと人間の協働による膨大な文書審査業務の効率化）、AI活用営業・窓口対応トレーニング（ロールプレイ）、契約書業務アシスタント（複数の専門AIエージェントによる包括的支援）、ATM不正検知（マルチモーダルモデルによる特殊詐欺防止）の4つの実装例が詳しく解説されており、一部についてはAWS CDKによるデプロイ手順も紹介されています。 ブログ記事「【開催報告 & 資料公開】AWS 秋のオブザーバビリティ祭り 2025」を公開 このブログでは、2025年11月6日に開催された「AWS秋のオブザーバビリティ祭り2025〜最新アップデートと生成AI×オブザーバビリティ〜」のイベント報告として、オブザーバビリティ分野における生成AI技術の活用事例を中心に紹介しています。特に注目される内容として、「生成AIで進化するAWSオブザーバビリティ」セッションでは、運用課題の解決手段としてのAIOpsアプローチが解説され、Amazon CloudWatchに組み込まれたAI機能（CloudWatch Investigations、Query Generator、CloudWatch Logs Anomaly Detection、CloudWatch Anomaly Detection）によるインシデント調査・対応の効率化手法が紹介されました。また、Amazon CloudWatch MCP ServerやAmazon CloudWatch Application Signals MCP Serverを活用し、Amazon Q Developer CLIを通じてインシデント調査からレポーティングまでを自動化するデモも披露されています。さらに、「Amazon Bedrock AgentCoreで実現！お手軽AIエージェントオブザーバビリティ」セッションでは、2025年10月13日にGA となったAmazon Bedrock AgentCoreを活用したAIエージェント開発・運用における CloudWatch GenAI Observability機能の詳細な活用方法が紹介されています。 ブログ記事「SAP アプリケーション開発を Amazon Q Developer でより速く」を公開 このブログでは、SAPアプリケーション開発におけるAmazon Q Developerの活用方法を紹介しています。Amazon Q Developerを活用し、ABAP コードの生成、BTPとFioriアプリケーションの生成、単体テストケースの作成、レガシーABAPコードのドキュメント化という4つの主要な使用例を紹介しています。自然言語のプロンプトから機能的なABAPコードや完全なFioriアプリケーションを生成でき、SAPのプログラミングフレームワーク全体において生産性向上を実現出来ます。 ブログ記事「SAP Cloud Application Programming を加速する Amazon Q Developer」を公開 このブログでは、SAP Cloud Application Programming Model（CAP）開発を加速するAmazon Q Developerの活用方法を紹介しています。CAPは、Python、Node.js、Core Data Servicesを使用してエンタープライズクラウドサービスとアプリケーションを開発するためのSAPのフレームワークで、コアシステムを変更せずにカスタムアプリケーションを作成できるサイドバイサイド拡張をサポートしています。このツールにより、SAP開発者は複雑なCAPフレームワークの技術的詳細から解放され、従来手動で行っていたプロジェクト構造設定、依存関係構成、ボイラープレートコード作成の時間を大幅に短縮できます。 サービスアップデート Anthropic社のClaude Sonnet 4.5が AWS GovCloud (米国) のAmazon Bedrockで利用可能に Anthropic社のClaude Sonnet 4.5が、AWS GovCloud (米国東部および米国西部)でAmazon Bedrockを通じて利用できるようになりました。Claude Sonnet 4.5はAnthropicの最も高性能なモデルで、複雑なエージェントの構築、高度なコーディング、長期間にわたるタスクの実行において卓越した性能を発揮します。AWS GovCloud (米国)での提供により、政府機関や規制の厳しい業界でも、セキュリティとコンプライアンス要件を満たしながら最新のAI技術を活用できるようになりました。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近、ハーブを育てるのにハマっています。

本記事は 2025 年 10 月 15 日に公開された “ Guide to AWS Cloud Resilience sessions at re:Invent 2025 ” を翻訳したものです。 組織に損失をもたらすダウンタイムを防ぐ方法を学ぶために AWS re:Invent に参加される方は、重要なアプリケーションのレジリエンスを向上させるのに役立つ、150 以上のブレイクアウトセッション、ワークショップ、チョークトーク、ビルダーセッション、コードトークに参加できます。セッションを確認するには、 re:Invent 2025 イベントカタログ を開き Area of Interest で Resilience にチェックを入れフィルタリングします。この投稿では、これらの必見のセッションをいくつか紹介します。ビジネスに最も関連性の高いセッションを選択できるよう、推奨事項を 3 つのトピックに分けています。1/ AWS のイノベーションとベストプラクティス、2/ レジリエントなアプリケーションの構築と運用、3/ レジリエンス文化の醸成です。受付が開始されています。お早めにご予約ください。 AWS のイノベーションとベストプラクティス お客様のアプリケーションに最も信頼性の高いクラウドインフラストラクチャを提供するため、AWS にて行っている最先端のイノベーションをご紹介します。アベイラビリティーゾーン (AZ) やリージョンなどの AWS の 障害分離境界について学び、それらを活用してアプリケーションのレジリエンスを向上させる方法を習得できます。また、20 年以上にわたって大規模な高可用性サービスを運用してきた経験から得られた、実証済みの運用プラクティスと重要な教訓を共有します。 ブレイクアウトセッション From ideas to impact: Architecting with cloud best practices ( ARC204 ) 2025 年は、AWS Well-Architected Framework、Cloud Adoption Framework、AWS Cloud Operating Modelの 10 周年を迎えます。これらの基礎的なフレームワークが、お客様のフィードバック、数千の組織から得られた実践的な知見を通じてどのように進化してきたかを学びます。体系的なガイダンスとして始まったものが、クラウド環境を最適化するための常に進化する知見へと成熟しました。この継続的なフィードバックが、アーキテクチャレビュー、運用、改善活動全体にわたるイノベーションをどのように推進しているかをご覧ください。これらの統合されたベストプラクティスを活用してクラウド変革を加速させるための実践的な戦略を学びます。 Building on AWS resilience: Innovations for critical success ( ARC207 ) 世界経済と重要なインフラストラクチャを支える基幹サービスには、極めて高いレジリエンスが求められます。約 20 年にわたる集中的なイノベーションを通じて AWS は、世界中の重要なワークロードを支える中核的なエンジニアリング手法と運用手法を開発してきました。AWS のアーキテクチャイノベーションと組織的プラクティスが、深刻な障害発生時でもレジリエンスを維持する堅牢なサービスの構築をどのように支援しているかをご紹介します。また、AWS がレジリエンスへの継続的な投資を通じて、政府、経済、重要インフラ全体にわたる基幹サービス提供の基盤をどのように提供しているかを学びます。 チョークトークとコードトーク Building resilient clients: Architecture patterns from Amazon.com ( ARC331 ) Amazon.com の大規模な本番環境での経験から得られた、レジリエントなフロントエンドアプリケーションを構築するためのアーキテクチャパターンをご紹介します。Amazon.com が、障害注入テスト、キャッシング戦略、グレースフルデグラデーションパターンを通じて、ピークイベント時の信頼性を維持するためにフロントエンドシステムをどのようにアーキテクチャ設計しているかを学びます。サーキットブレーカー、デプロイメントの安全性、運用上の優秀性のための包括的なモニタリングの実装を探ります。この技術セッションでは、AWS Well-Architected Framework の原則に沿った、スケールする堅牢なクライアントアプリケーションをアーキテクチャ設計するための実践的なパターンを提供します。 Defend against downtime using fault isolation boundaries ( COP305 ) AWS の障害分離境界に合わせた一般的な障害モードから回復するアプリケーションを構築することで、可用性目標を達成できます。このチョークトークでは、Application Recovery Controller (ARC) を使用して、AWS アベイラビリティーゾーンおよび AWS リージョン内の障害からアプリケーションを回復する方法を共有します。ARC の仕組みと、アーキテクチャに組み込むべき重要なポイントを習得できます。 Resilience testing and AWS Lambda actions under the hood ( COP414 ) サーバーレステクノロジーの使用が増えるにつれて、レジリエンステスト (カオスエンジニアリング) は、信頼性と可用性の高いアプリケーションを確保するためにますます重要になっています。AWS Lambda ベースのワークロードのレジリエンスをテストするための新機能をデモし、これらの障害がどのように構築され、内部で実行されるかを解説します。また、モダンなサーバーレスアプリケーションに関する顧客経験から得られた貴重な知見も提供いたします。 レジリエントなアプリケーションの構築と運用 シングル AZ、マルチ AZ、マルチリージョンアーキテクチャ全体でアプリケーションのレジリエンスを最大化するための戦略を探ります。自動復旧メカニズムを活用してダウンタイムを最小限に抑える効果的な手法や、障害から迅速に復旧するための戦略をご紹介します。また、アプリケーションが業界標準や規制に準拠するための実践的なガイダンスも提供します。 ブレイクアウトセッション Building resilient multi-Region applications with Capital One ( ARC404 ) 組織は、大規模なマルチリージョンアプリケーションで予測可能な回復時間を達成し、一貫性を維持することに大きな課題を抱えています。Application Recovery Controller (ARC)、Aurora DSQL、Dynamo DB Multi-Region Strong Consistency を使用して、明確な復旧目標を持つレジリエントなアーキテクチャを作成する方法を学びます。実世界の実装パターンを通じて、ARC Region switchとAWS Fault Injection Service がメンテナンスとテストのアプローチをどのように変革するかをご紹介します。このエキスパートレベルのセッションでは、予測可能な回復と一貫した運用を提供するマルチリージョンアプリケーションを設計するための実践的な戦略を提供します。 Multi-Region disaster recovery & resilience testing (feat. Fidelity) ( COP358 ) AWS のイノベーションが、エンタープライズ規模の組織のディザスタリカバリ (DR) 戦略をどのように革新しているかをご紹介します。AWS リージョン全体で数千のアプリケーションを管理するには、高度な DR 機能が必要ですが、従来は複雑でリソース集約的なカスタム開発が求められていました。Fidelity が、Amazon Application Recovery Controller の Region switch 機能によるマルチリージョン復旧オーケストレーション、ライブダッシュボード、レポート機能を活用して、8,500 のミッションクリティカルなアプリケーションの DR をどのように変革したかを学びます。さらに、AWS Fault Injection Service と組み合わせることで、Fidelity は現実的な条件下で復旧手順を検証し、DR プランへの信頼性を高めています。AWS が企業のインフラ運用のモダナイゼーション、コンプライアンスの向上、ミッションクリティカルなアプリケーションの事業継続性の強化をどのように実現しているかをご覧ください。 Architecting resilient multicloud operations, feat. Monzo Bank ( HMC201 ) 組織がレジリエンスのニーズに対応するためにマルチクラウド戦略を選択する際、データの一貫性、サービスの分離、長期的なテストと保守といった領域で課題に直面することがよくあります。このセッションでは、運用レジリエンスに対する実用的で効率的なアプローチを提供する戦略的マルチクラウドアーキテクチャを実装した、Monzo Bank のレジリエンスへの取り組みについて学びます。主要な AWS インフラストラクチャと並行して、別のクラウドプロバイダー上で重要な銀行サービスを実行する Monzo の Stand-in Platform について詳しく掘り下げます。サービスの可用性を維持し、データ整合性のトレードオフを管理し、レジリエントなマルチクラウドアーキテクチャを実装するための実践的なパターンを学べます。 Cyber resilience on AWS, designing security and recovery strategies ( GBL204 ) サイバーレジリエンスとは、サイバー攻撃などの有害なイベントが発生しても、組織が意図した成果を継続的に提供できる能力のことです。サイバーレジリエンスとディザスタリカバリは、インシデント発生後に通常の運用を復旧するための計画と対応を含むという点で共通しています。サイバーレジリエンスは、より広範な戦略の一部としてディザスタリカバリを含んでいます。サイバーレジリエンスを設計する際には、下記の複数の重要なテーマがあります。 保護：システム、ネットワーク、データを保護するために講じる予防的措置 準備：サイバーインシデントに効果的に対応し、復旧できるよう組織を準備する活動 復旧：サイバーインシデント発生後、システム、ネットワーク、データを通常の状態に復元するための対応 チョークトークとビルダーズセッション Architecting multi-Region expansion for mission-critical workloads ( ARC322 ) ミッションクリティカルなアプリケーションを複数の AWS リージョンに拡張する際は、特に厳格な SLA 要件がある場合、綿密なアーキテクチャ計画が必要です。このチョークトークでは、マルチリージョン拡張における主要な設計上の考慮事項を探ります：サービスの可用性評価、安全なリージョン間接続の実装、信頼性の高い運用の確保。シナリオベースの共同演習を通じて、評価方法、ネットワークパターン、運用手順をマッピングする方法を学びます。ミッションクリティカルなワークロードの高可用性とパフォーマンスを維持するリージョン拡張プロジェクトのための、実践的なアーキテクチャ手法を習得できます。 Cell-based architectures: From connected vehicles to enterprise systems ( ARC327 ) コネクテッドビークルプラットフォームは、セルベースアーキテクチャが大量のデバイスアクセス、データ急増、レイテンシーに敏感なワークロードの課題をどのように解決するかを示しています。このアーキテクチャパターンが自動車分野を超えて、スマートカメラ、監視システム、ソーラー管理、SaaSプラットフォームをどのように変革するかを学びます。AWS IoT Core、Amazon MSK、Amazon EKS with Graviton、Amazon Aurora、Amazon Memory DB for Redis を使用した実践的な例を通じて、障害分離、スケーラブルなデプロイ、ローカライズされたエッジサービスの実装方法をご紹介します。このセッションでは、多様な業界にわたって大規模なパフォーマンスを維持するレジリエントなコネクテッドシステムを構築するためのアーキテクチャパターンを提供します。 A practical guide for meeting regulatory resilience requirements ( COP210 ) 世界中の組織は、DORA、NIS2、RegSCI などの規制要件を満たすために、運用レジリエンスを実証する必要があります。これらの規制は、組織が中断を防ぎ事業継続性を維持するためのインシデント検知とディザスタリカバリ計画を備えていることを保証することを目的としています。このチョークトークでは、金融サービスやヘルスケアなどの規制業界において、AWS サービスを使用してコンプライアンスを評価し証明する方法を学びます。D-CAT ツール、AWS Fault Injection Service の実験レポート、AWS Resilience Hub のレジリエンス評価、Amazon Application Recovery Controller のライブダッシュボードの実践的な活用方法を探り、規制への準備状況を評価し文書化する方法をご紹介します。 AWS disaster recovery strategies ( COP302 ) このディザスタリカバリ (DR) ビルダーズセッションで、予期せぬ事態に備えましょう。ビジネスの復旧目標に沿った DR 戦略を実装するアプリケーションに取り組みます。バックアップと復元、パイロットライト、ウォームスタンバイ、または AWS Elastic Disaster Recovery (AWS DRS)、Amazon Aurora、Amazon S3、Amazon EC2、AWS CloudFront、AWS DRS、AWS Fault Injection Service、AWS Backup などのアプローチ、サービスを取り上げます。また、選択したアプローチをテストし検証する方法も探ります。ビジネスに適した DR 戦略を構築するための実践的な知見を習得できます。 Financial services multi-Region design patterns and best practices ( IND317 ) AWS 上で金融サービス向けのレジリエントなマルチリージョンデプロイメントを構築するための実証済みのアーキテクチャパターンと設計原則をご紹介します。Amazon Application Recovery Controller、Amazon Aurora DSQL、Amazon Dynamo DB Multi-Region 強整合性などの専門的な AWS サービスを活用して、堅牢なグローバルソリューションを構築するための実践的な知見を得られます。マルチリージョンデプロイメントに伴うトレードオフを包括的に理解し、組織固有の要件に対して信頼性、パフォーマンス、コストのバランスを取った、情報に基づいたアーキテクチャ上の意思決定を行う能力を習得できます。 ワークショップ Building and testing resilient multi-AZ applications ( ARC304 ) レジリエントなマルチ AZ アプリケーションの構築とテストの実践的な経験を獲得できます。包括的なヘルスモニタリングのために、Amazon CloudWatch ダッシュボード、インサイトルール、複合アラームの使用方法を学びます。AWS Fault Injection Service を使用してランダムな障害を注入し、さまざまなシングル AZ 障害をシミュレートする練習を行います。AWS CodeDeploy を使用したゾーンデプロイメントを習得し、現実的な障害シナリオを体験します。Amazon Application Recovery Controller のゾーンシフト機能を活用して、障害から復旧し顧客体験を維持する方法を探ります。このワークショップでは、AWS 上で高可用性システムを設計し運用するための実践的なスキルを提供します。 From downtime to uptime: Mastering application recovery on AWS ( ARC307 ) AWS 上でアプリケーションのレジリエンスを強化するための、Amazon Application Recovery Controller (ARC) の最新機能を習得します。ハンズオン演習を通じて、自動復旧ワークフローの実装、復旧計画のテスト、大規模な復旧オペレーションの監視方法を学びます。エンタープライズのレジリエンス要件に沿った復旧ソリューションの設計と管理における実践的なスキルを構築します。このワークショップでは、高度な復旧アーキテクチャを通じて事業継続性を確保するための実証済みのパターンを、クラウドアーキテクトと DevOps エンジニアに提供します。 Building resilient architectures with observability ( COP408 ) 重要なシステムに障害が発生すると、ダウンタイム1分毎に金銭的損失と信頼の喪失が発生します。このハンズオンワークショップで、アプリケーションをレジリエントで可観測性の高いシステムに変革しましょう。カオスエンジニアリングを通じてレジリエンスを強化し、AWS Fault Injection Service で障害を注入してアベイラビリティーゾーンの障害、ネットワークの問題、デプロイメントの問題をシミュレートします。Amazon CloudWatch と Amazon Application Recovery Controller を活用して、障害を検知、診断し、自動的に復旧する方法を学びます。実際の条件下でも可観測性とレジリエンスを維持するアプリケーションを構築する実践的な経験を習得できます。 レジリエンス文化の醸成 運用準備レビュー (Operational Readiness Reviews (ORR) )、レジリエンステスト、根本原因分析 (Root Cause Analysis (RCA) ) 、ゲームデイシナリオを通じて、開発サイクルの早い段階でレジリエンスを統合する方法を学びます。金銭的損失を伴うダウンタイムを防ぐのに役立つ、効果的で安全なデプロイメントプラクティスと堅牢なオブザーバビリティ戦略を構築するための技術を探ります。 ブレイクアウトセッション Mastering Root Cause Analysis: Rebuilding trust after outages ( ARC211 ) 障害の調査は困難ですが、それを顧客に効果的に説明することはさらに大きな課題です。根本原因分析 (Root Cause Analysis (RCA) ) ドキュメントは、理解を示し、責任を明確にし、不足点に対処する計画を提示することで信頼を再構築する唯一の機会となることがよくあります。10 年以上にわたる効果的な RCA 作成の経験から、透明性を保ちながら複雑性、カスタムソフトウェア、社内用語を乗り越えるための実践的な戦略を学びます。ISV や SaaS プロバイダーの方は、何が起こったのか、なぜ起こったのかを説明し、確実な改善計画を示す洞察に富んだ RCA を作成する手法をご紹介します。 The incident is over: Now what? ( COP216 ) 最適な運用プラクティスは、避けられないインシデントへの対処方法と迅速な復旧方法を定義します。では、その後はどうでしょうか？真の根本原因を突き止め、効果的な予防措置の実施を計画するにはどうすればよいでしょうか？すべてのインシデントを組織全体の学習機会に変えるにはどうすればよいでしょうか？責任共有モデルやサードパーティソフトウェアベンダーはどのように関わってくるのでしょうか？ 根本原因分析 (Root Cause Analysis) と Correction of Error (COE) に関する私たちの思考モデルと数十年にわたる経験を共有しますので、皆様の組織で効果的なプラクティスを推進できるようになります。 チョークトーク、コードトーク、ビルダーズセッション Operational excellence: Building resilient systems ( ARC316 ) このチョークトークでは、運用プラクティスとシステムレジリエンスの重要な関係を探ります。ロギング、ヘルスチェック、デプロイメント戦略などの基本的な要素が、AWS 上のアプリケーションの信頼性にどのように影響するかを検証します。実際のシナリオを通じて、システムの可用性を損なう一般的な運用上の落とし穴を発見し、Well-Architected の原則に沿った実践的な解決策を学びます。アーキテクチャのレジリエンスを強化し、運用上の優秀性を高めるための実証済みのアプローチを学びます。このインタラクティブなセッションでは、堅牢なクラウドシステムを構築し維持するための実践的なパターンを、アーキテクトとオペレーターに提供します。 Agent down! Building unbreakable AI workflows ( COP321 ) このチョークトークで、カオスエンジニアリング (レジリエンステスト) の原則が自律型 AI エージェントワークフローにどのように適用されるかをご紹介します。AWS Fault Injection Service を使用して、複雑なマルチステップタスクを処理するエージェントベースのシステムをストレステストする方法を学びます。意思決定ループ、タスクの引き継ぎ失敗、リソース調整の崩壊など、エージェント AI 特有の障害モードを特定および軽減する方法をご紹介します。オーケストレーション層、メモリシステム、ツールの相互作用全体でエージェントのレジリエンスを検証する実験を設計する練習をします。自律型 AI ワークフローを構築または維持しているチームに最適なこのチョークトークは、エージェント駆動型アーキテクチャのレジリエンスを向上させるための実践的な技術を提供します。 Streamline operations with automated health monitoring and response ( COP343 ) AWS 環境が複雑化するにつれて、組織は健全なインフラストラクチャの可視性を維持し、インシデントに対応することに課題を抱えています。このチョークトークでは、AWS Health と Amazon CloudWatch を使用して、包括的なヘルスモニタリングと自動化されたインシデント対応を構築する方法を学びます。Systems Manager Automation を使用した修復の実装、効果的なモニタリングパターンの作成、メトリクスをアクションに変換する実践的な内容を体験できます。クロスアカウントヘルスダッシュボード、インテリジェントなアラート、自動対応ランブックの実践的なアプローチを習得できます。 Downtime prevention with the Resilience Lifecycle Framework ( COP357 ) ほとんどのシステム障害は人的エラー、コードデプロイメントの問題、システムの設定ミスに起因するため、リスクを事前に軽減し、レジリエンス計画を実践し、運用インシデントの再発を防ぐためのフレームワークを整備することが重要です。このチョークトークでは、長年にわたるお客様や社内チームとの協働に基づき、レジリエンスのベストプラクティスを集約した包括的なアプローチである AWS レジリエンライフサイクルフレームワーク の適用方法を学びます。目標設定、レジリエンスを考慮した設計、レジリエンステスト、運用準備レビュー (Operational Readiness Reviews (ORR) ) の実施、インシデント分析レポートの作成など、重要なワークロードのレジリエンス態勢を強化するための実践的な戦略を習得できます。 Build resilient SaaS: Multi-account resilience testing patterns ( ISV404 ) エンタープライズ SaaS プロバイダーは、テナント境界を越えて障害が拡散するのを防ぎながら、高可用性を維持するという課題に直面しています。主要な ISV が、AWS Fault Injection Service を使用して、制御されたレジリエンステスト実験を通じてマルチテナントアーキテクチャのレジリエンスを検証する方法を学びます。厳格なテナント分離を維持しながらクロスアカウント障害シナリオをテストする、セキュリティおよび HR テクノロジープロバイダーの実例をご紹介します。顧客の可用性を損なうことなく、SaaS アーキテクチャを強化するレジリエンステストを実装するためのパターンをご紹介します。 ワークショップ Chaos engineering workshop ( COP304 ) このワークショップでは、カオスエンジニアリングとも呼ばれるレジリエンス実験を実行するための AWS Fault Injection Service (FIS) を紹介します。障害を注入し、電源中断やリージョン間接続の問題などのテストシナリオを適用して、Amazon EKS、Amazon ECS、AWS Fargate、Amazon EC2、Amazon S3、Amazon RDS などのサービスの動作にどのような影響を与えるかを確認する方法を学びます。また、規制業界でのコンプライアンスに必要な実験レポートの作成方法も学びます。さらに、Amazon CloudWatch、AWS X-Ray、Amazon CloudWatch RUM を使用して、実験から重要なインサイトを得る方法も学びます。 本ブログは Partner Solutions Architect の 石倉 徹が翻訳しました。原文は こちら です。 Vanessa Au Vanessa Auは、AWS のシニアプロダクトマーケティングマネージャーです。Amazon での 8 年以上の経験とワシントン大学でのコミュニケーション学博士号を持ち、インパクトの高いプロダクトローンチの実行と、データとストーリーテリングを活用してお客様が AWS を使用してレジリエントなアプリケーションを構築する方法を紹介することを専門としています。

2025 年 10 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS Black Belt Online Seminar 一覧 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon Aurora 機能編 – Aurora Global Database の詳細 Amazon Aurora Global Database では、複数の AWS リージョンにまたがり複数の Amazon Aurora Database クラスターを構成できます。大規模障害におけるデータベースの地理的冗長性や、ユーザーのアクセス元の地域近くにクラスターを配置し各地域から低いレイテンシーでのデータ読み取りを実現します。 こちらの動画では Amazon Aurora Global Database ついて紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されており、データベースの地理的冗長性に関心のある方 Amazon Aurora 及び Amazon Aurora Global Database の利用を検討中、または今後検討をご予定の⽅ Amazon Aurora Global Database の概要、他のレプリケーションソリューションとの違いを理解したい方 本 BlackBelt で学習できること Aurora Global Database に関する概要や切り替え動作など、主要機能や制限事項について学習いただけます。 スピーカー 石渡 嘉之 テクニカルアカウントマネージャー Amazon Aurora 運用実践編 – チューニングアプローチ AWS が提供するデータベースのマネージドサービスである Amazon Aurora のチューニングアプローチについてご紹介します。 データベースチューニングのための検知・分析に活用できるツールとして CloudWatch Database Insights ではデータベース全体の健全性を管理する包括的な機能を提供しています。 その他にも「CloudWatch」「拡張モニタリング」があります。 こちらの動画では、これらのモニタリングツールを使ってどのように分析していくかを待機イベントやデータベースロードについて説明しつつ、ご紹介させて頂きます。 資料（ PDF ） | 動画（ YouTube ） 対象者 データベースのクラウド移行を検討されている方 Amazon Aurora の利用を検討中、または今後検討をご予定の方 Amazon Aurora をご利用中で、チューニングを検討中の方 本 BlackBelt で学習できること Amazon Aurora においてチューニングを実施する際に活用できるツールについて学習できます。 スピーカー 河合 智彦 テクニカルアカウントマネージャー Amazon RDS 概要編 – RDS for DB2 概要 AWS が提供するデータベースのマネージドサービスである Amazon RDS 上で提供する RDS for Db2 の概要を説明します。RDS for Db2 での運用や高可用性構成の機能を紹介し、オンプレミス環境の Db2 から AWS 環境の RDS for Db2 へ移行した際の差異を運用面やデータベース環境面に沿って解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 オンプレミスや EC2 などで IBM Db2 Database を運用中の方 AWS で RDS for Db2 の利用を検討中、または今後検討予定の⽅ Amazon RDS for Db2 の概要、機能を押さえたい方 本 BlackBelt で学習できること RDS for Db2 の概要について学習いただけます。 スピーカー 野間 愛一郎 シニアソリューションアーキテクト Amazon RDS 概要編 – RDS for MariaDB 概要 AWS が提供するデータベースのマネージドサービスである Amazon RDS 上で、MariaDB の運用に際し発生する、高可用性の実現、バックアップ、レプリケーション構成などのセットアップ方法をはじめ、日々のデータベース運用を効率化する手法について、実務に即した具体的なソリューションをご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 オンプレミスや Amazon EC2 上などで MariaDB を運用中の方 Amazon RDS for MariaDB のご利用を検討されている方 Amazon RDS for MariaDB におけるデータベース運用の効率化に興味がある方 本 BlackBelt で学習できること RDS for MariaDB の概要について学習いただけます。 スピーカー 野沢 充彦 クラウドサポートエンジニア Amazon RDS 概要編 – RDS for Oracle 概要 Amazon RDS for Oracle は、Oracle Database を AWS 環境で利用できるマネージドサービスです。Multi-AZ の構成やバックアップ・リカバリ、パフォーマンス管理といった煩雑な DBA 作業を RDS の機能で担保できるため、DBA はアプリケーションの開発やデータモデリングに専念できるようになります。こちらの動画では Amazon RDS for Oracle の概要について紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 オンプレミスや EC2 などで Oracle Database を運用中の方 AWS で RDS for Oracle の利用を検討中、または今後検討予定の⽅ Amazon RDS for Oracle の概要、機能を押さえたい方 本 BlackBelt で学習できること RDS for Oracle の概要について学習いただけます。 スピーカー 松尾 亮 パートナーソリューション アーキテクト AWS Backup で考える DR 戦略 #2 PITR 編 AWS Backup で考える DR 戦略 #2 PITR 編 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Backup 基礎編を視聴いただいた方 AWS Backup の導入・運用において、以下の課題をお持ちの方： 頻繁に更新されるリソースの人為的ミス対策を強化したい より細かい精度でのバックアップ・復元が必要 厳格な RPO 要件でデータ損失を最小限に抑えたい AWS Backup でバックアップ・復元を実行されたことがある方 本 BlackBelt で学習できること AWS Backup における継続的バックアップとポイントインタイムリカバリについて紹介いたします。 スピーカー チャンクォックフォン クラウドサポートエンジニア 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2025-12 Amazon EKS x AWS アカウント アーキテクチャパターン ソリューションアーキテクト 後藤 健汰

みなさん、こんにちは。カスタマーソリューションマネージャーの西口です。2025 年 11 月 5 日に、AWS Japan が主催のコスト最適化関連イベントとなる、「AWS 秋の Cost Optimization 祭り 2025 〜最新アップデート＆メソッドと生成 AI × コスト最適化〜」を開催いたしました。ご参加いただきました皆様には、改めて御礼申し上げます。AWS Cost Optimization 祭りは去年に続き、2 回目のイベントとなります。去年の開催ブログはこちらです ( 2024秋 )。 本ブログでは、イベント内容概要の紹介とイベントの中で各登壇者が発表した資料を公開いたします。 イベント概要 「AWS 秋の Cost Optimization 祭り 2025」は、コスト最適化の最新アップデートやメソッド、生成 AI ×コスト最適化を学ぶイベントです。約70名のお客様にご参加いただき、約2時間にわたるイベントとなりました。 前半セッションでは、AWS の FinOps 最新情報セッションとしてコスト最適化フレームワークや CFM Tips 、生成 AI とコスト最適化の最新傾向をご紹介しました。続く生成 AI ×コスト最適化に関するセッションでは、具体的な例として、 Amazon Q Developer の活用方法や Well-Architected Framework Review と生成 AI を組み合わせたアプローチを解説しました。 後半セッションでは、実際のシステム開発や運用ノウハウとして、 Amazon ECS と Amazon Aurora のコスト最適化に向けたポイントや技術的アプローチについて、実践的な知見を共有しました。 各セッションの概要と発表資料は以下をご覧ください。 セッション紹介 AWS の FinOps、およびコスト最適化に関する今年のアップデート 発表資料： AWS_秋のCostOptimization祭り2025_1_AWSFinOpsコスト最適化アップデート まず、テクニカルアカウントマネージャーの堀沢から、AWS の FinOps およびコスト最適化に関する最新動向を紹介しました。FinOps とは、クラウドから得られる価値を最大化するために、組織全体が協力してデータに基づいたコスト最適化を行う取り組みです。AWS では Cloud Financial Management (CFM) というフレームワークを通じて、「可視化」「最適化」「計画・予測」「FinOps の実践」という4つの柱に沿った活動を推進しています。　2025年には、コスト最適化のための実践的なベストプラクティス集である CFM Tips の日本語対応や、自然言語でのコスト分析を可能にする MCP Server の導入、 AWS Cost Explorer での任意の2か月間のコスト比較機能など、AI 技術を活用した新機能が追加され、より効率的なコスト最適化が可能になっていることをお伝えしました。 Accelerating your FinOps with Amazon Q Developer 発表資料： AWS_秋のCostOptimization祭り2025_2_FinOpswithAmazonQDeveloper 次のセッションでは、テクニカルアカウントマネージャーの加須屋より、Amazon Q Developer を活用した FinOps の効率化と加速について解説しました。近年、FinOps の適用範囲が拡大し、AI 関連のコスト管理 (FinOps for AI) や AI を活用したコスト管理 (AI for FinOps) の重要性が高まっています。Amazon Q Developer は、コスト分析作業の効率を大幅に向上させるだけでなく、CFM フレームワークの「可視化」「最適化」「計画・予測」「FinOps の実践」の各領域で活用可能です。具体例として、AI を活用したダッシュボードの自動生成、FinOps の知識ベース構築、コスト最適化ドキュメントの分析などが紹介され、これらを通じて FinOps 全体の加速が実現できることを示しました。また、実際のデモンストレーションも実施したため、会場でご参加の皆様は具体的イメージが湧きやすかったのではないかと思います。 Context-aware cost optimization〜Gen AI x Well-Architected Framework Review〜 発表資料： AWS_秋のCostOptimization祭り2025_3_Context-awarecostoptimization 前半最後のセッションでは、テクニカルアカウントマネージャーの三田より、Well-Architected Framework Review (WAFR) を生成 AI で効率化する手法を紹介しました。コスト最適化において、明示的なコストだけでなく暗黙的なコスト (可用性不足、技術的負債など) も含めたトレードオフを考慮することが重要です。従来の WAFR は時間がかかり、範囲が限定的で一時点の評価になりがちという課題がありましたが、 Well-Architected IaC Analyzer を使用することで、数時間かかっていたレビューを数分に短縮できます。さらに、Amazon Q Developer などを活用してコンテキスト (背景情報) を生成・追加することで、より適切にトレードオフの判断が可能になり、効果的なコスト最適化を実現できることを示しました。 コンテナに移行したらコストが増えた！？ ECS のコスト最適化に向けて改めて確認したいポイント 発表資料： AWS_秋のCostOptimization祭り2025_4_ECSコスト最適化 後半の最初のセッションでは、ソリューションアーキテクトの東より、Amazon ECS のコスト最適化に関するポイントを示しました。ECS ではいくつかのコスト最適化のポイントがありますが、本セッションでは特に ①スケーリングポリシーの最適化 (カスタムメトリクスや Metrics Math の活用)、②イメージサイズの最適化 (マルチステージビルドを含む Dockerfile 記述の Tips)、③ロギング戦略の見直し ( FireLens を用いたログの振り分け)、④Capacity Provider の見直し (Spot インスタンスのフォールバックを含んだ活用例)、⑤継続的なタスクサイズの見直し ( Container Insights の活用) を取り上げています。また、新たに登場した ECS Managed Instance という選択肢についても触れ、 AWS Fargate と Amazon EC2 のメリットを両立できる新しいオプションとして紹介しました。上記に添付した資料内には当日の時間の関係上、触れられなかった内容も記載してあります。是非ダウンロードしてご覧ください。 Aurora のコスト構造を理解して最適化 〜技術的アプローチと実践〜 発表資料： AWS_秋のCostOptimization祭り2025_5_Auroraコスト最適化 最後のセッションでは、シニアテクニカルアカウントマネージャーの西原より、Amazon Aurora のコスト最適化を説明しました。Aurora のコスト最適化では Aurora のコスト構造を踏まえて Cost Explorer でコストの内訳を把握し、ワークロードに応じた最適な構成を選択することが重要です。コスト最適化の主な方法として、インスタンスのダウンサイジングやタイプの変更、リザーブドインスタンスの購入、未使用クラスタの停止などのインスタンス最適化があります。また、I/O コストが全体の 25% を超える場合は I/O 最適化インスタンスへの移行を検討することや、変動の大きいワークロードや開発環境向けには Aurora Serverless v2 の活用が効果的であり、リーダーインスタンスやセカンダリリージョンに Serverless v2 を採用する混在環境での利用も可能であることを紹介しました。 まとめ 本イベントでは、AWS FinOps の最新情報や生成 AI を使ったコスト最適化のアプローチ、ECS と Aurora のコスト最適化方法を紹介しました。本イベントにより、クラウドサービスをムダなく使いこなして、スマートに費用を抑えるコツを身につけて頂けますと幸いです。クラウドではコスト最適化に終わりはなく継続して実施することが重要です。今後もこのようなイベントを通じて、AWS からコスト最適化の情報発信を継続していきます。 本ブログは、シニアカスタマーソリューションマネージャーの西口、シニアテクニカルアカウントマネージャーの石王により執筆いたしました。

みなさん、こんにちは。AWS ソリューションアーキテクトの古屋です。 近年、生成 AI 技術は急速な進化を遂げ、ビジネスや社会のあらゆる領域に変革をもたらしています。テキスト生成から画像作成、音声合成、コード開発支援まで、その応用範囲は日々拡大しており、多くの産業で業務効率化や新たな価値創造が実現されています。特に注目すべきは、専門性の高い領域や業界においても、生成 AI が人間の専門家を支援し、これまで解決が困難だった課題に新たなアプローチをもたらしている点です。 そのような中で、医療機器業界では、品質管理システム（QMS）の運用に関わる業務負担が大きく、人手不足が深刻な課題となっています。特に厳格な規制要件への対応や膨大な文書管理、品質イベント処理などは、多くの医療機器メーカーにとって大きな負担となっています。 今回は、この課題に着目し、AWS の生成 AI 技術である Amazon Bedrock を活用して革新的なソリューションを開発された 株式会社 Berry 様の事例をご紹介します。 Berry 様の状況と経緯 医療機器メーカーの株式会社 Berry 様は、自社での経験をもとに、品質管理業務を効率化するクラウド型 eQMS（電子品質管理システム）「 QMSmart 」を提供しています。QMSmart は、QMS 活動に必須とされる文書管理、品質イベント管理、教育訓練の機能を一気通貫で提供し、医療機器メーカーの品質管理業務を支援しています。 医療機器業界では、QMS 省令や ISO 13485 などの厳格な規制要件に準拠した品質管理が求められます。しかしながら、従来の QMS 運用では、以下の課題が存在していました。 ・医療機器特有の規制要件や品質管理手法の習得に時間がかかり、新人教育が困難 ・文書管理における不正確な情報や属人的な原因分析、進捗管理の不透明さ ・紙ベースの文書管理や Excel を使った進捗管理による業務の非効率性 これらの課題を解決するため、Berry 様は医療機器メーカーとしての経験に加え、様々なケースに対応できるよう 50 社以上の医療機器メーカーへヒアリングを行いながら AI 技術を活用したより付加価値の高い機能を開発しました。 しかし、AI 技術の導入にあたっては、いくつかの技術的な懸念がありました。医療機器という専門性の高い分野では、RAG（Retrieval-Augmented Generation）や基盤モデルのファインチューニングが必要ではないか、といった技術的ハードルを感じていらっしゃいました。また、医療機器業界の機密性の高い情報を AI で処理することへの安全性に対する懸念もありました。 このような状況の中で、Berry 様が AWS を選択された理由は次の通りです。まず、長期間にわたり AWS の各種サービスを活用してきた実績があり、その信頼性と安定性を評価されていました。既存の AWS 環境との親和性が高く、統一されたプラットフォームで開発・運用できることは、学習コストや運用コストの面で大きなメリットとなります。 また、AWS のサービスはデータ連携の親和性が高く、既存のデータベースやストレージサービスとの統合が容易です。さらに重要だったのが、セキュリティ面での信頼性です。Amazon Bedrock では、医療機器業界で求められる高いセキュリティレベルを満たしながら、安全に AI を活用できる環境を構築できます。特に Amazon Bedrock の Guardrails 機能により、プロンプトインジェクションなどの新たな攻撃手法に対しても、デフォルトの設定で十分な防御効果が得られることが後の検証で確認しました。 これらの要素が揃っていたことで、Berry 様は AWS 上で生成 AI を活用した QMS ソリューションの開発を進めることを決定しました。 ソリューション／構成内容 QMSmart の AI 機能は、インフラストラクチャの管理・運用負荷の少ないマネージドサービスで構成されています。システム構成は、QMSmart から Amazon Bedrock の基盤モデルを呼び出してレスポンスを受け取る形で実現されています。 QMSmart は、上述の課題に対し、Amazon Bedrock を活用して 3 つの AI 機能を実装しました。苦情発生から分析、CAPA（是正・予防措置）、改訂、教育まで一気通貫したプロセスの全てに AI サービスを組み込んでいます。 / ・AI 文章チェック機能 QMS 省令、ISO 13485 などの規制要件に対する文書の適合性を自動で判定し、不足している項目や改善箇所を具体的に指摘します。経験の浅い担当者でも規制対応が可能になります。 ・AI 根本原因分析支援機能 苦情報告や不適合事象が発生した際、AI によりユーザーがこれまでに登録した事例データベースから関連する事例を抽出し、パターン分析を行います。さらに「なぜなぜ分析」を支援することで根本原因まで効率的に深堀りします。実効性の高い是正措置・予防措置（CAPA）を提案し、品質問題の再発防止を実現します。 ・AI テスト生成機能 FDA 通知などの任意の文書から理解度測定のためのテスト問題を自動生成します。英文の規制文書から日本語のテスト問題を生成することも可能で、教育資料の作成時間を半日から 15 分に短縮します。 これらの機能は全て Amazon Bedrock の高度な言語理解能力と、医療機器業界特有の知識を組み合わせることで実現しています。また、当初、Berry 様では医療機器という専門性の高い分野での AI 活用には、RAG やファインチューニングが必要だと考え、検証を進めていました。しかし、Amazon Bedrock での検証を通じて、InvokeModel 実行時のシステムプロンプトの工夫により、医療機器に関して的を絞った回答を生成できることを検証で確認したことから、現行の構成に至りました。 導入効果 Amazon Bedrock を導入することで以下の2つの効果が得られました。 Berry 様側の効果 医療機器の品質管理、製造管理に関する専門的視点を組み込んだプロンプトテンプレートを実装することで、効率的なリクエスト作成と高品質な回答の取得を実現しています。これにより、RAG を使った検証に約 1 か月を要していたところを、システムプロンプトの工夫に切り替えることで、以降の開発期間を約一週間に短縮できました。 QMSmart の導入によるBerry 様の顧客企業での効果 属人的だった QMS 業務の標準化と透明性が向上し、AI 支援による意思決定の質と一貫性が高まることで、規制対応の確実性と監査対応の容易さが実現されました。 ・規制適合性の自動チェックにより業務効率を 50% 向上 ・教育資料の作成時間を半日から 15 分に短縮 ・AI による根本原因分析支援で迅速かつ的確な処置案を導出 なお、現存の AI 機能の他にも、Amazon Bedrock を活用した新機能の開発も進められており、今後もユーザーの利便性向上のために生成 AI の活用の加速が見込まれます。 お客様の声 株式会社 Berry 様からは、以下のようなコメントをいただいています。 「Amazon Bedrock を活用した AI 機能の導入により、これまで専門性が高すぎて AI では対応できないと思っていた医療機器の QMS 業務が、プロンプトエンジニアリングだけで実現できることがわかりました。特に Guardrails 機能により、医療機器業界で求められる高いセキュリティレベルを確保しながら、安心して AI を活用できるようになりました。複数のモデルを比較検証できることや、モデルの切り替え検証ができることの重要性を実感しています。変化に追随しやすいという点が、Amazon Bedrock の大きなメリットです。 開発者が体験している AI による恩恵を QMS 業務をしている人たちにも感じてもらえるようになり、業界全体の生産性向上に貢献できることを嬉しく思っています。今後は、このシステムをベースにさらなる機能拡張を計画しており、医療機器業界全体の品質管理業務の効率化に貢献していきます。」 まとめ 今回は AWS の生成 AI サービスである Amazon Bedrock を活用し、医療機器業界の QMS 業務を効率化するBerry 様の取り組みについてご紹介しました。本事例は、生成 AI の高度な言語理解能力と専門知識を組み合わせることで、規制産業における複雑な業務プロセスを改善した例です。 「AI で医療機器メーカーの人手不足を解消し、安全で高品質な医療機器の開発・製造を支援する」というビジョンのもと、Berry 様は医療機器業界の品質管理に革新をもたらしています。QMSmart は、AWS の生成 AI 技術を活用することで、医療機器業界における QMS 業務の効率化と品質向上を同時に実現しています。 人手不足が深刻化する中、AI による業務支援は今後ますます重要になるでしょう。Berry 様の取り組みは、規制産業における生成 AI 活用の先進的な事例として、多くの企業に参考になるものと考えられます。Amazon Bedrock を利用した生成 AI の活用にご興味をお持ちのお客様は、ぜひ AWS までお問い合わせください 。 ソリューションアーキテクト　古屋　楓　　 アカウントマネージャー 　ク　シイ

急速に進化するエンタープライズソフトウェアの世界において、SAP の Cloud Application Programming Model (CAP) は、Python、Node.js、Core Data Services (CDS) を使用してエンタープライズクラウドサービスとアプリケーションを開発するためのベストプラクティスを提供します。CAP は、カスタム開発の柔軟性を維持しながら SAP の広範なエコシステムと簡単に統合できる、アジャイルでマイクロサービスベースのアーキテクチャの需要の高まりに対応するフレームワークを提供します。このブログでは、Amazon Q Developer が CAP 開発をどのように加速するかを探り、ABAP コードベースのモダナイゼーションに関する 前回のブログ に基づいて説明します。SAP 開発における根本的な課題の一つは、進化するビジネス要件を満たしながらクリーンなコアシステムを維持することです。CAP は、コアを変更することなく SAP システムと統合するカスタムアプリケーションを開発できるサイドバイサイド拡張を通じてこの課題に対処します。このアプローチにより、システムの安定性が確保され、アップグレードが簡素化され、技術的負債が削減される一方で、迅速なイノベーションが可能になります。開発の合理化と統合の簡素化における CAP の利点にもかかわらず、多くの開発者、特に従来の SAP 開発パラダイムに慣れ親しんだ開発者にとって、移行は困難です。ここで Amazon Q Developer が CAP 開発体験を変革するのに役立ちます。Amazon Q Developer は、CAP の複雑さを理解するだけでなく、コンセプトから本番対応アプリケーションまでの開発プロセス全体をガイドできる AI コンパニオンです。これこそが Amazon Q Developer が SAP CAP 開発の領域で行うことです。この知的アシスタントがクラウドアプリケーションの構築方法をどのように可能にし、CAP 開発をあらゆるスキルレベルの開発者にとってアクセスしやすく、効率的で、さらには楽しいものにするかを探ってみましょう。Amazon Q Developer は、SAP Business Application Studio (BAS) の Web バージョンで拡張機能として利用できます。Visual Studio Code ユーザーの場合は、BAS 拡張機能がインストールされ、リモート SAP BTP アカウントに接続されていることを確認してください。AWS Builder ID を使用して Amazon Q Developer の無料ティアにサインインするには、この ユーザーガイド の VS Code セクションに従ってください。 AI を活用した開発ジャーニー CAP を使用してベンダー管理システムを作成するタスクを担当するシナリオを考えてみましょう。プロジェクト構造の設定、依存関係の構成、ボイラープレートコードの記述に時間を費やす代わりに、次のような会話型プロンプトを通じて Amazon Q Developer とビジョンを共有するだけです： 「私は『vendor details app』というプロジェクトを持っています。すべての指示に従ってください。サンプル CSV データを使用してベンダー（ベンダーモデル）を表示するデモ SAP CAP アプリケーションを作成したいと思います。アノテーションとサービス定義も作成してください。データ永続化のために SQLite にデプロイし、テーブルが作成され、ダミーデータが正常に作成されたことを確認してください。完了したら、モデル、データ、サービスを確認できるように私の指示を待ってください。作成したアノテーションを使用してベンダーを表示する Fiori リストページを使用して UI を作成する予定なので、UI は作成しないでください。」 Amazon Q Developer の主要な機能は、単一の自由な会話で多層的で複雑な指示を処理する方法です。このプロンプトは、アプリケーションのセットアップ、サービス定義、データモデリング、アノテーション作成、さらにはサンプルデータ生成を同時に要求しながら、UI 開発など行わないことについて明確な境界を設定する方法を示しています。フルスタック開発ワークフローのこの包括的な理解により、開発者は段階的な指示ではなく戦略的目標に集中できます。 Amazon Q Developer を際立たせるのは、そのエージェント的な性質です。コマンドに応答するだけでなく、開発プロセスに積極的に参加します。コンテキストを理解し、改善を提案したり潜在的な問題を特定したりするイニシアチブを取ることができます。このプロアクティブなアプローチと、コマンドを実行するためのターミナルへの直接アクセスにより、真の開発パートナーとなります。 プロセスが展開されるにつれて、Amazon Q Developer は、明示的なフィールドごとの仕様を必要とせずに、最も関連性の高いフィールドを自律的に決定し、データベースモデルを自律的に設計することで、ビジネスコンテキストの知的理解を実証します。サービス層の確立にシームレスに移行し、UI と RESTful エンドポイントの適切なアノテーションを作成します。 上記のプロンプトに基づいて、Amazon Q Developer の動作を見てみましょう。このデモンストレーションでは、プロジェクトの初期化から機能するアプリケーションまでの開発ジャーニー全体を目撃します。 主要なアノテーション： プロジェクト構造の初期化 ベンダーフィールドを使用した自動モデル生成 データフォルダーと CSV 作成 アノテーション付きサービス定義 データベースデプロイメントとデータ挿入 検索機能付きアプリケーションプレビュー このデモンストレーションの詳細な表示については、GIF を右クリックして新しいタブで開いてください コード生成を超える機能 Amazon Q Developer の機能は、コードの信頼性と保守性を確保するソフトウェア開発の重要な側面であるテストにまで及びます。単体テストは、統合前に各コンポーネントが分離して正しく機能することを確保し、信頼性の高いソフトウェア開発の基盤を形成します。 Amazon Q Developer は、シンプルなプロンプトを包括的なテスト戦略に変換します。 「jest を使用してテストケースを作成し、それらも実行できますか」 明示的な指示なしに、すべてのアーキテクチャ層でアプリケーションを検証する必要性を本質的に理解します： データモデルテスト：基盤レベルでのデータ整合性の確保 サービス層テスト：ビジネスロジックと操作の検証 API 統合テスト：エンドツーエンド機能の確認 テスト失敗時にエラーを報告するだけでなく、Amazon Q Developer は分析、適応、ソリューションの実装を行います。自律的な自己修復機能とコマンド実行のための統合ターミナルアクセスを通じて、従来のデバッグをインタラクティブでガイド付きのプロセスに変換します。新しいテストケースを生成するだけでなく、既存のコードのテストをリバースエンジニアリングし、レガシー（現状）と新しいコンポーネント（将来）の両方で包括的なカバレッジを確保できます。包括的なテストパートナーとして、Amazon Q Developer は詳細なカバレッジレポートとインテリジェントなエラー分析を提供し、根本原因を自動的に特定し、修正を実装します。 Amazon Q Developer がテストプロセスをどのように合理化し、複雑なテストシナリオを自律的に処理する能力を実証するかをご覧ください。 主要なアノテーション： ベンダーモデル用の異なるテストケース生成 自動エラー検出と修正 包括的なテスト実行 結果分析とレポート このデモンストレーションの詳細な表示については、GIF を右クリックして新しいタブで開いてください 開発の最も軽視されがちな側面であるドキュメンテーションが、Amazon Q Developer によって開発プロセスの不可欠な部分になります。印象的なのは、シンプルなプロンプトが包括的なドキュメンテーション戦略をトリガーする方法です。現代のアプリケーションには基本的なセットアップ指示以上のものが必要であることを本質的に理解しています。 「README ファイルを作成してください」 Amazon Q Developer がドキュメンテーションプロセスを、別の遅延したタスクではなく、開発ワークフローの不可欠な部分に変換する方法をご覧ください。 主要なアノテーション： README ファイル生成 – プロジェクトセットアップ、前提条件、構成手順 UI アノテーションガイド – Fiori レンダリング API ドキュメンテーション – サービスエンドポイント、メソッド、統合詳細 開発拡張ガイド – 機能のカスタマイズと拡張のガイドライン テスト強化ガイドライン – テストカバレッジ要件と強化アプローチ このデモンストレーションの詳細な表示については、GIF を右クリックして新しいタブで開いてください SAP クラウド開発の未来を支援 開発者がビジネス要件と革新的な機能に集中している間、Amazon Q Developer は CAP 実装の詳細の重い作業を処理します。新しい機能を追加したり、構築したばかりのベンダーアプリケーションを Cloud Foundry にデプロイしたりする必要がありますか？会話形式で説明するだけで、Amazon Q Developer がコンテキストを理解し、必要なコマンドを実行し、デプロイメント構成を作成し、SAP システム接続を確立し、Cloud Connector、Cloud Foundry 組織とスペースなどの必要な詳細を求めて、すべてのステップで手を取ってガイドしてくれます。 ブログをお読みいただき、ありがとうございました。Amazon Q Developer を CAP 開発ワークフローに組み込んでモダナイゼーションジャーニーを開始し、即座の利益を体験してください。詳細については、 ドキュメンテーション をご覧いただき、今すぐ Amazon Q Developer の無料ティアをお試しください。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

はじめに すべての企業は、開発者の生産性向上、アプリケーションのより高速な構築、レガシーコードの保守負担の軽減を支援する方法を模索しています。Amazon Q Developer は、企業が高度にカスタマイズされた SAP 環境に関連する技術的負債を解消し、新機能をより迅速に提供するのに役立つ生成 AI ツールです。このブログでは、Amazon Q Developer を使用して SAP 開発者の生産性向上とより迅速なイノベーションを支援する方法について説明します。SAP は、世界中の数千の企業のビジネス運営を支えるミッションクリティカルなアプリケーションです。長年（そして数十年）にわたって、多くのお客様は自社固有の要件を満たすために SAP をカスタマイズしてきました。これらのカスタマイゼーションを作成するために、お客様は SAP の ABAP プログラミング言語を利用して、必要なビジネス機能を提供する専用プログラムを作成してきました。ABAP プログラムは企業が SAP をビジネスに適合させるのに役立ちましたが、これにより運用とアップグレードが困難な高度にカスタマイズされた SAP 環境が生まれました。私たちは、ドキュメンテーションが不足している、または元の開発者が退職している「数十年前」に書かれた複雑な ABAP コードについてよく耳にします。現在、これらの企業がクラウドへの移行、S/4HANA を含む SAP の最新オファリングの実装、SAP が推奨する「クリーンコア」戦略（お客様がコア SAP アプリケーションを変更することなく固有の要件を満たすために SAP を拡張する）の採用を検討する中で、レガシーコードは多くの課題を提示しています。 Amazon Q Developer による SAP モダナイゼーションの簡素化 Amazon Q Developer は、企業がレガシーコードの課題を克服し、より高速で低コストの SAP アップグレードを可能にするのに役立ちます。これにより、規制遵守、セキュリティパッチ適用、新しいソフトウェア機能からの恩恵が簡素化されます。Amazon Q Developer は、レガシー ABAP コードの機能仕様と技術仕様の両方のドキュメンテーションを生成する能力があり、貴重な時間を節約できます。Amazon Q Developer は、従来の SAP ABAP、SAP ABAP RESTful Application Programming Model (RAP)、SAP Cloud Application Programming Model (CAP) を含む SAP プログラミングフレームワーク全体で動作します。Q Developer は、VS Code、Eclipse、その他複数の IDE 内で IDE 拡張機能として利用できます。Amazon Q Developer の Eclipse バージョンは、近い将来、すべての異なる ABAP オブジェクトタイプで完全に機能するようになります。他のプログラミング言語（Java、Python）で Q Developer を使用しているお客様は、開発者の生産性が最大 40% 向上し、さまざまな開発タスクが最大 80% 加速されたと報告しています。私たちは既に、ABAP 開発で同様の利益を実現している SAP のお客様（およびパートナー）からの声を聞き始めています。 Zappos.com のエンタープライズシステム担当シニアディレクターである Saul Dave 氏は次のように述べています： Amazon Q Developer は、私たちの ABAP 開発とアプリケーションサポートチームにとってゲームチェンジャーになるでしょう。 それでは、Q Developer が SAP 開発者の生産性をどのように向上させるかを示す 4 つの使用例を詳しく見てみましょう： ABAP コードの生成 BTP と Fiori アプリケーションの生成 テストケースの生成 レガシー ABAP コードのドキュメント化 使用例 #1: ABAP コードの生成 Amazon Q Developer は、自然言語プロンプトを解釈して機能的なコードを作成できます。この例では、オーダー番号とお客様番号でフィルタリングする機能を含む、オープンな販売オーダーを表示する ABAP コードが生成されます。開発者は、Q Developer に次のプロンプトを入力してコードを作成します： 「zhprp_sales_order_overview という名前の ABAP レポートを生成し、オープンな販売オーダーのリストを表示し、オーダー番号またはお客様番号（sold-to-party）でフィルタリングします。含める項目：販売オーダー番号、Sold-to-party、オーダー作成日、明細番号、材料番号、注文数量、確認数量。レコードを販売オーダー番号で並べ替えます。出力を ALV 形式で表示します。」 次の短いビデオは、プロンプトの入力と生成されたコードの出力を示しています。Q Developer チャットウィンドウは画面の右側にあります。ビデオでは、コードが SAP 内で正常に実行されていることも示されています。 使用例 #2: Fiori と BTP のコード生成 次の例は、Q Developer を使用して完全な Fiori アプリケーションを開発する方法を示しています。この例では、CDS ビュー、OData インターフェース、UI を含むフロントエンドとバックエンドコンポーネントを作成するプロセスを段階的に進める単一のプロンプトを使用します。使用されるプロンプトは次のとおりです： 「販売オーダー（作成、更新、削除）用の Fiori アプリケーションを作成するために必要なすべてのことを教えてください。そして、各ステップを作成している間、私を手助けしてください。さらに、ダミーデータを挿入するクラスと、TDD 用の CDS ビューのテストクラスも必要です。」 Amazon Q は階層化されたアプローチに従い、必要なテーブル構造が作成されるデータベース層から始まります。その後、プロセスは CDS 層に移り、基盤となるデータベーステーブルを抽象化しながらデータのビジネス指向ビューを提供するルート CDS ビューが確立されます。ビジネス層では、Amazon Q は動作実装とテストクラスを含む CDS ビューの動作定義の生成を支援します。サービス層では、OData V2 公開のためのサービス定義とバインディングの作成が含まれ、Fiori アプリケーションとバックエンド間の通信が可能になります。UI 層では、Amazon Q はメタデータ拡張を使用した UI アノテーションを支援します。開発は、manifest.json の作成、サービスバインディング、アクティベーション、パブリッシングを含むロードマップに従って続行されます。最終ステップでは、完全な Fiori アプリケーションを生成するためのカスタムコントローラーアクションと HTML UI5 コンポーネントの作成が含まれます。 使用例 #3: 単体テストケースの生成 Amazon Q Developer は、ドキュメンテーションと元の開発者が利用できない場合に、既存のコードのテストクラスの作成を支援します。ユーザーは単純にコードを Q のインラインチャットに貼り付けるだけで、包括的なテストシナリオを自動的に分析して生成します。生成されたコードの構文エラーは、ワンクリック実装で Q のインラインチャット機能を通じて迅速に修正できます。生成されたテストクラスは SAP システムですぐに利用でき、必要に応じて微調整できます。 「パブリックメソッド用の単体テストクラスを生成してください “ここにクラスロジック/詳細を提供してください”」 この機能により、開発者は複数の反復後でもビジネスロジックを簡単にテストでき、手動テストの膨大な労力を節約できます。 使用例 #4: レガシー ABAP コードのドキュメント化 次の例は、Amazon Q Developer が ABAP コードを分析し、チャットウィンドウのカスタムテンプレートに基づいて既存のコードベースと新しく作成されたコードの両方に適応してドキュメンテーションを自動生成する方法を示しています。ドキュメンテーションを PDF または Word ドキュメントに簡単に変換できます。Amazon Q Developer は、主要な情報を抽出し、一貫したフォーマット標準を維持することで、ドキュメンテーションプロセスを合理化します。この例では、次のプロンプトが使用されました： 「上記の ABAP コードの技術ドキュメンテーションを生成してください。次のポインターをテンプレートとして使用して、各コンポーネントが実行するアクションを明確に説明する非常に詳細なドキュメンテーションを提供してください： 1. クラス/プログラム名 2. クラス/プログラム概要 3. 技術仕様 3.1 データ構造 3.2 選択画面（提供されている場合） 4. 主要コンポーネント 4.1 サブルーチン/メソッド 5. テスト実装（提供されている場合） 5.1 テストメソッド 5.2 テストセットアップ 6. 技術的依存関係 7. エラーハンドリング 8. パフォーマンスの考慮事項 この機能により、組織は関連するカスタムオブジェクトによって影響を受けるビジネスプロセスを簡単に理解し、ドキュメント化でき、移行と知識移転の際に役立ちます。 上記の例からわかるように、Amazon Q Developer は SAP 開発者の手作業を削減する強力な機能を提供し、お客様がビジネスプロセスをより迅速にモダナイゼーションするのに役立ちます。お客様がこれらの機能を継続的に活用する方法を見ることを楽しみにしています。 価格モデル： Amazon Q Developer の無料ティアから始めることができます。これは、月に 50 回のチャットインタラクション、月に 5 回のソフトウェア開発支援、月に最大 1,000 行のコード変換を提供します。Pro ティアは、無料ティアのすべての機能に加えて、ユーザーとポリシーを管理するエンタープライズアクセス制御機能、提案を改善するためにコードベースに Q Developer をカスタマイズする機能、高度な機能のより高い使用制限を提供します。 詳細な価格プランを探索するにはこちらをクリック してください。 今すぐレガシー SAP コードをモダナイゼーションしましょう。 Amazon Q Developer のセットアップに関する段階的な指示については、この ワークショップ にアクセスしてください。SAP の使用例を実演し、これらやその他のシナリオの詳細な解説を提供する今後の YouTube ビデオにご注目ください。Amazon Q Developer の詳細については、 ドキュメンテーション をご覧いただくか、レガシー SAP コードのモダナイゼーションをどのように支援できるかについて話し合うために私たちのチームにお問い合わせください。 本ブログは Amazon Q Developer CLI による機械翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

AWS re:Invent の開催が間近に迫る中、さまざまな道のりと知識共有へのコミットメントを通じて世界中のビルダーを後押しし続けている 3 人のすばらしい AWS ヒーローをご紹介したいと思います。テクノロジー業界や地方コミュニティの女性の地位向上から、学問的専門知識と業界専門知識の橋渡し、そしてエンタープライズ AI ソリューションの開拓まで、これらのリーダーたちはコミュニティを前進させる革新的精神を実証しています。ヒーローたちのストーリーは、熱意あふれるアドボカシーやメンターシップと卓越した技術の組み合わせが、AWS のグローバルコミュニティをどのように強化するのかを浮き彫りにしています。 Dimple Vaghela 氏 – アフマダーバード、インド コミュニティヒーローである Dimple Vaghela 氏は、彼女が地域全体でのクラウド教育と技術的成長を推進する AWS User Group Ahmedabad と AWS User Group Vadodara の両方を先導しています。彼女の影響は、何千人もの学習者がクラウドキャリアを進める手助けとなってきた多数の AWS ミートアップ、ワークショップ、AWS Community Days の開催など多岐にわたります。Vaghela 氏は、地方出身の少女たちのテクノロジーキャリアを支援する「Cloud for Her」プロジェクトを立ち上げるとともに、Women in Tech India User Group の共催者も務めています。AWS re:Invent 2024 では、彼女の並外れたリーダーシップとコミュニティ貢献が認められ、オーナーシップ部門で AWS ユーザーグループリーダー賞を受賞しました。Vaghela 氏は現在も、講演、メンタリング、影響力のあるテクニカルイベントの企画を通じて、よりインクルーシブなクラウドコミュニティを構築し続けています。 Rola Dali 氏 – モントリオール、カナダ コミュニティヒーローである Rola Dali 氏は、AWS クラウドを専門とするデータ、機械学習、AI のシニアエキスパートで、神経科学とバイオインフォマティクスの博士号、およびヒトゲノムに関する専門知識に基づくユニークな視点をもたらしています。AWS Montreal User Group の共催者、そして以前の AWS コミュニティビルダーとしてのクラウドコミュニティに対するコミットメントが認められた Dali 氏は、2024 年に名誉あるゴールデンジャケット賞を受賞しました。Dali 氏は、AWS ソリューションの設計、ブログや講義を通じた知識の共有に加えて、テクノロジー業界に参入する女性、産業界へ転身する学術関係者、キャリアをスタートさせる学生のメンタリングを行うことで、テクノロジーコミュニティを積極的に形成しています。 Vivek Velso 氏 – トロント、カナダ 機械学習ヒーローである Vivek Velso 氏は、27 年を超える IT 業界経験を持つ熟練のテクノロジーリーダーであり、組織がそのクラウドインフラストラクチャを生成 AI ワークロード向けにモダナイズするための支援を専門としています。AWS に関する深い専門知識が認められ、すべての AWS 認定を修了した人のための名誉あるゴールデンジャケット賞を受賞した Velso 氏は、複数の認定試験の AWS Subject Matter Expert (SME) プログラムに積極的に貢献しています。これまで AWS コミュニティビルダーや AWS アンバサダーを務めてきた Velso 氏は、100 件を超える技術ブログ、記事、カンファレンス講演、AWS ライブストリームを通じて知識を共有し続けることで、コミュニティが自信を持ってクラウドイノベーションを取り入れるための支援を提供しています。 詳細をご覧ください AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローのウェブページ にアクセスしてください。 – Taylor 原文は こちら です。

11 月 10 日、 AWS Backup での Amazon EKS のサポート が発表され、他の Amazon Web Services (AWS) サービスで信頼されているものと同じ一元化されたプラットフォームを使用して Kubernetes アプリケーションをセキュア化する機能が提供されるようになりました。この統合は、コンテナ化されたアプリケーションを保護しながらクラスター構成とアプリケーションデータの両方にエンタープライズグレードのバックアップ機能を提供するという複雑性を解消します。 AWS Backup は、AWS ワークロードとオンプレミスワークロードの全体でデータ保護を一元化し、自動化するためのフルマネージドサービスです。 Amazon Elastic Kubernetes Service (Amazon EKS) は、Kubernetes クラスターの可用性とスケーラビリティを管理するためのフルマネージド Kubernetes サービスです。この新しい機能を使用することで、他の AWS サービスと並行して Amazon EKS 環境全体でのデータ保護の一元的な管理と自動化を行えます。 これまで、お客様が EKS クラスターをバックアップするにはカスタムソリューションやサードパーティツールに頼らなければならず、クラスターごとに複雑なスクリプト作成とメンテナンスが必要でした。AWS Backup での Amazon EKS のサポートは、EKS クラスター (Kubernetes デプロイとリソース) およびステートフルデータ ( Amazon Elastic Block Store (Amazon EBS) 、 Amazon Elastic File System (Amazon EFS) 、 Amazon Simple Storage Service (Amazon S3) のみに保存されているもの) の両方を保護する単一の一元化されたポリシー主導のソリューションを提供し、クラスター全体でカスタムスクリプトを管理する必要をなくことで、このオーバーヘッドを解消します。復元に関しては、これまでお客様は EKS バックアップをターゲット EKS クラスター (ソース EKS クラスターまたは新しい EKS クラスター) に復元しなければならず、復元する前に EKS クラスターインフラストラクチャをプロビジョニングしておく必要がありました。この新しい機能では、EKS クラスターバックアップの復元時に以前の EKS クラスターの構成設定に基づいて新しい EKS クラスターを作成し、この新しい EKS クラスターに復元するオプションもお客様に提供され、EKS クラスターのプロビジョニングは AWS Backup がお客様に代わって管理します。 このサポートには、単一または複数の EKS クラスターを保護するためのポリシーベースの自動化が含まれます。 この単一データ保護ポリシーは、AWS Backup がサポートするすべてのサービスで一貫したエクスペリエンスを提供します。そのため、悪意のある変更や不注意による変更を防ぐためのイミュータブルバックアップの作成が可能になり、お客様が規制コンプライアンスのニーズを満たすために役立ちます。顧客データの損失やクラスターのダウンタイムが発生した場合でも、お客様は使い勝手の良いインターフェイスを使用することで暗号化されたイミュータブルバックアップから EKS クラスターデータを簡単に復元し、EKS クラスターを大規模に実行する事業継続性を維持できます。 仕組み 以下は、AWS Backup で EKS クラスターのオンデマンドバックアップのサポートを設定する方法です。最初にバックアッププロセスのウォークスルーを説明してから、EKS クラスターの復元を実際に行っていきます。 バックアップ AWS Backup コンソール の左側にあるナビゲーションペインで [ 設定 ] を設定してから [ リソースを設定 ] を選択し、AWS Backup での EKS クラスター保護オプションを有効にします。 Amazon EKS が有効になったので、[ 保護されたリソース ] で [ オンデマンドバックアップを作成 ] を選択し、既存の EKS クラスターである floral-electro-unicorn のバックアップを作成します。 [設定] で EKS を有効にすることで、EKS クラスターのオンデマンドバックアップの作成時に EKS が [ リソースタイプ ] として表示されることを確実にします。EKS リソースタイプとクラスターの選択に進みます。 残りの情報はデフォルトのままにしておき、[ IAM ロールを選択 ] を選択して、 私に代わってバックアップを作成および管理するときに AWS Backup が引き受ける必須の許可 を用いて作成およびカスタマイズされたロール ( test-eks-backup ) を選択します。[ オンデマンドバックアップを作成 ] を選択してプロセスを完了します。 ジョブが開始され、EKS クラスターの状態と永続的ボリュームの両方をバックアップし始めます。Amazon S3 バケットがバックアップにアタッチされている場合は、 追加の Amazon S3 バックアップ許可 AWSBackupServiceRolePolicyForS3Backup をロールに追加する 必要があります。このポリシーには、AWS Backup が任意の Amazon S3 バケットをバックアップするために必要な許可が含まれています。これには、バケット内のすべてのオブジェクトと、関連する AWS KMS キーへのアクセスが含まれます。 ジョブが正常に完了し、 floral-electro-unicorn EKS クラスターが AWS Backup によってバックアップされました。 復元 AWS Backup コンソールを使用して、EKS クラスターバックアップの復元プロセスを開始するための EKS バックアップ複合リカバリポイントを選択してから、[ 復元 ] を選択します。 [ EKS クラスターを完全に復元 ] を選択して、EKS バックアップを完全に復元します。既存のクラスターに復元するには、[ 既存のクラスターを選択 ] し、ドロップダウンリストからクラスターを選択します。個々の Kubernetes リソースが復元される順序として、[ デフォルトの順序 ] を選択します。 その後、永続的ストレージリソースの復元を設定します。このリソースは EKS クラスターと共に復元されます。 次に、復元アクションを実行するための [ IAM ロールを選択 ] します。デフォルトでオンになっている [ 保護されたリソースのタグ ] チェックボックスはそのままにしておき、[ 次へ ] を選択します。 [ 復元 ] を選択してプロセスを完了し、ジョブを開始する前に、すべての情報を確認します。 ドロップダウン矢印を選択すると、EKS クラスターの状態とアタッチされている永続的ボリューム両方の復元ステータスの詳細が表示されます。このウォークスルーでは、個々のリカバリポイントのすべてが正常に復元されました。バックアップの一部が失敗した場合でも、正常にバックアップされた永続ストア (Amazon EBS ボリュームなど) とクラスター構成設定を個別に復元することが可能です。ただし、EKS バックアップを完全に復元することはできません。正常にバックアップされたリソースを復元用に利用できるようになり、EKS クラスターのリカバリポイントの下にネストされたリカバリポイントとして一覧表示されます。部分的な失敗が発生すると、失敗した部分の通知が行われます。 メリット 以下は、AWS Backup での Amazon EKS のサポートによって実現されるメリットです。 カスタムスクリプトやサードパーティソリューションの管理に伴うオーバーヘッドを解消するフルマネージド型のマルチクラスターバックアップエクスペリエンス。 バックアップのライフサイクル管理を簡素化し、EKS を含めた AWS サービス全体でアプリケーションデータのバックアップとリカバリをシームレスにする一元化されたポリシーベースのバックアップ管理。 バックアップボールト を使用してバックアップを保存し、整理する機能。バックアップボールトにポリシーを割り当てて、バックアッププランやオンデマンドバックアップを作成するためのアクセス権をユーザーに付与するとともに、リカバリポイントの作成後にそれらを削除する能力を制限します。 知っておくと便利な情報 以下は、知っておくと役に立つ情報です。 AWS Backup を使用した EKS クラスターの保護には、 AWS Backup コンソール 、API、または AWS コマンドラインインターフェイス (AWS CLI) を使用します。また、クラスターの作成後にクラスターのオンデマンドバックアップを作成することも可能です。 いくつかの異なるアカウントや AWS リージョン に EKS バックアップのセカンダリコピーを作成して、バックアップが誤って削除されるリスクを最小限に抑えることができます。 EKS バックアップの復元は、AWS Backup コンソール、API、または AWS CLI を使用して実行できます。 復元は非破壊的であるため、既存のクラスターに復元しても Kubernetes バージョンやデータが上書きされることはありません。その代わりに、バックアップリソースとソースリソース間の差分の復元が作成されます。 Kubernetes リソースはクラスターレベルでスコープされている可能性があるため、復元が正常に行われるようにするためにも、名前空間は既存のクラスターにのみ復元できます。 お客様の声 Salesforce の Sr.Director of Engineering である Srikanth Rajan 氏は、「バックアップと復元の堅実な計画がない状態でソフトウェアのバグやクラスターの意図しない削除に起因する Kubernetes コントロールプレーンの損失が発生すると、致命的な結果を招くことになりかねません。AWS による EKS の新しいバックアップと復元特徴量のリリースが非常にすばらしいのはこのためです。これは、Kubernetes プラットフォームの重大なレジリエンシーギャップの解消に向けた大きな前進です」と語っています。 今すぐご利用いただけます AWS Backup での Amazon EKS のサポートは、AWS Backup と Amazon EKS が提供されているすべての AWS 商用 リージョン (中国を除く) と AWS GovCloud (米国) で本日からご利用いただけます。今後の更新については、 全リージョンのリスト をご確認ください。 詳細については、 AWS Backup 製品ページ と AWS Backup の料金ページ をご覧ください。 AWS Backup で EKS クラスターを保護するためのこの機能をぜひお試しいただき、 AWS re:Post for AWS Backup 、または通常の AWS サポート担当者を通じてフィードバックを提供することで、皆さんのご意見をお聞かせください。 – Veliswa 原文は こちら です。

はじめに AWS上でSAPワークロードの真の可能性を解き放つ準備はできていますか？パズルの最も重要なピースの一つを解決しましょう：企業ネットワークとクラウドERPワークロード間の安全で信頼性の高いネットワーク接続の確立です。 AWSでは、お客様がSAP Cloud ERP Private ワークロード（旧RISE with SAP）の実装を支援する中で、3つの質問が当然のように浮上します： 「プライベートクラウドERP環境への安全な接続をどのように確立すればよいか？」 「私たちのユースケースに最もコスト効率の良いネットワークアーキテクチャは何か？」 「Direct Connect、Site-to-Site VPN、またはその両方を実装すべきか？」 これらの質問をお持ちの方は、あなただけではありません。今日行うネットワーク接続の決定は、システムパフォーマンスから災害復旧機能まで、あらゆることに影響を与え、今後何年にもわたってSAP運用に影響を与えます。 このガイドでは、複雑さを取り除き、特定のビジネス要件に合致するアプローチで、既存のインフラストラクチャをAWS for SAP Cloud ERP Privateに接続する方法をお示しします。 開始：責任共有モデルの理解 SAP Cloud ERP Privateのワークロードを実装する際、責任は分担されます： SAPがCloud ERP Privateが動作するAWS環境を管理 お客様がインフラストラクチャとAWS内のSAP Cloud ERP Private環境間のネットワーク接続を管理 この分担は、実装を開始する前に明確な接続戦略が必要であることを意味します。 ビジネスニーズに対応しましょう すべての組織は、SAP Cloud ERP Privateの旅において独自の要件を持っています。私たちは以下の出発点を見ています： 集中実装：ネットワークインフラストラクチャをAWS for SAP Cloud ERP Private環境と迅速に接続するための、直接的で安全なネットワーキングソリューションをお探しです。このアプローチは、セキュリティを維持しながらシンプルさを優先します 既存のAWSインフラストラクチャ：確立されたAWS接続があり、SAP Cloud ERP Privateをネットワークアーキテクチャに効率的に統合し、現在の投資を最大化したいとお考えです マルチリージョン運用：ビジネスが複数のリージョンまたは複雑なハイブリッド環境にわたって高度なネットワーキング機能を必要とし、強化された制御と自動化を求めています 3つのアプローチすべてがセキュリティと信頼性を提供します。主な違いは、即座のニーズ、運用の複雑さ、将来のスケーラビリティのバランスをどのように取るかです。 この投稿で扱う内容 異なるビジネス要件に合致する3つの接続アーキテクチャを説明します： 基盤アーキテクチャ：セキュリティと信頼性を維持しながら迅速に実装できる、合理化された安全な接続ソリューション。迅速な展開を優先する組織に最適 統合アーキテクチャ：既存のAWS投資を最適化し、自動フェイルオーバー機能を提供するハイブリッド接続アプローチ。SAP Cloud ERP Privateワークロードを現在のAWS環境に組み込むのに最適 包括的アーキテクチャ：AWSベストプラクティスと高度な自動化を組み込みながら、複雑なマルチリージョン展開に最大の柔軟性を提供するエンタープライズランディングゾーンアプローチ 各ソリューションについて、以下を学習します： 主要なビジネスドライバーとユースケース 図表付きの詳細なアーキテクチャパターン 実装の考慮事項とベストプラクティス 各アーキテクチャはセキュリティと信頼性を提供します。選択は、特定のビジネス要件、運用の好み、成長計画によって決まります。 最適なネットワークアーキテクチャを構築する準備はできましたか？詳しく見ていきましょう。 オプション1：AWS Direct Connectでミッションクリティカルな接続を構築 図1：顧客ネットワークとAWS for SAP Cloud ERP Private環境（AWS for RISE with SAP）間の回復力のあるDirect Connect構成 SAPワークロードが一貫した高性能接続を要求する場合、 AWS Direct Connect （DX）が提供します。このソリューションは、インフラストラクチャとAWS上のSAP Cloud ERP Private間の専用プライベートネットワーク接続を提供し、最も要求の厳しいワークロードに対して予測可能なパフォーマンスと信頼性の高いスループットを保証します。 なぜDirect Connectを選ぶのか？ ミッションクリティカルなSAP環境において、DXは以下を提供します： 一貫した低レイテンシパフォーマンス 予測可能なネットワーク動作 専用帯域幅 プライベート接続によるセキュリティ強化 重要：スムーズな展開を確保するため、予定されている本稼働日の少なくとも6〜8週間前にDirect Connectの実装を開始してください。 以下が必要な場合にDXを検討してください： 一貫した低レイテンシパフォーマンスを必要とする本番SAP環境 定期的な大容量データ転送（1日2TB以上） 複数のリージョンにわたる信頼性の高い帯域幅 ミッションクリティカルな運用における予測可能な応答時間 Direct Connection オプションの選択： AWS Direct Connectは接続への2つのパスを提供します： ホスト接続 AWS Direct Connectパートナーを通じた迅速な展開 コスト効率の良い実装 50 Mbpsから25 Gbpsまでの帯域幅オプション 実装時間の短縮（数日から数週間） ほとんどのSAP Cloud ERP Private展開に最適 専用接続 接続に対する最大限の制御 最大100 Gbpsのカスタム帯域幅 より長い実装タイムライン（数週間） より高い初期費用 大容量、レイテンシに敏感なワークロードに推奨 重要なセキュリティ注意事項：どちらの接続タイプも組み込み暗号化は含まれていません。強化された保護のためにMACsecなどの追加のセキュリティ対策の実装を検討してください。 回復力のある接続の構築 ミッションクリティカルなワークロードについては、高可用性のために複数のDX接続の実装をお勧めします。方法は以下の通りです： AWS Direct Connect回復力推奨事項 を使用して最適なモデルを選択 冗長接続のために AWS Direct Connect回復力ツールキット を実装 最大の回復力のために異なるプロバイダーからの接続を展開 本稼働前にフェイルオーバー構成をテスト コストの考慮事項 複数のDX接続は単一リンクと比較して初期費用と継続費用の両方を増加させますが、以下を提供します： より高い可用性 強化されたSLAコンプライアンス より良いビジネス継続性 接続中断のリスク軽減 注意：AWS for SAP Cloud ERP Privateへのネットワーク接続を実装する際、Direct Connect接続管理をSAPに委任すると、将来の接続変更の柔軟性が制限される可能性があることに注意してください。 オプション2：Direct Connect + VPNフェイルオーバーでコストと信頼性を最適化 図2：顧客ネットワークとSAP Cloud ERP Private（RISE with SAP）環境間のAWS Direct Connectプライマリ接続とSite-to-Site VPNバックアップ AWS for SAP Cloud ERP Privateワークロードの接続を計画する際、ビジネス継続性を実現するために常に複数のDirect Connect接続が必要というわけではありません。AWS Direct ConnectとSite-to-Site VPNを組み合わせることで、パフォーマンスとコスト効率のバランスを取った回復力のあるネットワークアーキテクチャを作成できます。 ハイブリッド接続戦略の構築 このソリューションは、Direct Connectをプライマリパスとして使用し、SAPワークロードに期待される一貫したパフォーマンスを提供します。一方、 AWS Site-to-Site VPN （VPN）は自動フェイルオーバーオプションとして待機し、プライマリ接続に中断が発生した場合にインターネット経由で暗号化された接続を提供します。このアプローチにより、冗長Direct Connectリンクのコストなしに高い信頼性を得ることができます。 組織は以下の場合にこのハイブリッドモデルが特に価値があると感じています： 複数のリージョンにわたってSAPワークロードを展開する場合 開発およびテスト環境をサポートする場合 グローバルの従業員からSAPアプリケーションへのアクセスを可能にする場合 ビジネス継続性を維持しながらコストを管理する場合 Site-to-Site VPNの開始 AWS Site-to-Site VPN を組み込む主な利点の一つは、迅速な展開機能です。Direct Connectの実装が進行中（6〜8週間かかる場合があります）の間に、数日でVPN接続を確立できます。これにより、チームはSAP Cloud ERP Privateでの作業をすぐに開始し、準備ができたらDirect Connectをプライマリパスとして移行できます。 VPN接続は以下を提供します： 安全なデータ転送のための組み込みIPSec暗号化 インターネット接続に基づく柔軟な帯域幅 従業員のグローバルなアクセシビリティ 従量課金制の価格モデル ビジネスに適した選択をする このハイブリッドアプローチは、以下が必要な組織に特に適しています： パフォーマンス要件と予算制約のバランスを取る さまざまな帯域幅ニーズを持つリモートオフィスをサポートする 開発チームに即座の接続を提供する 災害復旧機能を確立する 帯域幅とレイテンシはインターネット接続によって変動しますが、お客様はSite-to-Site VPNが開発、テスト、バックアップシナリオに十分以上のパフォーマンスを提供することを発見しています。自動フェイルオーバー機能により、プライマリ接続に問題が発生してもチームは重要なSAPシステムへのアクセスを維持できます。 実装の計画 このハイブリッド接続アプローチを検討する際は、以下の重要なポイントを念頭に置いてください： 要件から始める： 予想されるトラフィック量 異なる環境のパフォーマンス要件 従業員の地理的分布 予算制約 タイムラインを考慮する： 即座の接続のためにまずVPNを実装 並行してDirect Connect展開を計画 テストと検証期間をスケジュール フェイルオーバー手順を準備 成長について考える： 将来の帯域幅要件 追加の場所の接続 潜在的なワークロード拡張 詳細な構成手順とアーキテクチャパターンについては、 オンプレミスネットワークからRISE with SAPへの接続 に関する技術文書をご確認ください。 オプション3：AWSランディングゾーンでエンタープライズ基盤を構築 図3：オンプレミスネットワークとSAP Cloud ERP Private（RISE with SAP）間の集中化された接続管理を提供するAWSランディングゾーン SAP Cloud ERP Privateへの旅がより広範なクラウド戦略の一部である場合、ランディングゾーンの実装により、ビジネスとともに成長する基盤が作成されます。このアプローチは、AWS環境全体でセキュリティと制御を維持しながら複雑さを管理するのに役立ちます。 なぜランディングゾーンアプローチを検討するのか？ ランディングゾーンを組織のデジタル都市計画と考えてください。個々の構造（ワークロード）をスペースが許す場所に構築するのではなく、現在のニーズをサポートしながら将来の成長に備える、よく設計されたインフラストラクチャを作成しています。SAP Cloud ERP Privateにとって、これは接続ソリューションがより大きな戦略的アーキテクチャの一部になることを意味します。 エンタープライズ基盤の構築 その核心において、ランディングゾーンはベストプラクティスに従う Well-Architected なマルチアカウントAWS環境です。以下を提供します： 集中化されたセキュリティ制御と監視 標準化されたネットワークアーキテクチャ 自動化されたアカウントプロビジョニング リージョン間での一貫したガバナンス 柔軟な統合オプション Landing Zone Accelerator（LZA） は、この基盤を迅速かつ安全に実装するのに役立ちます。オープンソースツールとして、LZAはAWSの最新のベストプラクティスを組み込みながら、ニーズに基づいてカスタマイズする柔軟性を提供します。 接続された環境の作成 ランディングゾーン内で、AWS Transit Gatewayは洗練された企業ネットワークバックボーンと同様に、ネットワークトラフィックの中央ハブとして機能します。この設計により、以下が可能になります： 複数のVPCの接続 オンプレミスネットワークの統合 一貫したセキュリティポリシーの実装 トラフィックパターンの集中監視 必要に応じた接続のスケール 実世界での応用 組織は以下の場合にランディングゾーンアプローチを実装します： 厳格なセキュリティとコンプライアンス基準を維持する必要がある コアSAPワークロードを超えて拡張する計画がある 複数の地理的リージョンで運用している 高度なトラフィック管理が必要 追加のAWSサービスを活用したい 集中化された監視と管理が必要 例えば、グローバル製造業者はAWS for SAP Cloud ERP Privateから始めるかもしれませんが、IoT機能、分析プラットフォーム、機械学習サービスを追加する計画があります。ランディングゾーンアプローチにより、これらの追加がよりスムーズで安全になります。 ランディングゾーンの計画 ランディングゾーンは直接接続オプションよりも多くの初期計画が必要ですが、Landing Zone Acceleratorがプロセスを簡素化します。開始方法は以下の通りです： 要件の評価 現在および将来のワークロードニーズ セキュリティとコンプライアンス基準 地理的分布 統合要件 アーキテクチャの設計 アカウント構造 ネットワークトポロジー セキュリティ制御 管理ツール 展開の計画 実装フェーズ リソース要件 タイムラインの考慮事項 テストアプローチ 必要な時にサポートを受ける Landing Zone Acceleratorは自動化とガイダンスを提供しますが、この旅において一人ではありません。 AWSプロフェッショナルサービス と AWSパートナー が以下をサポートできます： 最適なアーキテクチャの設計 セキュリティベストプラクティスの実装 ネットワーク接続の構成 運用手順の確立 将来を見据えて ランディングゾーンアプローチは直接接続オプションよりも大きなステップのように見えるかもしれませんが、組織の将来への投資です。以下に必要なフレームワークを提供します： 効率的なスケール セキュリティの維持 コストの制御 イノベーションの実現 ビジネス成長のサポート AWS for SAP Cloud ERP Privateに特化した詳細なガイダンスについては、 AWS上でRISE with SAPのためのエンタープライズ対応ネットワーク基盤の構築 に関するドキュメントをご覧ください。 すべてをまとめる：最適なネットワーク戦略の構築 AWS for SAP Cloud ERP Private（旧RISE with SAP）を使用する各組織の旅は独特です。そのため、AWSは特定のニーズに合わせて組み合わせることができる柔軟な接続オプションを提供しています。これらのオプションがどのように連携して包括的なソリューションを作成するかを探ってみましょう。 エンタープライズ成功のための強力な組み合わせ パフォーマンス + 回復力 – Direct ConnectとSite-to-Site VPNの組み合わせ（オプション1 + 2） 重要なワークロードは専用接続で実行 リモート拠点はVPN経由で接続 組み込みフェイルオーバー保護 コスト効率的なグローバルリーチ エンタープライズ制御 + 信頼性 – 冗長Direct Connectを持つランディングゾーン（オプション3 + 1） 環境に対する最大限の制御 最高レベルの可用性 業界標準のセキュリティ制御 将来対応の基盤 柔軟性 + コスト最適化 – ハイブリッド接続を持つランディングゾーン（オプション3 + 2） スケーラブルなアーキテクチャ スマートなコスト管理 自動フェイルオーバー 簡素化された管理 完全なエンタープライズソリューション – 包括的アプローチ（オプション1 + 2 + 3） 最大の柔軟性 完全な冗長性 グローバルリーチ 将来対応設計 決定を下す 最適なネットワーク戦略は、いくつかの重要な要因によって決まります： ビジネスクリティカルな要件 パフォーマンス要件 予算の考慮事項 実装タイムライン 将来の成長計画 地理的分布 行動を起こす：次のステップ 結論として、AWS for SAP Cloud ERP Private（RISE with SAP）へのネットワーク接続は、プレッシャーの下では複雑に見えるかもしれません。しかし、この投稿と言及されたリソースの助けを借りて、より情報に基づいた出発点を持つことができます。最適なネットワーク接続の選択は、ビジネス目標、実装時間枠、予算、AWSやネットワーキングの習熟度、その他の制限事項によって決まります。行動を起こす方法は以下の通りです： 要件の評価 現在のネットワーク要件をマッピング パフォーマンス要件の文書化 重要なワークロードの特定 将来の成長を考慮 アプローチの計画 接続戦略の選択 実装フェーズの定義 タイムラインの確立 ステークホルダーの調整 実装の準備 技術要件の作成 AWSとの早期エンゲージメント アーキテクチャレビューのスケジュール テスト計画の開発 結論： AWS for SAP Cloud ERP Private（旧RISE with SAP）への成功した接続への旅は、シンプルなDirect Connect実装から始めるか、包括的なランディングゾーンを構築するかに関わらず、まず一歩から始まります。。 始める準備はできましたか？AWSアカウントチームに連絡するか、AWSサポートポータルでケースを開いて、最適なネットワークアーキテクチャの構築を開始してください。 追加リソース： AWS上でRISE with SAPのためのエンタープライズ対応ネットワーク基盤構築のガイダンス 接続 – 一般的なSAPガイド 安全でスケーラブルなマルチアカウントAWS環境のセットアップ – AWS P… AWS Direct Connect + AWS Transit Gateway + AWS Site-to-Site VPN – Amaz… オンプレミスネットワークからRISE with SAPへの接続 本ブログの翻訳はAmazon Q Developer CLIによる機械翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。 <!-- '"` -->

はじめに 数千のお客様が AWS上でSAPワークロード を実行しており、お客様はAWS上でクラウドネイティブなアプリケーション拡張を構築することで、ビジネスプロセス変革を加速することを求めています。お客様は200を超えるAWSサービスを活用して、ERPシステムのクリーンコアを維持し、アップグレードを合理化し、AWSネイティブ機能を使用して進化するビジネスニーズに合わせてペースよくイノベーションを行っています。 セキュリティはAWSの最優先事項です。このモダナイゼーションの旅において、お客様の重要な焦点は、最小権限を順守し、複雑なシステム境界を越えてアイデンティティを伝播することで、セキュリティ体制を強化することです。一つのユースケースは、ユーザーがAWS上でホストされているクラウドネイティブアプリケーション拡張からSAPリソースにアクセスする場合です。 より良いユーザーエクスペリエンスの重要な実現要因は、プリンシパル伝播です。これは、AWSのApplication Load Balancer（ALB）などの初期認証ポイントから、再認証を必要とせずにSAPなどのバックエンドシステムまで、検証されたアイデンティティを運ぶ能力です。これにより、SAPリソースがALBによって検証されたアイデンティティを信頼し、ユーザー認可を通じて最小権限アクセスを担保することができます。 このブログ投稿では、 Application Load Balancer（ALB） 、X.509証明書、およびMutual Transport Layer Security（mTLS）が、AWS上でホストされているクラウドネイティブ拡張からミッションクリティカルなSAP ERPシステムのSAPリソースにアクセスするSAPユーザーに対して、シングルサインオン（SSO）エクスペリエンスを可能にする方法に焦点を当てています。 プリンシパル伝播とは？ プリンシパル伝播により、ユーザーは一度サインインするだけで複数のシステムに安全にアクセスでき、複数回ログインする必要がなくなります。これにより、ユーザーが一度認証されると（例：ALBでのクライアント証明書による認証）、そのアイデンティティがSAPなどの下流システムによって一貫して認識され、信頼されることが保証されます。これにより、冗長なログインプロンプトの必要性がなくなり、ランドスケープ全体で安全なユーザーコンテキストが維持されます。システムユーザーではなく、ユーザーのアイデンティティの下でアクションが実行されることを保証し、トークンベースの認証に依存することでセキュリティを向上させ、アイデンティティをシステムに転送することでシングルサインオン（SSO）を可能にします。 プリンシパル伝播の主要なメリット シングルサインオン（SSO）によるより良いユーザーエクスペリエンス： ユーザーは複数のシステムやアプリケーションにアクセスするために一度だけ認証すればよく、繰り返しのログインプロンプトの煩わしさを排除し、異なるプラットフォーム間での生産性を維持できます。 セキュリティの強化： 複数の認証情報を保存する必要性を排除し、認証タッチポイントを削減することで、プリンシパル伝播はセキュリティ体制を強化します。明確な監査証跡を維持し、統合されたシステム全体で一貫したセキュリティポリシーを強制する統一されたセキュリティコンテキストを作成し、潜在的な攻撃者が環境を侵害することを困難にします。 コンプライアンスとガバナンス： 組織は、包括的なユーザーアクティビティの追跡と説明責任を通じて、規制要件へのより良いコンプライアンスを維持できます。プリンシパル伝播により、ユーザーアクションがすべてのシステムで適切に帰属し、ログに記録されることが保証され、監査プロセスと規制報告が簡素化されます。 管理効率： ITチームは、単一の制御ポイントからユーザーアクセス、権限、認証情報を管理でき、ユーザーライフサイクル管理を簡素化し、日常的な管理タスクを合理化できます。 システム統合： プリンシパル伝播は、異なるシステムとプラットフォーム間の橋渡しとして機能し、システム境界を越えて一貫したユーザーコンテキストと認可を維持します。この統合は、アプリケーションが複数のプラットフォームとクラウドサービスにまたがる現代のハイブリッド環境において特に価値があります。 コスト削減： 組織は、ヘルプデスクチケットの削減、セキュリティ実装の簡素化、および集中管理によるより効率的なリソース利用から恩恵を受けます。 mTLS認証はプリンシパル伝播をどのようにサポートできるか？ Mutual Transport Layer Security（mTLS）認証は、クライアントとサーバー間で安全な双方向暗号化接続を確立します。サーバーのみが証明書を提供する標準的なTLSとは異なり、mTLSでは両方の当事者がデジタル証明書を提示する必要があります。このメカニズムにより、ユーザーはクライアントとサーバー間でより良いセキュリティ体制を持つシームレスな認証を体験できます。 図1. クライアントとサーバー間のmTLS認証フロー mTLS認証シナリオでは、両方が信頼されることを保証するために、認証局（CA）を使用してクライアントとサーバー証明書をプロビジョニングする必要があります。認証プロセスは以下のように動作します： クライアントがサーバーへの接続を要求します。 サーバーがその証明書を提示します。 クライアントがサーバーの証明書を検証します。 クライアントがサーバーの検証と認証のためにその証明書を提示します。 クライアントとサーバー間で安全な接続が確立されます。 Application Load BalancerでのmTLSクライアント認証 ALBはmTLS認証をサポートしています。パススルーモードと検証モードの2つのモードを提供します。 安全なデータフローを確保するために、ALB、SAP Web Dispatcher、S/4HANAシステムを含むインフラストラクチャ全体で使用されるすべてのSSL（Secure Socket Layer）またはTLS証明書は、これらの証明書の実装と保守を容易にするために、単一の信頼できるルート認証局から発行される必要があります。 mTLSパススルーモード mTLSパススルーモードでは、ALBはクライアントの証明書チェーン全体をバックエンドターゲットに転送します。これは X-Amzn-Mtls-Clientcert という名前のHTTPヘッダーを介して行われます。リーフ証明書を含むチェーンは、+、=、/を安全な文字として使用してURLエンコードされたPEM形式で送信されます。mTLSパススルーモードを使用する際の考慮事項は以下の通りです。 クライアント証明書が存在しない場合、ALBはヘッダーを追加しません。バックエンドがこれを処理する必要があります。 バックエンドターゲットがクライアント認証とエラー処理を担当します。 HTTPSリスナーの場合、ALBはクライアント-ALB TLSを終端し、ターゲットにインストールされた証明書を使用して新しいALB-バックエンドTLSを開始します。 ALBのTLS終端により、ロードバランシングにALBの任意のルーティングアルゴリズムを使用できます。 mTLS検証モード mTLS検証モードを有効にするには、CA証明書バンドルを含むトラストストアを作成します。これは AWS Certificate Manager（ACM） 、AWS Private CA、または独自の証明書をインポートすることで実現できます。Amazon S3に保存され、トラストストアにリンクされた証明書失効リスト（CRL）を使用して、失効した証明書を管理します。 ALBはトラストストアに対するクライアント証明書の検証を処理し、不正なリクエストを効果的にブロックします。このアプローチにより、バックエンドターゲットからmTLS処理をオフロードし、システム全体の効率を向上させます。ALBはS3からCRLをインポートし、S3への繰り返しフェッチなしでチェックを実行し、レイテンシを最小限に抑えます。 クライアント認証を超えて、ALBは HTTPヘッダー （例： X-Amzn-Mtls-Clientcert-Leaf ）を通じてクライアント証明書メタデータをHTTPヘッダー経由でバックエンドSAP Web Dispatcherに送信します。これにより、SAPサーバーが元の「ホストヘッダー」情報を保持する要件を満たすために、証明書の詳細に基づいてバックエンドターゲットで追加のロジック実装が可能になります。 これにより、SSL接続を終端するAWSロードバランサーなどの非SAPソースから発信された場合でも、サーバーがクライアント証明書メタデータを一貫して処理できるようになります。ALB – SAP Web Dispatcher – SAPサーバー間でエンドツーエンド暗号化を実装している場合は、 icm/HTTPS/client_certificate_header_name などのSAP Web Dispatcherプロファイルパラメータを設定する必要があります。詳細については、 このリンク を参照してください。 推奨事項 AWS上でのSAPワークロードデプロイメントには、mTLS検証モードの実装を推奨します。これにより、可能な限り早期（ALBレイヤー）で検証と認証をオフロードできるためです。mTLS検証モードは、RISE with SAP on AWSでもサポートされています。 mTLS検証モードのアーキテクチャパターン 図2. AWS上のSAPワークロードのmTLS検証認証データフロー 上記のアーキテクチャは、AWS Direct Connectを通じて閉鎖されたオンプレミスとAWS VPCでmTLS認証がどのように実装されるかを説明しています。mTLS認証は、インターネット接続を持つリモートユーザーに対しても実装できます。 アーキテクチャフロー ユーザーは、クライアントデバイス（ラップトップおよび/またはモバイル）にX.509証明書をインストールします。 クライアントデバイスはALBへの接続を開始し、それぞれの証明書を共有して、両方が互いを検証できるようにします。ALBの検証はAmazon S3をトラストストアとして活用します。 検証が完了すると、ALBは検証と認証のためにSAP Web Dispatcherに接続を転送します。 SAP Web Dispatcherは、検証と認証のためにSAPインスタンス（S/4HANA、ABAPスタックなど）に接続を転送します。 実装手順 詳細な実装手順はこちら で確認できます。これらの設定手順は、安全なクライアント-サーバー認証の基盤を確立します： Amazon S3を使用してトラストストアを設定します。 プライベート認証局（CA）と中間証明書を保存するために Amazon S3バケットを作成 します。 EC2コンソールを通じて トラストストア を設定し、S3バケットにリンクします。 ネットワーク接続に対する追加のセキュリティ制御のために証明書失効リスト（CRL）を実装します。 Application Load Balancer（ALB）を設定します。 AWS Certificate Manager を使用してALB用の SSLパブリック証明書を要求 します。 要求されたSSLパブリック証明書に関連付けることでmTLSを有効にする HTTPSリスナー を作成します。 ALBからのトラフィックのみを許可するインバウンドルールを設定して、 SAP Web Dispatcher専用のセキュリティグループを作成 します。 SAP Web Dispatcher用の ターゲットグループを作成 し、ALBにマッピングします。 SAPインスタンス（SAP S/4HANAなど）をバックエンドとしてターゲットするようにSAP Web Dispatcherを設定します。 sapgenpseコマンド を使用して、ルートおよび中間証明書をSAP WebDispatcherにインポートします。 SAP Web Dispatcher用のSSLパブリック証明書を（同じプライベートCAから）生成し、 sapgenpseコマンド を使用してインストールします。 SAPパラメータ icm/HTTPS/client_certificate_header_name = x-amzn-mtls-clientcert を実装します。 SAPドキュメント を参照してください。 安全な接続を受け入れるようにSAP S/4HANAを設定します。 SAP S/4HANAのSTRUSTトランザクションにルートおよび中間証明書をインポートします。 SAP Web Dispatcherに割り当てられたSSL証明書の詳細でSAPパラメータ icm/trusted_reverse_proxy を実装します。 SAPドキュメント を参照してください。 料金 Application Load Balancerの料金に関する詳細情報は このリンク で確認できます。mTLS認証に特に関連して、mTLS検証ユースケースシナリオに基づいてALBに関連付けられたトラストストアあたりの追加の時間料金があります。 S/4 HANAアプリケーションが平均して1秒あたり1つの新しい接続を受信し、それぞれが2分間持続すると仮定できます。クライアントは平均して1秒あたり5つのリクエストを送信し、リクエストとレスポンスの処理バイト数の合計は1秒あたり300 KBです。ロードバランサーでクライアントリクエストをルーティングするために1つのルールを設定し、Mutual TLSシナリオ用に1つのトラストストアを関連付けています。 米国東部（バージニア北部）リージョンの料金を使用して、月次Application Load Balancerコストを以下のように計算します： 新しい接続（1秒あたり） ：各LCU(Load Balancer Capacity Unit)は1秒あたり25の新しい接続を提供します（1時間の平均）。アプリケーションが1秒あたり1つの新しい接続を受信するため、これは0.04 LCU（1秒あたり1接続 / 1秒あたり25接続）に相当します。 アクティブ接続（1分あたり） ：各LCUは1分あたり3,000のアクティブ接続を提供します。アプリケーションは1秒あたり1つの新しい接続を受信し、それぞれが2分間持続します。これは1分あたり120のアクティブ接続、または0.04 LCU（1分あたり120アクティブ接続 / 1分あたり3,000アクティブ接続）に相当します。 処理バイト数（1時間あたりGB） ：各LCUは1時間あたり1 GBの処理バイトを提供します。各クライアント接続が1秒あたり300 KBのデータを転送するため、これは1時間あたり1.08 GBまたは1.08 LCU（1.08 GB/1 GB）に相当します。 ルール評価（1秒あたり） ：10の無料ルールのため、この次元は料金に影響しません。 これらの値を使用して、時間料金は4つの次元で消費される最大LCUを取ることで計算されます。この例では、処理バイト次元（1.08 LCU）が新しい接続（0.04 LCU）、アクティブ接続（0.04 LCU）、ルール評価（0 LCU）よりも大きく、1時間あたり$0.00864（1.08 LCU * LCUあたり$0.008）または月額$6.22（$0.00864 * 24時間 * 30日）の合計料金となります。 $0.0225（ALB時間）の時間料金と0.0056（トラストストア）の時間料金を追加すると、Application Load Balancerの総コストは： 1時間あたり$0.03674（$0.0281時間料金 + $0.00864 LCU料金）；または 月額$26.4528（$0.03114 * 24時間 * 30日） 。 まとめ Application Load BalancerのmTLSサポートは、SAPランドスケープでプリンシパル伝播を実装するための堅牢な基盤を提供します。この統合により、AWSのマネージドサービスを活用しながら、安全でスケーラブル、かつ保守可能なSSOソリューションが可能になります。 主要なポイント： ALBのmTLSサポートがプリンシパル伝播の実装を簡素化します。 SAP Web Dispatcherとの統合により、認証情報の適切なマッピングが保証されます。 AWSマネージドサービスが運用オーバーヘッドを削減します。 証明書ベースの認証によるセキュリティの強化。 ALBを使用してmTLS認証を実装することで、組織は従業員により良いユーザーエクスペリエンスを提供しながら、SAPアプリケーションのセキュリティ体制を向上させることができます。このソリューションは、アプリケーションランドスケープ全体で安全で効率的な認証メカニズムを維持する必要があるAWS上でSAPワークロードを実行している企業に特に関連があります。 AWS Well Architected Framework（SAP Lens） に含まれるセキュリティのベストプラクティスに常に従い、証明書とトラストストアを定期的に更新することを忘れないでください。 SAP投資からより多くの価値を得る方法についてのインスピレーションを得るために、 AWS for SAPブログ で詳細をお読みください。 SAP on AWSディスカッションに参加 お客様のアカウントチームとAWSサポートチャネルに加えて、最近 re:Post – AWSコミュニティのための再構築されたQ&amp;Aエクスペリエンスを開始しました。AWS for SAPソリューションアーキテクチャチームは、お客様とパートナーを支援するために回答できるディスカッションと質問について、AWS for SAPトピックを定期的に監視しています。質問がサポート関連でない場合は、re:Postでのディスカッションに参加し、コミュニティの知識ベースに貢献することを検討してください。 クレジット 貢献してくれた以下のチームメンバーに感謝します：Derek Ewell、Sreenath Middhi、Rajendra Narikimelli、Joachim Aumman、Arne Knoeller、Adam Hill。 <!-- '"` --> 本ブログの翻訳はAmazon Q Developer CLIによる機械翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

こんにちは。ソリューションアーキテクトの大南です。 2025 年 11 月 6 日に「AWS 秋のオブザーバビリティ祭り 2025 〜最新アップデートと生成 AI × オブザーバビリティ〜」と題したイベントを開催しました。AWS オブザーバビリティ祭りはこれまで半年ごとの春と秋に継続して実施しており今回で 5 回目のイベントとなります。ご参加いただきました皆様には、改めて御礼申し上げます。今までの開催報告ブログはこちら( 2023秋 、 2024春 、 2024秋 、 2025春 )。 本ブログでは、その内容を簡単にご紹介しつつ、発表資料を公開いたします。今回のイベントでは、前回のオブザーバビリティ祭り以降のアップデートのご紹介、また AWS オブザーバビリティサービスに組み込まれた生成 AI エージェントの活用や運用のユースケースを想定した MCP Server の活用、Amazon CloudWatch GenAI Observability を活用した AI エージェントのためのオブザーバビリティ、クロスアカウントやクロスリージョン環境での CloudWatch 機能の活用、X-Ray SDK と Daemon のサポート終了に伴う移行方法のガイド、という実際の運用ですぐ活用できる内容を中心にご紹介しました。日々の運用にすぐ活かせる内容となっておりますので、ぜひご活用ください！ セッションの紹介 AWS オブザーバビリティサービスアップデート アマゾン ウェブ サービス ジャパン 合同会社 スペシャリストソリューションアーキテクト 加藤 正樹 セッション資料 セミナー開始は、Specialist SA 加藤より、AWS オブザーバビリティアップデートと題して、モニタリングとオブザーバビリティの違いや、オブザーバビリティで必要となるデータ、AWS の提供するオブザーバビリティサービスについておさらいをし、春のオブザーバビリティ祭り以降の最新機能アップデートについてご紹介しました。Amazon CloudWatch Logs のログイベントサイズの増加や、Amazon CloudWatch Metrics Insights のメトリクスデータのクエリ可能な期間が3時間から2週間へ拡大されたアップデートなど運用業務で嬉しいアップデートについて解説しました。Database Performance Insights のサポート終了に伴う CloudWatch Database Insights への移行ガイドなども確認しておきたいポイントです。機能アップデートをまとめておさらいしたい方は、ぜひご確認ください。 生成 AI で進化する AWS オブザーバビリティ アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 梅津 寛子 アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 大石 美緒 セッション資料 次に、SA 梅津よりオブザーバビリティにおける運用課題への解決手段として AIOps を活用するアプローチをご紹介しました。Amazon CloudWatch へ組み込まれた AI 機能(CloudWatch Investigations、Query Generator、CloudWatch Logs Anomaly Detection、CloudWatch Anomaly Detection)を活用してこれまでのインシデント調査および対応をより効率化できることを示しました。加えて SA 大石より、CloudWatch に関する MCP Server(Amazon CloudWatch MCP Server、Amazon CloudWatch Application Signals MCP Server)を Amazon Q Developer CLI を利用してインシデント調査からレポーティングを行うデモをご紹介しました。CloudWatch Investigations と MCP Server の使い分けが気になる方は必見です。 Amazon Bedrock AgentCore で実現！お手軽 AI エージェントオブザーバビリティ アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 大西 朔 セッション資料 SA 大西より、AI エージェントの開発・運用を楽にするための Amazon Bedrock AgentCore を活用した AI エージェントのオブザーバビリティについてご紹介しました。2025 年 10 月 13 日に GA となった Amazon Bedrock AgentCore の全体像に触れた後、AgentCore Observability にフォーカスし、AI エージェントを扱う際に必要な観点を解説しました。CloudWatch GenAI Observability 機能を通して AgentCore におけるトレースのデータ構造をはじめとして取得可能な情報について共有いたしました。既に AI エージェントを開発・運用中の方やこれから導入を検討される方におすすめです！ クロスアカウント/クロスリージョンのオブザーバビリティ アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 大南 賢亮 セッション資料 次に SA 大南より、クロスアカウントやクロスリージョン環境で活用できる CloudWatch の機能についてご紹介しました。これまで CloudWatch クロスアカウントオブザーバビリティと、クロスアカウントクロスリージョン CloudWatch コンソールという2つの機能がありましたが、2025年9月のアップデートにより、クロスアカウントクロスリージョン環境化でログデータを一元化する機能が追加されました。それぞれの機能について特徴と適したユースケースを解説し、実装パターンを提示しました。クロスアカウントやクロスリージョンでの CloudWatch を活用したオブザーバビリティについてご興味がある方はぜひご確認ください。 X-Ray SDK と Daemon のサポート終了と移行ガイド アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 津和崎 美希 セッション資料 最後は SA 津和崎より、サポート終了がアナウンスされた AWS X-Ray SDK と Daemon の移行方法についてご説明しました。X-Ray の中でも API やコンソールは従来通り利用でき、今回のサポート終了の対象は SDK と Daemon が対象であることやサービス上変更のない部分、それを踏まえて X-Ray の概念を OpenTelemetry に置き換える必要があることを詳細にご紹介しました。移行に関する具体的なアプローチにも触れ、すぐ作業にとりかかれる内容を網羅しています。現在 AWS X-Ray と Daemon をご利用の方には必見の内容となっていますので、 こちら のAWS X-Ray SDK /Daemon サポート終了に関するブログとともにご確認ください。 まとめ 今回は、「最新アップデートと生成 AI × オブザーバビリティ」というテーマで様々な立場の方がすぐ活用できる実践的な内容を中心に様々な機能やユースケースをご紹介しました。本イベントをきっかけにより皆様の業務が効率化でき、より高度な取り組みにつながるよう貢献できましたら幸いです。今後も、お客様のシステム運用を少しでも効率化できるように、このようなイベントを企画し、情報発信を継続していきます。AWS のサービスを利用することをご検討いただいているお客様がいらっしゃいましたら、無料で個別相談会を開催しておりますので、 こちらのリンク からぜひお申し込みください。 アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 大南 賢亮

概要 AWS では、金融機関のお客様が AWS 上でシステムを構築する際の参考となる「 金融リファレンスアーキテクチャ日本版 」を提供しています。このたび、生成 AI に関する新たなコンテンツを追加しました。 金融機関における生成 AI の活用は、業務効率化と顧客体験向上の両面で大きな期待が寄せられています。一方で、機密情報の取り扱いやコンプライアンス要件への対応など、金融機関特有のセキュリティ要件を満たす必要があります。 今回、以下の 2 つのコンテンツを追加しました： 1. 生成 AI ワークロードのリファレンスアーキテクチャ : セキュリティ要件に対応したサンプル実装 2. 金融機関での生成 AI ユースケース : 具体的な活用例の紹介 1. 生成 AI ワークロードのリファレンスアーキテクチャ 概要 AWS Samples で公開されている「 Generative AI Use Cases (GenU) 」の閉域版をベースに、金融機関のセキュリティ要件に対応するためのカスタマイズを施したサンプル実装です。AWS CDK によるデプロイ手順を提供しており、実際に環境を構築して動作を確認できます。 GitHub : doc/reference-arc-genai GenU は、チャット、文章生成、要約、翻訳、RAG（Retrieval-Augmented Generation）、画像生成、動画生成など、多様な生成 AI ユースケースを提供するオープンソースアプリケーションです。本リファレンスアーキテクチャでは、これを金融機関で安全に活用するための実装パターンを示しています。 金融機関向けセキュリティ強化 本サンプル実装では、GenU 閉域版に対して以下のカスタマイズを施しています： 閉域ネットワーク構成 : システム間の通信を閉域ネットワーク内に閉じる構成 暗号化の強化 : AWS KMS カスタマーマネージドキーによるデータ保護 Amazon Bedrock Guardrails の設定強化 : 機密情報の検出・ブロック、金融業界向けトピックフィルタ、日本語対応 監視とガバナンス : Amazon CloudWatch による利用状況の可視化 詳細なアーキテクチャ構成については、アーキテクチャ解説書をご覧ください。 提供コンテンツ アーキテクチャ解説書 : GenU の主要機能と金融機関での活用方法、セキュリティ強化の詳細 FISC マッピング : FISC 安全対策基準（第 13 版）への対応状況 デプロイ手順書 : サンプル実装のデプロイ方法 2. 金融機関での生成 AI ユースケース 概要 生成 AI の具体的な活用例として、金融機関での実践的なユースケースを紹介しています。各ユースケースでは、Amazon Bedrock を中心とした AWS サービスを活用した構成例と、実装のポイントを解説しています。一部のユースケースについては、AWS CDK によるデプロイ手順を提供しており、実際の業務で利用可能なアプリケーションとして環境を構築できます。 GitHub : doc/fsi-case-study/reference-arc-genai-usecase 文書・コンテンツ審査 詳細はこちら | デプロイ可能 金融機関における膨大な文書審査業務を、AI と人間の協働（Human in the Loop）で効率化するソリューションです。 審査基準となるガイドライン文書をアップロードするだけで、AI が自動的にチェックリストを生成し、審査対象の文書を自動審査します。金融商品広告の法令・規制チェック、営業資料の社内コンプライアンス審査、マーケティング資料のブランドガイドライン準拠確認、ESG 報告書の業界ベストプラクティス準拠確認などに適用できます。 導入メリット : 審査時間の短縮、審査品質の標準化、判断根拠の明確化 AI を活用した営業・窓口対応トレーニング（ロールプレイ） 詳細はこちら | デプロイ可能 営業担当者や窓口担当者のトレーニングを、AI を活用したロールプレイで効率化します。AI が顧客役を演じ、様々なシナリオ（クレーム対応、商品説明、契約手続きなど）での対応練習を可能にします。24 時間いつでも利用でき、対応履歴の記録と振り返りができます。 導入メリット : トレーニングコストの削減、新人教育の効率化、対応品質の標準化 契約書業務アシスタント 詳細はこちら 契約書関連業務を包括的に支援する AI アシスタントシステムです。複数の専門 AI エージェント（スーパーバイザーエージェント、契約書作成エージェント、既存契約確認エージェント、契約 Q&amp;A エージェント）が連携して動作し、ユーザーの要求を自動的に適切なエージェントに振り分けます。 新規契約書の作成や既存契約状況の確認、契約関連質問への対応を自然言語での操作で実現します。 導入メリット : 契約書作成時間の短縮、問い合わせ対応の迅速化、専門知識の組織的活用 ATM 不正検知（高齢者電話利用） 詳細はこちら ATM 周辺での不審な行動（電話をしながらの ATM 操作など）を検知し、特殊詐欺被害を未然に防ぐソリューションです。Amazon Bedrock 上のマルチモーダルモデル活用して、既存の防犯カメラ映像からリアルタイムで不審な行動を検知し、店舗スタッフに即座に通知します。 導入メリット : 特殊詐欺被害の未然防止、顧客保護と信頼性の向上、既存インフラの有効活用 まとめ 今回追加した生成 AI に関するコンテンツは、金融機関における生成 AI 活用の第一歩として、セキュリティ要件に配慮したサンプル実装と、具体的な活用例を提供しています。 リファレンスアーキテクチャ では、GenU をベースに金融機関のセキュリティ要件に対応した実装パターンを示し、 ユースケース では、実際の業務での活用イメージを具体的に紹介しています。デプロイ手順も提供していますので、ぜひ実際に環境を構築して動作を確認してみてください。 金融リファレンスアーキテクチャ日本版の全てのコンテンツは GitHub リポジトリ から利用できます。フィードバックや質問については、GitHub の Issue としてご登録ください。皆様からのご意見をお待ちしております。 参考リンク 生成 AI ワークロードのリファレンスアーキテクチャ アーキテクチャ解説書 FISC マッピング デプロイ手順書 金融機関での生成 AI ユースケース ユースケース一覧 文書・コンテンツ審査 AI を活用した営業・窓口対応トレーニング（ロールプレイ） 契約書業務アシスタント ATM 不正検知 その他 金融リファレンスアーキテクチャ日本版 GitHub リポジトリ Generative AI Use Cases (GenU) 本ブログ記事は、AWS のソリューションアーキテクト 都築了太郎 が執筆いたしました。

このブログは Transform your MCP architecture: Unite MCP servers through AgentCore Gateway の翻訳記事です。 — AI エージェントが大規模に利用されていく中で、独自の Model Context Protocol (MCP) サーバーを作成し、特定のユースケースやドメイン、組織の機能やチーム向けに AI エージェントをカスタマイズするケースが増えています。また、既存の MCP サーバーやオープンソースの MCP サーバーを AI ワークフロー用に統合する必要もあります。カスタムビルド、パブリック利用可能、オープンソースなどの様々な形態の MCP サーバーを、AI エージェントが容易に利用できる組織全体で統一されたインターフェースに効率的に統合する方法が必要です。 今年の初めに AWS は Amazon Bedrock AgentCore Gateway を発表しました。これは完全マネージド型サービスで、中央集約型の MCP サーバーとして機能し、エージェントがツールを発見、アクセス、呼び出すための統一されたインターフェースを提供します。そして直近では、 AgentCore Gateway に既存の MCP サーバーをターゲットタイプとしてサポートする機能拡張を実施しました。この機能により、複数のタスク固有の MCP サーバーを、単一の MCP ゲートウェイインターフェースの背後にグループ化できます。これにより、個別のゲートウェイを維持する運用の複雑さが軽減され、(AgentCore Gateway のターゲットとしてこれまで利用可能であった) REST API や AWS Lambda 関数と同様に中央集約型のツールおよび認証管理が提供されます。 中央集約型のアプローチを取らない場合、1) 組織全体でツールを発見し共有することが困難となる、2) 複数の MCP サーバー間での認証管理が複雑になる、3) 各サーバーに対して個別のゲートウェイインスタンスを維持する管理工数、が課題となります。Amazon Bedrock AgentCore Gateway は、既存の MCP サーバーをネイティブターゲットとして扱うことでこれらの課題を解決し、ルーティング、認証、ツール管理のための単一の制御ポイントを顧客に提供します。これにより、MCP サーバーの統合が他のターゲットをゲートウェイに追加するのと同じ様に簡単に実現できます。 MCP のサイロを打破する: エンタープライズチームが統一された Gateway を必要とする理由 複数のチームが特定のドメイン用に特化した MCP サーバーを運用する e コマース注文システムのケースを考えてみましょう。 ショッピングカートチームはカート管理ツールを持つ MCP サーバーを運用しています。 製品カタログチームは製品の閲覧と検索のための MCP サーバーを運用しています。 プロモーションチームはプロモーションロジックを処理する MCP サーバーを運用しています。 以前は、注文エージェントはこれらの各 MCP サーバーに個別に接続し認証コンテキストを管理する必要がありました。AgentCore Gateway の MCP サーバーターゲットにより、単一のゲートウェイの下に統合しながら、チーム固有の所有権とアクセス制御を維持できるようになりました。このアプローチの威力は、組織利用における MCP サーバーの設計を柔軟にできることです。複数のロジックに基づいて MCP サーバーをグループ化できます。 ビジネスユニットとの整合 : MCP サーバーをビジネスユニットごとに整理します。 製品機能の境界 : 各製品チームがドメイン固有のツールを持つ MCP サーバーを所有し、明確な所有権を維持しながらエージェント用の統一されたインターフェースを提供します。 セキュリティとアクセス制御 : 異なる MCP サーバーには異なる認証メカニズムが必要です。ゲートウェイが認証の複雑さを処理し、認可されたエージェントが必要なツールに簡単にアクセスできるようにします。 次の図は、注文エージェントが AgentCore Gateway を通じて複数の MCP サーバーとやり取りする様子を示しています。エージェントはゲートウェイに接続し、利用可能なツールを発見します。各チームはドメイン固有のツールを管理しながら、組織全体での一貫したエージェント利用体験に貢献します。ゲートウェイはツール名の競合、認証を処理し、ツール全体で統一的なセマンティック検索を提供します。 AgentCore Gateway は、最新のエージェントアーキテクチャにおける統合ハブとして機能し、多様なエージェント実装を幅広いツールプロバイダーと接続するための統一されたインターフェースを提供します。図に示されているアーキテクチャは、ゲートウェイがエージェントとツール実装アプローチの間のギャップを埋める方法を示しており、現在は MCP サーバーターゲットを直接統合する機能が強化されています。 AgentCore Gateway 統合アーキテクチャ AgentCore Gateway では、ターゲットがエージェントに提供するツールを規定します。ターゲットには Lambda 関数、OpenAPI 仕様、Smithy モデル、MCP サーバー、その他のツール定義を指定することができます。 アーキテクチャのターゲット統合側は、ツール統合におけるゲートウェイの汎用性を示しています。MCP サーバーターゲット機能により、ゲートウェイはパブリック MCP サーバーからのツールを直接組み込むことができ、他のターゲットタイプと同等に扱います。この機能は、ある AgentCore Gateway インスタンスが別のインスタンスのターゲットとして機能するフェデレーションシナリオにも拡張され、組織の境界を越えた階層的なツール編成が可能になります。ゲートウェイは、ツールとして公開されるエージェントを持つ AgentCore Runtime インスタンス、プライベート MCP サーバー、従来の AWS Lambda 関数、Smithy および AWS サービス API の両方とシームレスに統合できます。 ターゲットの多様性に加えて、ゲートウェイの認証アーキテクチャは更なる運用上のメリットを提供します。ゲートウェイは、インバウンド認証をターゲットシステムから切り離し、エージェントが単一のインターフェースを通じて複数の ID プロバイダーを使用するツールにアクセスできるようにします。この中央集約型のアプローチにより、AI エージェントの開発、デプロイ、メンテナンスが簡素化されます。MCP サーバーターゲットにも同じアプローチを使用でき、ゲートウェイがターゲット用に構成された ID プロバイダーを使用してサーバーとのインターフェースの複雑さを管理します。 ゲートウェイが提供する認証機能により、統一されたアーキテクチャでツールを管理することができます。エージェントがツールの発見を要求すると、ゲートウェイはターゲットの種類によらず一貫したツール情報を提供します。セマンティック検索機能はツールタイプ全体で動作するため、エージェントは実装に関係なく関連するツールを発見できます。ツールの呼び出し中、ゲートウェイは必要なプロトコル変換、認証フロー、データ変換を処理し、異なるターゲットシステムの複雑さを管理しながら、エージェントにクリーンで一貫したインターフェースを提示します。 MCP サーバーターゲットサポートの追加は、ゲートウェイの機能における重要な進化を表しています。従来の API や Lambda 関数を維持しながら、MCP ネイティブツールを直接統合できるようになりました。この柔軟性により、段階的な移行戦略が可能になり、チームは既存の統合を継続的に運用しながら、独自のペースで MCP ネイティブ実装を採用できます。ゲートウェイの同期メカニズムは、異なるターゲットタイプ間でツール定義が最新の状態を保つことを保証し、その認証および承認システムは、基盤となるツール実装に関係なく一貫したセキュリティ制御を提供します。 ゲートウェイは、MCP サーバー、従来の API、サーバーレス関数を一貫したツール環境に統合します。この機能は、エンタープライズグレードのセキュリティとパフォーマンスとともに、エージェントコンピューティングにとって有益なインフラストラクチャとなります。 ソリューションのウォークスルー このセクションでは、AgentCore Gateway で MCP サーバーターゲットを設定する手順をご紹介します。MCP サーバーを AgentCore Gateway に追加することで、大規模な MCP サーバーを管理する際のツール管理、セキュリティ認証、運用のベストプラクティスを一元化できます。 AgentCore Gateway へ MCP Server を追加する AgentCore Gateway を作成し、MCP Server をターゲットとして追加します。 前提条件 次の前提条件を確認してください。 Amazon Bedrock AgentCore アクセス権を持つ AWS アカウント。詳細については、 Permissions for AgentCore Runtime のドキュメントを参照してください。 Python 3.12 以降 OAuth 2.0 の基本的な理解 複数のインターフェースを通じてゲートウェイを作成し、ターゲットを追加できます。 AWS SDK for Python (Boto3) AWS Management Console AWS Command Line Interface (AWS CLI) 高速で簡単なセットアップのための AgentCore starter toolkit 次の実用的な例とコードスニペットは、Amazon Bedrock AgentCore Gateway のセットアップと使用方法を示しています。インタラクティブに操作したい場合は、 GitHub の Jupyter Notebook サンプル をご参照ください。 ゲートウェイを作成する ゲートウェイを作成するには、AgentCore starter toolkit を使用して、JWT ベースのインバウンド認証用に Amazon Cognito を使用した デフォルトの認証構成を作成 できます。Cognito の代わりに別の OAuth 2.0 準拠の認証プロバイダー を使用することもできます。 import time import boto3 gateway_client = boto3.client("bedrock-agentcore-control") # 認証構成を作成します。この Gateway へのアクセスを承認されるクライアントを指定します auth_config = { "customJWTAuthorizer": { "allowedClients": ['&lt;cognito_client_id&gt;'], # クライアントは Cognito で構成された ClientId と一致する必要があります "discoveryUrl": '&lt;cognito_oauth_discovery_url&gt;', } } # create_gateway API を呼び出します # この操作は非同期なので、Gateway の作成に時間がかかる場合があります # この Gateway は CUSTOM_JWT オーソライザー、つまり auth_config で参照する Cognito User Pool を活用します def deploy_gateway(poll_interval=5): create_response = gateway_client.create_gateway( name="DemoGateway", roleArn="&lt;IAM Role&gt;", # IAM Role には Gateway の作成/一覧表示/取得/削除の権限が必要です protocolType="MCP", authorizerType="CUSTOM_JWT", authorizerConfiguration=auth_config, description="AgentCore Gateway with MCP Server Target", ) gatewayID = create_response["gatewayId"] gatewayURL = create_response["gatewayUrl"] # デプロイを待機します while True: status_response = gateway_client.get_gateway(gatewayIdentifier=gatewayID) status = status_response["status"] if status == "READY": print("✅ AgentCore Gateway is READY!") break elif status in ["FAILED"]: print(f"❌ Deployment failed: {status}") return None print(f"Status: {status} - waiting...") time.sleep(poll_interval) if __name__ == "__main__": deploy_gateway() # &lt; &gt; の値は実際の値に置き換える必要があります サンプル MCP Server を作成する 例として、静的な応答を返す 3 つの簡単なツールを持つサンプル MCP サーバーを作成しましょう。サーバーは stateless_http=True を指定した FastMCP を使用しており、これは AgentCore Runtime の互換性に必要 です。 from mcp.server.fastmcp import FastMCP mcp = FastMCP(host="0.0.0.0", stateless_http=True) @mcp.tool() def getOrder() -&gt; int: """注文を取得します""" return 123 @mcp.tool() def updateOrder(orderId: int) -&gt; int: """既存の注文を更新します""" return 456 @mcp.tool() def cancelOrder(orderId: int) -&gt; int: """既存の注文をキャンセルします""" return 789 if __name__ == "__main__": mcp.run(transport="streamable-http") AgentCore Runtime デプロイを構成する 次に、starter toolkit を使用して AgentCore Runtime デプロイを構成します。このツールキットは、起動時に Amazon ECR リポジトリを作成し、AgentCore Runtime へのデプロイ用の Dockerfile を生成できます。この実装は例として示しているもののため、実際には独自の MCP サーバー実装を使用してください。実際の環境では、MCP サーバーのインバウンド認証はゲートウェイの構成とは異なる可能性があります。その場合、 Runtime 認証用の Amazon Cognito ユーザープールを作成する サンプルコードを参照してください。 from bedrock_agentcore_starter_toolkit import Runtime from boto3.session import Session boto_session = Session() region = boto_session.region_name print(f"Using AWS region: {region}") required_files = ['mcp_server.py', 'requirements.txt'] for file in required_files: if not os.path.exists(file): raise FileNotFoundError(f"Required file {file} not found") print("All required files found ✓") agentcore_runtime = Runtime() auth_config = { "customJWTAuthorizer": { "allowedClients": [ '&lt;runtime_cognito_client_id&gt;' # クライアントは Cognito で構成された ClientId と一致する必要があり、Gateway Cognito プロバイダーとは別にすることができます ], "discoveryUrl": '&lt;cognito_oauth_discovery_url&gt;', } } print("Configuring AgentCore Runtime...") response = agentcore_runtime.configure( entrypoint="mcp_server.py", auto_create_execution_role=True, auto_create_ecr=True, requirements_file="requirements.txt", region=region, authorizer_configuration=auth_config, protocol="MCP", agent_name="mcp_server_agentcore" ) print("Configuration completed ✓") # &lt; &gt; の値は実際の値に置き換える必要があります MCP サーバーを AgentCore Runtime 上で起動する Dockerfile ができたので、MCP サーバーを AgentCore Runtime 上で起動しましょう。 print("Launching MCP server to AgentCore Runtime...") print("This may take several minutes...") launch_result = agentcore_runtime.launch() agent_arn = launch_result.agent_arn agent_id = launch_result.agent_id print("Launch completed ✓") encoded_arn = agent_arn.replace(':', '%3A').replace('/', '%2F') mcp_url = f"https://bedrock-agentcore.{region}.amazonaws.com/runtimes/{encoded_arn}/invocations?qualifier=DEFAULT" print(f"Agent ARN: {launch_result.agent_arn}") print(f"Agent ID: {launch_result.agent_id}") AgentCore Gateway のターゲットとして MCP サーバーを作成する AgentCore Gateway が AgentCore Runtime 上の MCP サーバーへアクセスする際のアウトバウンド認証用に、AgentCore Identity Resource Credential Provider を作成します。 identity_client = boto3.client('bedrock-agentcore-control', region_name=region) cognito_provider = identity_client.create_oauth2_credential_provider( name="gateway-mcp-server-identity", credentialProviderVendor="CustomOauth2", oauth2ProviderConfigInput={ 'customOauth2ProviderConfig': { 'oauthDiscovery': { 'discoveryUrl': '&lt;cognito_oauth_discovery_url&gt;', }, 'clientId': '&lt;runtime_cognito_client_id&gt;', # クライアントは Runtime オーソライザー用に Cognito で構成された ClientId と一致する必要があります 'clientSecret': '&lt;cognito_client_secret&gt;' } } ) cognito_provider_arn = cognito_provider['credentialProviderArn'] print(cognito_provider_arn) # &lt; &gt; の値は実際の値に置き換える必要があります MCP サーバーを指すゲートウェイターゲットを作成します。 gateway_client = boto3.client("bedrock-agentcore-control", region_name=region) create_gateway_target_response = gateway_client.create_gateway_target( name="mcp-server-target", gatewayIdentifier=gatewayID, targetConfiguration={"mcp": {"mcpServer": {"endpoint": mcp_url}}}, credentialProviderConfigurations=[ { "credentialProviderType": "OAUTH", "credentialProvider": { "oauthCredentialProvider": { "providerArn": cognito_provider_arn, "scopes": ["&lt;cognito_oauth_scopes&gt;"], } }, }, ], ) # ゲートウェイターゲットを非同期に作成します gatewayTargetID = create_gateway_target_response["targetId"] # &lt; &gt; の値は実際の値に置き換える必要があります ゲートウェイターゲットを作成した後、 get_gateway_target API 呼び出しを使用してゲートウェイターゲットのステータスを確認するポーリング処理を実装します。 import time def poll_for_status(interval=5): # READY ステータスをポーリングします while True: gateway_target_response = gateway_client.get_gateway_target(gatewayIdentifier=gatewayID, targetId=gatewayTargetID) status = gateway_target_response["status"] if status == 'READY': break elif status in ['FAILED', 'UPDATE_UNSUCCESSFUL', 'SYNCHRONIZE_UNSUCCESSFUL']: raise Exception(f"Gateway target failed with status: {status}") time.sleep(interval) poll_for_status() Strands Agents フレームワークでゲートウェイをテストする MCP サーバーからツールをリストするために、 Strands Agents でゲートウェイをテストしてみましょう。異なるエージェントフレームワークで構築された他の MCP 互換エージェントも使用できます。 from strands import Agent from mcp.client.streamable_http import streamablehttp_client from strands.tools.mcp.mcp_client import MCPClient def create_streamable_http_transport(): return streamablehttp_client(gatewayURL,headers={"Authorization": f"Bearer {token}"}) client = MCPClient(create_streamable_http_transport) with client: # listTools を呼び出します tools = client.list_tools_sync() # モデルとツールを使用してエージェントを作成します agent = Agent(model=yourmodel,tools=tools) ## 任意のモデルに置き換えることができます # サンプルプロンプトでエージェントを呼び出します。これは MCP listTools のみを呼び出し、LLM がアクセスできるツールのリストを取得します。以下は実際にツールを呼び出しません。 agent("Hi , can you list all tools available to you") # サンプルプロンプトでエージェントを呼び出し、ツールを呼び出して応答を表示します agent("Get the Order id") AgentCore Gateway での MCP サーバーのツール定義の更新 SynchronizeGatewayTargets API は、MCP サーバーターゲットからのツールのオンデマンド同期を可能にする新しい非同期操作です。MCP サーバーは、エージェントが発見して呼び出すことができるツールをホストします。時間の経過とともに、これらのツールを更新する必要があったり、既存の MCP サーバーターゲットに新しいツールを導入する必要があったりする場合があります。プロトコルハンドシェイクを実行し、利用可能なツールをインデックス化する SynchronizeGatewayTargets API を通じて外部 MCP サーバーに接続できます。この API により、MCP サーバーのツール構成を変更した後に、ツール定義を更新するタイミングを明示的に制御できます。 ターゲットが OAuth 認証で構成されている場合、API はまず AgentCore Identity サービスとやり取りして、指定された認証情報プロバイダーから必要な認証情報を取得します。これらの認証情報は、MCP サーバーとの通信を開始する前に、鮮度と利用可否について検証されます。認証情報の取得が失敗した場合、または期限切れのトークンが返された場合、同期操作は適切なエラー詳細とともに即座に失敗し、ターゲットは FAILED 状態に遷移します。認証なしで構成されたターゲットの場合、API はツール同期に直接進みます。 ツール処理ワークフローは、セッションを確立するための MCP サーバーへの初期化呼び出しから始まります。初期化が成功した後、API は MCP サーバーの tools/list 機能にページ分割された呼び出しを行い、パフォーマンスとリソース使用率を最適化するために 100 個のバッチでツールを処理します。各ツールのバッチは正規化を受け、API はターゲット固有のプレフィックスを追加して、他のターゲットからのツールとの命名の競合を防ぎます。処理中、ツール定義は異なるターゲットタイプ間での一貫性を促進するために正規化されますが、元の MCP サーバー定義からの重要なメタデータは保持されます。 同期フローは次のときに開始されます。 運用管理者が SynchronizeGatewayTargets API を開始し、AgentCore Gateway をトリガーして構成された MCP ターゲットを更新します。 ゲートウェイは MCP ターゲットへの安全なアクセスのために AgentCore Identity から OAuth トークンを取得します。 次に、ゲートウェイはバージョン機能を取得するために MCP サーバーとの安全なセッションを初期化します。 最後に、ゲートウェイは MCP サーバーの tools/list エンドポイントにページ分割された呼び出しを行ってツール定義を取得し、ゲートウェイが最新で正確なツールのリストを維持することを保証します。 SynchronizeGatewayTargets API は、AgentCore Gateway 内で MCP ターゲットを管理する際の重要な課題に対処します。それは、システムのパフォーマンスとリソース使用率を最適化しながら、利用可能なツールの正確な表現を維持することです。この明示的な同期アプローチが価値がある理由は次のとおりです。 スキーマの一貫性管理 : 明示的な同期がない場合、AgentCore Gateway は ListTools 操作中に MCP サーバーへのリアルタイム呼び出しを行う必要があるか (レイテンシと信頼性に影響)、古いツール定義を提供するリスクがあります。 SynchronizeGatewayTargets API は、新しいツールをデプロイした後や MCP サーバーで既存のツールを更新した後など、戦略的なタイミングでツールスキーマを更新できる制御されたメカニズムを提供します。このアプローチにより、ゲートウェイのツール定義がパフォーマンスを損なうことなくターゲット MCP サーバーの機能を正確に反映することが保証されます。 パフォーマンスへの影響のトレードオフ : API は、不整合な状態につながる可能性のある同時変更を防ぐために、同期中に楽観的ロックを実装しています。これは、競合がある場合に複数の同期リクエストが再試行する必要がある可能性があることを意味しますが、このトレードオフは次の理由から許容されます。 ツールスキーマの変更は、通常の実行時の発生ではなく、頻度の低い運用イベントです 同期のパフォーマンスコストは、通常のツール呼び出し中ではなく、明示的に要求されたときにのみ発生します キャッシュされたツール定義により、同期している間でも ListTools 操作に一貫して高いパフォーマンスが得られます。 SynchronizeGatewayTargets API を呼び出す 次のサンプルコードを使用して、SynchronizeGatewayTargets API を呼び出します。 gateway_client = boto3.client('bedrock-agentcore-control', region_name=REGION) synchronize_gateway_response = gateway_client.synchronize_gateway_targets( gatewayIdentifier=gatewayID, targetIdList=[gatewayTargetID] ) print(synchronize_gateway_response) ツールスキーマの暗黙的な同期 CreateGatewayTarget および UpdateGatewayTarget 操作中、AgentCore Gateway は明示的な SynchronizeGatewayTargets API とは異なる暗黙的な同期を実行します。この暗黙的な同期により、MCP ターゲットが有効で最新のツール定義で作成または更新されることが保証され、READY 状態のターゲットはすぐに使用可能と保証されます。これにより、作成/更新操作が他のターゲットタイプよりも時間がかかる可能性がありますが、検証されたツール定義のないターゲットを持つことの複雑さと潜在的な問題を防ぐのに役立ちます。 暗黙的な同期フローは次のときに開始されます。 運用管理者が CreateGatewayTarget または UpdateGatewayTarget 操作を使用して MCP ターゲットを作成または更新します。 AgentCore Gateway は新規または更新された MCP ターゲットを構成します。 ゲートウェイはツール定義を更新するために非同期で同期プロセスをトリガーします。 ゲートウェイは安全なアクセスのために AgentCore Identity から OAuth トークンを取得します。 次に、ゲートウェイはバージョン機能を取得するために MCP サーバーとの安全なセッションを初期化します。 最後に、ゲートウェイは MCP サーバーの tools/list エンドポイントにページ分割された呼び出しを行ってツール定義を取得し、ゲートウェイが最新で正確なツールのリストを維持することを保証します。 MCP ターゲットの ListTools の動作 AgentCore Gateway の ListTools 操作は、MCP ターゲットから以前に同期されたツール定義へのアクセスを提供し、パフォーマンスと信頼性を優先するキャッシュファーストアプローチに従います。ツール定義が静的に定義されている従来の OpenAPI または Lambda ターゲットとは異なり、MCP ターゲットツールは同期操作を通じて発見され、キャッシュされます。クライアントが ListTools を呼び出すと、ゲートウェイは MCP サーバーへのリアルタイム呼び出しを行うのではなく、永続ストレージからツール定義を取得します。これらの定義は、ターゲット作成/更新中の暗黙的な同期、または明示的な SynchronizeGatewayTargets API 呼び出しを通じて事前に取得したものです。この操作は正規化されたツール定義のページ分割されたリストを返します。 MCP ターゲットの InvokeTool (tools/call) の動作 MCP ターゲットの InvokeTool 操作は、 ListTools を通じて発見されたツールの実際の実行を処理し、ターゲット MCP サーバーとのリアルタイム通信を管理します。キャッシュベースの ListTools 操作とは異なり、tools/call は MCP サーバーとのアクティブな通信を必要とし、特定の認証、セッション管理、エラー処理が発生します。tools/call リクエストが到着すると、AgentCore Gateway はまず、ツールが同期された定義に存在することを検証します。MCP ターゲットの場合、AgentCore Gateway は MCP サーバーとのセッションを確立するために初期化呼び出しを実行します。ターゲットが OAuth 認証情報で構成されている場合、AgentCore Gateway は initialize 呼び出しを行う前に AgentCore Identity から新しい認証情報を取得します。これにより、ListTools が期限切れの認証情報を持つキャッシュされたツールを返した場合でも、実際の呼び出しは有効な認証を使用することが保証されます。 インバウンド認証フローは次のときに開始されます。 MCP クライアントは MCP プロトコルバージョンを使用したリクエストを AgentCore Gateway に初期化します。 次に、クライアントは tools/call リクエストをゲートウェイに送信します。 ゲートウェイは安全なアクセスのために AgentCore Identity から OAuth トークンを取得します。 ゲートウェイは MCP サーバーとの安全なセッションを初期化して、ツールの実際の実行を呼び出して処理します。 MCP ターゲットの検索ツールの動作 AgentCore Gateway の検索機能により、MCP ターゲットを含む異なるターゲットタイプ全体でツールのセマンティック検索が可能になります。MCP ターゲットの場合、検索機能は同期操作中にキャプチャされ、インデックス化された正規化されたツール定義で動作し、リアルタイムの MCP サーバー通信なしで効率的なセマンティック検索を提供します。 ツール定義が MCP ターゲットから同期されると、AgentCore Gateway は各ツールの名前、説明、パラメータの説明に対して自動的にベクトル表現を生成します。これらのベクトル表現は正規化されたツール定義と一緒に保存され、検索クエリの意図とコンテキストを理解するセマンティック検索を可能にします。従来のキーワードマッチングとは異なり、正確な用語が一致しない場合でもエージェントは関連するツールを発見できます。 ゲートウェイを通じて MCP サーバーツールを検索する 次の例を使用してゲートウェイを通じてツールを検索します。 import requests import json def search_tools(gateway_url, access_token, query): headers = { "Content-Type": "application/json", "Authorization": f"Bearer {access_token}" } payload = { "jsonrpc": "2.0", "id": "search-tools-request", "method": "tools/call", "params": { "name": "x_amz_bedrock_agentcore_search", "arguments": { "query": query } } } response = requests.post(gateway_url, headers=headers, json=payload, timeout=5) response.raise_for_status() return response.json() # 使用例 token_response = utils.get_token(user_pool_id, client_id, client_secret, scopeString, REGION) access_token = token_response['access_token'] results = search_tools(gatewayURL, access_token, "math operations") print(json.dumps(results, indent=2)) まとめ 最近発表された Amazon Bedrock AgentCore Gateway でのターゲットタイプとしての MCP サーバーサポートは、エンタープライズ AI エージェント開発における進歩です。この新機能は、セキュリティと運用効率を維持しながら MCP サーバー実装をスケーリングする際の重要な課題に対処します。既存の MCP サーバーを REST API や Lambda 関数と一緒に統合することにより、AgentCore Gateway は大規模なツール統合のためのより統一された、安全で管理しやすいソリューションを提供します。組織は、統一された認証、簡素化されたツール検出、削減されたメンテナンスオーバーヘッドの恩恵を受けながら、単一の中央集約型インターフェースを通じてツールを管理できるようになりました。 詳細情報と高度な構成については、 GitHub のコードサンプル 、 Amazon Bedrock AgentCore Gateway 開発者ガイド 、 Amazon AgentCore Gateway の料金 を参照してください。 著者について Frank Dallezotte は AWS の Senior Solutions Architect で、独立系ソフトウェアベンダーと協力して AWS 上でスケーラブルなアプリケーションを設計および構築することに情熱を持っています。彼はソフトウェアの作成、ビルドパイプラインの実装、クラウドでのこれらのソリューションのデプロイに関する経験があります。 Ganesh Thiyagarajan は Amazon Web Services (AWS) の Senior Solutions Architect で、ソフトウェアアーキテクチャ、IT コンサルティング、ソリューション提供において 20 年以上の経験があります。彼は ISV が AWS 上でアプリケーションを変革し、モダナイズするのを支援しています。また、AI/ML テクニカルフィールドコミュニティの一員として、顧客が Gen AI ソリューションを構築および拡張するのを支援しています。 Dhawal Patel は Amazon Web Services (AWS) の Principal Generative AI Tech lead です。彼は、Agentic AI、Deep learning、分散コンピューティングに関連する問題について、大企業から中規模のスタートアップまでさまざまな組織と協力してきました。

本ブログは 株式会社ほくつう 様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWSアカウントマネージャーの井沼です。 昨今の異常気象により、日本の地方自治体では、市民の安全を確保するために道路状況の可視化が重要な課題となっています。 特に豪雨や豪雪など気象条件が厳しい地域では、リアルタイムの道路情報が県民の安心・安全な生活に不可欠です。 今回は、福井県様と株式会社ほくつう様が共同で取り組まれた「 みち情報ネットふくい 」の AWS を活用した事例をご紹介します。 お客様のサービス概要 「みち情報ネットふくい」は、福井県内に設置された300を超えるカメラから、リアルタイムの渋滞状況や冬期間の除雪状況を県民に提供するウェブサイトです。 国や自治体向けの総合防災情報プラットフォームを提供し、多種多様な情報通信システムの設計・システム開発・施工・メンテナンスまでのワンストップサービスを手掛ける株式会社ほくつう様が、福井県土木部道路保全課様からの依頼を受けてシステムを構築されました。 「みち情報ネットふくい」は道路管理者の垣根を超えた一元的な交通状況の把握のために、国土交通省やネクスコ、市町、隣接県である滋賀県とも連携を進め、公開するカメラ画像を大幅に増加させています。 従来の課題と背景 福井県は過去に多くの豪雨災害や雪害を経験しています。こうした状況下で、県民が安全に生活するためには、リアルタイムの道路情報が不可欠です。 しかし、従来のシステムでは、全てオンプレミス環境で実現しており、以下のような問題に直面していました： 1.[伸縮性] 悪天候時のアクセス集中に伴うカメラ画像の表示遅延 2.[信頼性] システム障害時における長時間停止のリスク 3.[俊敏性] 配信サーバーのリソース調達に要する時間 解決策の検討と AWS 採用理由 これらの課題を解決するため、ほくつう様は柔軟に拡張が可能な俊敏性を持つクラウドサービスへの移行を検討されました。 複数のクラウドプロバイダーを比較検討した結果、AWSサービスの持つ高い信頼性と伸縮性、豊富な実績とそれに伴う情報量の多さからAWSの採用を決定されました。 実装の詳細 採用した AWS サービスとその役割 「みち情報ネットふくい」のシステム構築には、以下のAWSサービスが活用されています： ・Amazon Elastic Compute Cloud (EC2)：ウェブアプリケーションの実行環境として利用 ・Amazon Simple Storage Service (S3)： システム全体のログデータの収集・保存に活用 ・Amazon CloudFront：画像データなどのコンテンツの高速配信を実現 システム構成の概要 今回の刷新により、画像の配信環境の全てをオンプレミスからAWSに切り替えています。 システムは、カメラから送信される画像データをAmazon CloudFrontを通じて配信することで、アクセス集中時にも安定的にレスポンスできる構成となっています。 特筆すべき点として、東京リージョンと大阪リージョンの両方に同一の環境を構築し、マルチリージョン構成を採用しています。 Amazon CloudFrontのオリジンフェイルオーバー機能を活用することで、プライマリのサーバーにアクセスできない場合は自動的にセカンダリに切り替わる仕組みを実装しており、ダウンタイムを最小化させています。 この構成により、アクセス集中時でも安定したパフォーマンスの提供および、サーバー障害などのシステムトラブル時においてもサービスを継続できる高信頼性を実現しています。 カメラからの画像収集は引き続きオンプレミスを併用していますが、将来的にはこちらもAWS化を検討しています。 (画像配信環境の構成イメージ ) 導入効果 AWS クラウド基盤の導入により、以下の効果が得られました： 1.ピーク時の表示時間遅延解消 (1分以上 → 最大5秒以内、高負荷でも遅延無く表示) 2.従来環境と同等のコストで高い信頼性を実現 3.急増する需要に対して俊敏にリソース拡張を実現 (2週間 → 数分) お客様の声 福井県土木部道路保全課様の声 「道路は県民の生活や経済活動を支える欠かせないインフラです。『みち情報ネットふくい』は、そうした重要な情報を県民やドライバーの皆様にリアルタイムで分かりやすく提供できる、重要な仕組みです。AWSに移行してから、アクセスの集中しやすい冬の期間においてもリアルタイムで画像表示ができるようになり、県民の方々により一層安心してご活用いただけるようになりました。今後も、より多くの方に活用いただけるよう、さらなる機能強化を図ってまいります。」 株式会社ほくつう様の声 「従来、道路情報はそれぞれの機関が個別に公開しており、災害時などに一目で全体状況を把握できる仕組みがありませんでした。そうした不便さや県民の不安を解消したいという思いが、今回のシステム開発の原動力となりました。国・県・市町・高速道路といった異なる管轄の情報を一括して確認できる『みち情報ネットふくい』は、まさに“生活の安全・安心”を支えるインフラとして、県民に寄り添うことを意識して構築したものです。従来の環境ではシステム構築に半年以上かかるところを、AWS のクラウドサービスを活用することで約 1 か月という短期間で迅速に対応することができました。さらに、AWSのマルチリージョン構成を採用することで運用負荷軽減と高い信頼性を同時に実現することができました。」 今後の展望 ほくつう様と福井県土木部道路保全課様は、今後もAWSのサービスを活用して「みち情報ネットふくい」の機能拡張を計画されています。具体的には、AI を活用した道路状況の自動分析や、より詳細な気象情報との連携など、県民の安全をさらに確保するための取り組みを検討されています。 また、このシステムの成功事例を基に、他の地方自治体への展開も視野に入れており、地域の安全確保に貢献する取り組みを拡大していく予定です。 まとめ 本事例は、AWSのクラウドサービスが地方自治体の公共サービス向上にどのように貢献できるかを示す好例です。特に災害時など、情報が最も必要とされる緊急時にこそ真価を発揮するシステムの構築は、市民の安全を守るという公共サービスの本質的な価値を高めるものと言えるでしょう。 AWSの柔軟なスケーラビリティと高い信頼性を持つサービスは、今後も多くの地方自治体が直面する課題解決に貢献していくことが期待されます。 株式会社ほくつう（右から）：社会インフラ事業本部 事業統括部 部長 山口 博文 様　営業部 社会インフラ営業課 西野 茜 様 営業部 社会インフラ営業課 森 将光 様 Amazon Web Services Japan : アカウントマネージャー 井沼 孝輔（左）

はじめに 株式会社ジャパン・インフォレックス （以下、ジャパン・インフォレックス）は、食品業界のメーカーと卸売り等の取引先の間に立つ企業である。同社は240 万件を超える商品マスターを業界標準に基づき一元管理して提供する業界最大のデータベースセンターを保持している。このデータベースは、8,000 社超のメーカーが直接登録するデータと、大手食品卸が代行登録する共有データの 2 種類のデータで構成されている。ジャパン・インフォレックスは、食品卸売業の商品マスターセンターとして業界の標準化と合理化に貢献し、流通 BMS (流通ビジネスメッセージ標準) に準拠した共通 EDI システムで流通デジタル化の推進を担っている。本ブログではジャパン・インフォレックスが実施した商品マスター刷新事例の概要と、その中でどのように AWS が活用されているかを紹介する。 &nbsp; 背景と新システムのコンセプト 関係会社と共有している現行システムは、稼働開始から 20 年以上が経過しており、これまで度重なる改修を行ってきた結果、その限界が顕在化してきていた。根本となるアーキテクチャ設計は 30 年以上前のものであり外部環境に適合しづらく、複雑化したシステムはブラックボックスになりメンテナンスに多大な労力とコストがかかっていた。食品業界全体で「デジタル化」が進むなかで、環境の変化に柔軟に対応し、安定した事業基盤を構築することが急務であった。従来のレガシーシステムを脱却し「業務効率化」「データ精度の向上」に加え新たなニーズへ対応し、商品マスターの機能・サービスの強化を図るために、現行システムの再構築が必要であった。 新システムへの刷新にあたって、以下の４点を基本コンセプトとして検討した。 持続性のあるシステム基盤に移行 HW・OSの保守終了（EOL）に備え、長期的に安定稼働できる基盤と保守体制を構築する。また多様な利用ユーザーの拡大や、多種な通信プロトコルやネットワークへの対応を見据えたシステム基盤を整備する。 保守性の高いアプリケーションに移行 レガシー開発言語を廃止し、機能改善によるセキュリティ強化をする。 利用ユーザーの利便性向上 関係会社と共有するシステムは機能改修時の障壁となるため、機能配置によるサービス独立性の確保をする。また、個別最適化したシステムではなく標準・共通化したサービスを提供する。 デジタル化に備えて新技術を採用 業務の運用負荷や、マスタ項目拡充に向けたメンテナンス負荷を下げるために、業務生産性向上と拡張性を確保する。 ソリューションの概要 新システムの基本コンセプトを実現するにあたり AWS へのシステム移行を決定した。常務取締役 情報システム部の我妻部長によると「AWS を選定した理由は、①インフラとしての堅牢性が高く、②セキュリティ対策も充実している。GuardDuty、Security Hub などのサービスがある。また、③連携パートナーが多いことも決め手となった」とのことである。 商品マスター管理システムは、IBM AIX 上で稼働しており、Micro Focus COBOL や、KornShell などレガシーなシステムとなっていた。また、対象システムは100万ステップ近くのプログラムとなっており、まずは老朽化したシステムのクラウド化への移行を優先し、その後次期システム構想に向けたモダナイゼーションを実施することとした。AWS 上のシステム構成としては、Amazon EC2（Windows Server 2019）、Amazon RDS for Oracle（Oracle 19c）を中心にしつつ、KornShell から PowerShell への変更、Micro Focus COBOL の新バージョン対応、Oracle 9i からOracle 19c への対応など古い資産の改善も図った。 ・移行元、移行先の環境 プロジェクトは複数のベンダーで構成され、エスカレーションルートを明確にして全ての情報を共有できる仕組みを整えた。また、我妻部長は、「AWS の知見が全くないところからこのプロジェクトが始まっている。AWS のソリューションアーキテクトの支援のおかげで、自分たちだけだと調査に半年かかっていたと思うが、1ヶ月程度で情報の整理ができた」と語っている。 その後、3日間にわたる開発資産や大容量データ・ファイルの移行作業において、課題発生時には迅速に対応し、タイムスケジュール内に完了した。その結果、無停止で切り替えを実現し、業務影響ゼロで本番稼働した。 ITインフラ領域を担った富士通株式会社の関根シニアマネージャーからは、「今回のプロジェクトは複数ベンダーでプロジェクトを進行したことで、技術的な検討や設計方針の調整が必要だった。しかし、AWS はサービスが豊富で、お客様の要件に合わせてカスタマイズしやすく、柔軟に対応することができた。特に Amazon RDSの利用は構築・運用面で大きなメリットがあった。」と語っている。 ・システム構成図 導入効果と今後の展開 AWS 移行プロジェクトは1年半を要したが、確立されたプロセスおよび体制により、最終的にタイムスケジュール通りの完了を実現した。我妻部長は将来の構想として①意思決定のスピードを上げること、②コストを抑えながらシステムを高度化することの2点を重要なポイントとして語っている。今後は、5 年や 10 年に一度の大規模更新などは避け、継続的な小規模アップデートによる運用を重視する。段階的な改善により総コストを抑制する戦略を採用していく方針である。 今後の展開として技術面では、データベースの OSS 化、API Gateway や AWS Lambda などを活用したサーバーレス化も目指しており、運用コストを削減していく方針である。また、S3 などを活用しデータ活用を高度化し、ビジネス面でも付加価値を高められる仕組みも目指している。そのためには、自社でコントロール可能な範囲でシステムを開発・運用・維持管理できる必要があり、組織・人材面での技術力向上と自社開発能力の強化を進めている。すでに AWS 資格取得者の社員も複数名出てきており、今後更なるスキル向上を図っていく予定である。 ジャパン・インフォレックスが持つ商品マスターは、業界の基本情報だけでなく、品質情報や市場データなどを組み合わせ、より付加価値のある情報を提供していくことで、様々なニーズへ対応しながら強化を図っていく方針である。さらに、生成AI を活用していくことで新たなサービス創出の基盤となることも期待されている。 ・ジャパン・インフォレックス様オフィスにて撮影 (ジャパン・インフォレックス様、富士通様、AWS) まとめ 本ブログでは、ジャパン・インフォレックスで実施した商品マスター刷新事例と、その中で AWS がどのように活用されているかを紹介した。AWS を利用することで 30 年間使用したレガシーシステムからの移行を実現し、技術的な課題解決だけでなく、AI 時代に対応した新たな価値創造基盤の構築が可能になった。本ブログがシステム刷新を検討している皆様の参考になりましたら幸いです。 本ブログは、ジャパン・インフォレックス様、メインベンダーである富士通様、 AWS 中村達也が共同で執筆しました。 著者について 中村 達也（Nakamura Tatsuya） SIerやWeb企業で経験を積んだ後、2019年よりAWSのソリューションアーキテクトとして従事。クラウド活用によるシステム移行や新技術でのイノベーション推進に携わる。現在はエンタープライズ企業の支援を担当し、AWSを最大限活用したデジタル化支援を行っている。

本稿は、2025 年 10 月 1 日に公開された Embracing AI-driven operations and observability at re:Invent 2025 を翻訳したものです。 組織がクラウドプレゼンスを拡大し続ける中、効果的な運用が成功の鍵としてますます重要になってきています。AWS re:Invent 2025 のクラウドオペレーショントラックでは、業界の専門家、AWS のリーダー、お客様が一堂に会し、監視とオブザーバビリティのモダナイゼーションに関する知見を共有します。このブログ記事では、運用とオブザーバビリティの主要なテーマについて説明し、クラウド運用戦略の変革に役立つセッションを紹介します。 モニタリングとオブザーバビリティトラックの参加を計画する 5 つの主要テーマにわたる 30 のセッションを提供するオペレーション管理トラックでは、ハンズオンワークショップから専門家レベルのディスカッションまで、すべての方に向けたコンテンツをご用意しています。re:Invent での参加経験を最大限に活用するために、以下をお勧めします。 優先順位を重点に : 組織の直面している運用上の課題に沿ったセッションを選択してください 形式を組み合わせる : 講義形式のセッションと、双方向対話型のワークショップ、ビルダーズセッションを組み合わせてください スキル開発を計画 : 現在のスキルレベルに合ったセッションと、スキルを伸ばすためのセッションを選択してください 早めに予約 : 人気のセッションはすぐに満席になるため、登録開始と同時に予約を入れてください 生成 AI とインテリジェントな運用 クラウドオペレーションの未来は AI が牽引しており、今年のセッションでは画期的な実装例を紹介します。 COP334 | Accelerating incident response through AIOps | Breakout Session 場所: 12 月 2 日 (火) 午後 3:00 – 4:00 PST | Wynn 生成 AI がテレメトリーデータを自動的に分析し、パターンを特定し、アクションにつながる知見を提供し、AI エージェントを活用することで、運用手法をどのように変革しているかを学びます。最新の AI 機能により、複数のシステムにまたがる何時間もの手動トラブルシューティングを、数分で解決できる効率的な調査に変換する方法を学びます。 COP326 | Elevate application and generative AI observability | Breakout Session 場所: 12 月 3 日（水）午後 2:30 ～ 3:30 PST | Wynn このセッションでは、従来のアプリケーションと生成系 AI ワークロードの両方に対して、Amazon CloudWatch の包括的なオブザーバビリティ機能をどのように活用するかをご紹介します。生成系 AI を活用したワークロードを構築するお客様は、エンドユーザーの成果、AI のパフォーマンス、稼働状態、精度、品質の問題を大規模に理解する上で課題に直面しています。 COP335 | Observability for AI Agents and Traditional Workloads | Breakout Session 場所: 12 月 3 日 (水) 午前 8:30 – 9:30 PST | Wynn このセッションでは、AI エージェントの意思決定や行動パターンから、CPU やメモリ使用率などの従来型インフラストラクチャメトリクスまで、アプリケーションスタック全体を Amazon CloudWatch で観測する方法をご紹介します。AI エージェントのパフォーマンスを既存のアプリケーション監視と併せて追跡する実践的なテクニック、AI コンポーネントと従来型サービス間の問題の相関関係、そして Amazon CloudWatch の検索機能を使用して問題を迅速に特定する方法について学びます。CCC Intelligent Solutions による講演です。 COP403 | Automate cloud operations with AI agents | Workshop 場所: 12 月 2 日 (火) 午後 12:30 – 午後 2:30 PST | Wynn この技術ワークショップに参加して、AI エージェントを使用したクラウドオペレーションの自動化ソリューションを構築しましょう。Amazon CloudWatch の調査と Amazon Bedrock Agents を使用して、合理化されたデバッグとインテリジェントな分析を体験するハンズオン学習ができます。 COP405 | Building agentic workflows for augmented observability | Code Talk 場所: 12 月 2 日火曜日 午前 11:30 – 午後 12:30 PST | Wynn このライブのインタラクティブなコーディングセッションでは、生のテレメトリーを実用的な情報に変換する AI エージェントを構築します。Amazon CloudWatch からメトリクス、ログ、トレースを相関分析するシステムを構築します。このエージェントはパターンを分析し、必要な監視設定を作成し、複雑な問題を自然言語で説明します。エージェントを本番環境に展開して運用イベントに自律的に対応し、予防的な観測ワークフローを作成する方法を紹介します。 COP418 | Monitor the quality and accuracy of your generative AI workloads | Code Talk 場所: 12 月 4 日火曜日 午後 2:00 – 3:00 PST | Wynn このライブコーディングセッションに参加して、Amazon CloudWatch が AI の可視性とトラブルシューティングをどのように実現するかを学びましょう。AWS Distro for OpenTelemetry (ADOT) を通じて自動的に計装された、Amazon Bedrock AgentCore と Amazon EKS を Strands Agent SDK で使用する AI エージェントアプリケーションを構築します。CloudWatch の生成系 AI ダッシュボードでエージェントとモデルの監視データを可視化し、レイテンシー、エラー、スロットリング、トークン使用量などの一般的な課題のトラブルシューティングを行う方法を学びます。信頼性の高い AI アプリケーションを構築・維持するための実践的なスキルを身につけて帰りましょう。 オブザーバビリティとパフォーマンスモニタリング モダンアプリケーションでは、スタック全体にわたる包括的なオブザーバビリティが必要です。 COP336 | Elevating application reliability | Breakout Session 場所: 12 月 3 日水曜日 午後 4:00 – 5:00 PST | MGM Amazon CloudWatch、AWS Systems Manager、AWS CloudTrail などの AWS ネイティブサービスを使用して、レジリエントなインフラストラクチャを構築・維持する方法をご紹介します。自動異常検出と予防措置の実装を実演します。迅速なインシデント調査と継続的な運用可視性を実現するための堅牢なロギングアーキテクチャについて説明します。生成型 AI を活用したインシデント分析の高速化と自動応答プレイブックの使用方法を学びます。インフラストラクチャの障害、セキュリティインシデント、性能劣化など、さまざまな課題に対応します。 COP404 | Build full-stack observability from applications to databases | Workshop 場所: 12 月 1 日（月）午後 3:00 ～ 5:00 PST | MGM このハンズオンワークショップでは、Amazon CloudWatch Application Signals と Database Insights を使用して包括的なオブザーバビリティを実装します。アプリケーションを流れるリクエストをトレースし、データベースのパフォーマンスメトリクスと相関付け、ボトルネックを素早く特定する方法を学びます。CloudWatch を使用して、統合ダッシュボード上でアプリケーショントレース、メトリクス、ログを監視し、SQL を使用して Aurora データベースのパフォーマンスを分析する実践的な体験ができます。 COP329 | Application Performance Monitoring: From design to implementation | Chalk Talk 場所: 12 月 1 日（月）午後 4:00 ～ 5:00 PST | Wynn このチョークトークでは、実際の現場におけるアプリケーションパフォーマンスモニタリング (APM) の課題と、Amazon CloudWatch を使用した解決方法について探ります。アーキテクチャ設計を深く掘り下げ、一般的な落とし穴を特定し、分散システムへの深い可視性を得る方法を紹介する、この参加型セッションにぜひご参加ください。 COP367 | Design effective Amazon CloudWatch dashboards and alarms | Chalk Talk 場所: 12 月 3 日（月）午後 3:00 ～ 4:00 PST | Mandalay Bay このチョークトークでは、ワークロードに適切な可視性とアクションを設計するために、Amazon CloudWatch のダッシュボードとアラームの機能について探求します。このセッションでは、SLO、カスタマーエクスペリエンス、インフラストラクチャの観点から、何を監視するかを決定する方法から始めます。Amazon CloudWatch を使用して、インシデント発生時のノイズや認知負荷を軽減し、チームがワークロードにとって重要な事項を素早く特定できるようにする方法を見ていきます。 セキュリティとコンプライアンス セキュリティは引き続き最優先事項であり、統合されたセキュリティオペレーションに焦点を当てたセッションが用意されています。 COP307 | Enhancing security visibility: building scalable log analytics | Chalk Talk 場所: 12 月 3 日（水）午前 9:00 ～ 10:00 PST | MGM このインタラクティブな Chalk Talk では、包括的なログ分析とリアルタイムな脅威検出のためのスケーラブルなソリューションをご紹介します。カスタムセキュリティダッシュボードの作成、自動アラートの実装、コンプライアンス監視ワークフローの確立に関する実践的なテクニックを説明します。 COP417 | Scale security monitoring using AWS CloudTrail with generative AI | Chalk Talk 場所: 12 月 3 日 (水) 午前 10:30 – 午前 11:30 PST | MGM このインタラクティブなチョークトークでは、AWS CloudTrail を使用したエンタープライズ規模のセキュリティ監視の構築について探ります。参加者は、VPC エンドポイントのネットワークイベント、AI を活用した自然言語クエリ、統合されたコンプライアンスダッシュボードを活用する包括的なセキュリティアーキテクチャの設計について議論します。 COP337 | Correlating compliance signals across AWS | Chalk Talk 場所: 12 月 5 日金曜日 午前 11:30 – 午後 12:30 PST | Caesars Forum このインタラクティブな対話形式のセッションでは、Amazon OpenSearch Service の新しいゼロ ETL を使用して、データサイロを排除し、組織全体で包括的なガバナンスの可視性を実現する方法を探ります。データの移動や複製を行うことなく、オンプレミスやマルチクラウド環境を含む Amazon S3 からデータを直接クエリするデータ間の関連性を分析するワークフローの設計について学びます。 オープンソースと現代的な運用 オープンソースツールを活用しているチームの場合: COP333 | Scaling open source observability stack feat. Warner Bros Discovery | Breakout Session 場所: 12 月 1 日（月）午前 11:30 ～午後 12:30 PST | Wynn このセッションでは、Amazon Managed Service for Prometheus、Amazon OpenSearch Service、Amazon Managed Grafana、OpenTelemetry などの AWS マネージド型オープンソースサービスを活用して、これらの課題を効果的に解決する方法をご紹介します。Warner Bros. Discovery が、セキュリティとコスト効率を維持しながら、大規模なテレメトリーデータの取り込みと処理のためのモダンなアーキテクチャパターンを使用して、オープンソースのオブザーバビリティを実装し、インシデント対応を加速させた方法について学びます。 COP412 | Observability: The open source way | Workshop 場所: 12 月 3 日水曜日 午後 3:30 – 午後 5:30 PST | Venetian Prometheus、OpenSearch、Grafana 向けの AWS マネージドサービスを実践的に体験します。サンプルアプリケーションをデプロイし、OpenTelemetry を使用してインストルメンテーションを行い、オブザーバビリティデータの収集、保存、分析、可視化を行います。インフラストラクチャ管理の負担なく、使い慣れたツールを使用して、コスト効率の高いスケーラブルなオブザーバビリティソリューションを構築する実践的な経験を得ることができます。 特集: AWS の舞台裏 COP415 | AWS Behind the Scenes: How AWS drives operational excellence &amp; reliability | Breakout Session 場所: 12 月 1 日（月）午後 1:30 ～ 2:30 PST | Caesars Forum この技術的な深掘りセッションでは、AWS サービスがどのように運用されているかを舞台裏からご紹介します。サービスの計測方法や監視方法について詳しく説明し、日々の運用において Amazon CloudWatch や Amazon OpenSearch の最新機能をどのように活用しているかをご紹介します。実際の運用事例と、サンプルアプリケーションを使用した実践的なデモンストレーションを通じて、AWS チームが信頼性を維持するために活用しているパターンとプラクティスについて学びます。 参加者向けの実践的な推奨事項 高度なトピックに進む前に、COP328「Implementing Observability at Scale」のような基礎的なセッションから始めましょう。 ハンズオンワークショップをお見逃しなく – COP403、COP404、COP408 では貴重な実践的な経験を得ることができます。 AI オペレーションに興味がある方は、COP334、COP335、COP413 のセッションシリーズで包括的な概要を学ぶことができます。 re:Invent 2025 にご参加いただき、AWS が AI、自動化、高度なオブザーバビリティによってクラウドオペレーションをどのように革新しているかをご覧ください。登録は現在受付中です – 今すぐお席を確保してください！ また、Venetian の AWS Village にある Monitoring &amp; observability と AIOps のキオスクにもぜひお立ち寄りください！ まだ登録していませんか？まだ参加に間に合います！ re:Invent ポータルから登録してください。 この記事の翻訳はソリューションアーキテクトの 原 が担当しました。 Jean Velez Torres Jean Velez Torres は、AGS チームの AWS ソリューションアーキテクトです。プエルトリコを拠点としており、ソフトウェア開発、DevOps のベストプラクティス、ERP システムにおいて豊富な経験を持っています。ソフトウェアエンジニアリングの技術的バックグラウンドとクラウドアーキテクチャの専門知識を組み合わせ、組織がデジタルソリューションを構築・改善することを支援しています。