本ブログは、Toyota Motor North America の SAP チーム（Manish Kumar、Anshuman Kowtha、Ashish Patel）との緊密な協力のもと共同執筆されました。 はじめに Toyota Motor North America（以下、トヨタ）は、AWS 上の大規模な SAP ランドスケープで、AI アシスト型の SAP 運用プラットフォーム BasisPilot を運用しています。現在の BasisPilot の対象範囲は、開発・テスト・ステージング・本番の各環境にまたがる 60 台以上の Amazon EC2 ホスト上の 20 の SAP システムで、複数の AWS アカウントとリージョンに及びます。このプラットフォームは、ABAP および Java のアプリケーションスタックや、マルチテナント構成を含む SAP HANA データベースなど、主要な SAP ワークロードタイプをサポートしています。従来、このランドスケープの運用には、エンジニアがターミナル、SAP GUI、スプレッドシート、AWS コンソールの間を行き来する必要がありました。 トヨタの SAP BTP Platform 部門で、BasisPilot は Amazon Bedrock を活用したツール呼び出し型の AI アシスタントを組み込んだ、単一ダッシュボードの運用プラットフォームとして設計・開発されました。SAP 運用から始まったものの、現在では AWS 上でホストされるワークロードの可視性、ヘルス指標、一般的なトラブルシューティング情報を、手動のステータス更新を待たずに必要とする、権限を持つプロダクト・インフラ・サポートの各チームにとっても有用なプラットフォームになっています。本記事では、このプラットフォームの機能、アーキテクチャ、背後にある AWS サービス、そして AI アシスタントがヘルスチェックから SAP カーネルアップグレードの計画・実行支援に至るまで、承認済みの運用ワークフローをどのように支援しているかを説明します。 社内発のイノベーション BasisPilot は商用製品ではありません。トヨタ社内で、SAP BTP Platform と SAP 運用ランドスケープに焦点を当てたエンジニアリングの取り組みとして始まりました。 Manish がこのプラットフォームを構想し、運用モデルを定義し、アーキテクチャ・設計・実装を主導しました。その作業には、共通のエビデンスモデル、サーバーレス API、クロスアカウント制御、非同期ワークフローエンジン、SAP の依存関係ロジック、承認境界、そしてツール呼び出し型の AI レイヤーが含まれます。トヨタの関係者と AWS のメンバーは、レビュー、検証、改良で協力しました。このプラットフォームは、監視、ライフサイクル管理、パッチ適用、HA、DR、バックアップ、コスト、セキュリティといった日々の運用を単一のサーバーレスインターフェースに集約し、承認済みで監査可能なワークフローのための AI アシスト運用レイヤーを備えています。その対象範囲は、SAP 運用ダッシュボードから、権限を持つチーム向けの共通の可視化・トラブルシューティングツールへと拡大しています。 実装を加速するための Kiro の活用 BasisPilot のコンセプト、運用モデル、アーキテクチャを定義した後、Manish は AWS の AI 搭載 IDE である Kiro を開発環境として使い、大規模なコードベースの探索、スキャフォールディングの作成、React と Lambda の境界をまたぐ不具合の追跡、テストや技術ドキュメントの改善といった個別の実装作業を高速化しました。特に、1 つの変更が API コントラクト、DynamoDB でのトラッキング、Systems Manager による実行、ユーザーインターフェースにまたがる場合に役立ちました。 SAP の依存関係シーケンス、承認境界、ロールバック要件、クロスアカウント制御、検証基準は Manish の SAP 運用経験に基づくもので、実際のシステムの挙動と照らし合わせて確認されています。彼は提案をレビューして調整し、BasisPilot の規約に統合し、結果をテストし、最終的な設計と実装の責任を担いました。 本記事の内容について トヨタの公開コンテンツガイドラインに従い、本記事ではアーキテクチャパターン、AWS サービス、設計上の判断のみを説明しています。アカウント ID、社内ホスト名、エンドポイント、認証情報、システム ID、その他の環境固有の情報は含まれていません。 「私は、AI をどこに当てはめられるかを問うところから始めたのではありません。Basis エンジニアがシステムに触れる前に下さなければならない判断、つまり、どのエビデンスを信頼するか、何をどの順序で行うべきか、何があれば作業を止めるべきか、から始めました。BasisPilot は、その判断をプラットフォームの振る舞いとして書き起こすことから生まれたのです。」 – Manish Kumar、Senior SAP Product Owner、Toyota Motor North America ミッションと目標 BasisPilot は、改善（継続的改善）の精神に基づく 5 つの原則に沿って開発されました。 単一ダッシュボード – SAP システム、AWS ホスト、クラスター、バックアップ、パッチサイクルを、どの AWS アカウントやリージョンにあるかにかかわらず、1 つのダッシュボードで可視化します。 安全な自動化 – 変更を伴うすべての操作は、ロールベースのアクセス制御、環境に応じた承認ゲート、完全な監査証跡を経由します。 汎用チャットボットではなく AI アシスト運用 – アシスタントは質問への回答、承認済みバックエンドツールの呼び出し要求、診断結果の要約、制御されたワークフローのガイドを行い、検証・承認・実行・監査の制御はプラットフォーム側が担います。 共有のセルフサービス可視化 – 権限を持つアプリケーション・インフラ・サポートの各チームが、ヘルス、アラート、トラブルシューティング情報を直接確認できるため、SAP BTP Platform チームによる手動更新への依存が減ります。 サーバーレスでコスト効率が高い – プラットフォーム自体にパッチを当てるべきサーバーはありません。バックエンドは Lambda、DynamoDB、およびリクエスト課金のマネージド AWS サービス上で稼働します。 プラットフォームの機能 BasisPilot は Amazon CloudFront から配信される React のシングルページアプリケーションで、バックエンドはすべてサーバーレス API で構成されています。アクセスはロールベースで、承認済みワークフローを操作できるユーザーもいれば、読み取り専用の可視化、インシデントのトリアージ、ステータス確認にプラットフォームを使うユーザーもいます。ダッシュボードは次の機能モジュールを提供します。 図 1 – 実際の画面からキャプチャした BasisPilot のランドスケープダッシュボード。運用値はオリジナルのままで、キャプチャ範囲にはマスキングが必要な SID、ホスト名、アカウント、IP の値は含まれていません。 Dashboard: 権限を持つチーム向けのランドスケープ全体のヘルス。システムの可用性、リソースのホットスポット、重大アラート、SLA 達成状況、クラウドインフラの概要をひと目で確認できます。 Systems: ABAP と Java の両スタックに対応したシステム単位のビュー。コンポーネントのステータス（ASCS/PAS/AAS または SCS/JAS とデータベース）、ライブメトリクス、起動/停止/再起動の操作を提供します。 Host Manager: ホストレベルの CPU/メモリ/ディスク、SAP プロセスのステータス、ファイルシステムの詳細（HANA のデータ/ログボリュームを含む）、ホストの一括操作を提供します。 Backup Status: HANA バックアップカタログ（フル/差分/増分/ログ）の可視化、ログバックアップの連続失敗の検知、RPO 違反アラートを提供します。 OS Patching: 環境ごとの AWS Systems Manager Patch Manager のコンプライアンス、パッチベースラインの承認日の自動化、パッチウィンドウ、そして承認ゲート付きの SAP を考慮した再起動オーケストレーション（SAP 停止 → 再起動 → SAP 起動）を提供します。 Cluster Status: Pacemaker/Corosync の HA クラスターのヘルス、HANA System Replication の状態、ノードのロール、フェイルオーバー履歴、安全なクラスター操作（メンテナンスモード、スタンバイ、制御されたスイッチオーバー）を提供します。 Disaster Recovery: AWS Elastic Disaster Recovery を使った DR テストのオーケストレーション。模擬訓練と実訓練、人による確認ゲートを伴うステップごとの実行、テストごとの完全な監査を提供します。 Threat Monitor: SAP のセキュリティインテリジェンス。SAP Security Audit Log による重要トランザクションの監視、HANA の監査イベント、SIEM へのエクスポート（CEF、Syslog、CSV、JSON）を提供します。 Security: SAP セキュリティベースラインのコンプライアンスを自動化。標準ユーザーのチェック、クライアント設定、プロファイルパラメータ、システムの変更可能性、HANA ユーザーのセキュリティを定期的に収集します。 Activity Log: ランドスケープ全体のすべての起動/停止/アップグレード/パッチ/ストレージ操作について、誰が何をしたかの完全な監査証跡を、実行中の操作のライブ進捗とともに提供します。 Cost &amp; Optimization: マルチアカウントの支出トレンド、EC2 のライトサイジングと新世代インスタンスの推奨、Amazon S3 のライフサイクル分析、Savings Plans のカバレッジ、古いバックアップの削除機会を提供します。 Findings: 継続的なセキュリティ/コストのインスペクター。オープンなセキュリティグループ、古い IAM キー、暗号化されていない Amazon EBS、パブリックな S3、アイドル状態のリソース、バックアップボールトの衛生状態を検出します。 AI Assistant: 表示中のページを認識するアシスタント。SAP 運用に関する質問への回答、承認済みバックエンドツールの呼び出し、長時間実行タスクの追跡、ダウンロード可能なレポートの作成を行います。 コアプラットフォームチームを超えた共有の可視化 設計上の重要な成果の 1 つは、BasisPilot が特定の専門グループに限定されないことです。同じヘルス、インベントリ、トラブルシューティングのビューを、RBAC を通じて AWS 上でホストされるエンタープライズプラットフォームを管理または利用する他の権限を持つチームにも公開できます。読み取り専用ユーザーに対しては、システムが稼働しているか、どのコンポーネントが異常か、メンテナンスウィンドウが有効か、問題がホストリソース・バックアップステータス・プラットフォームの可用性のいずれに関係しているか、といったよくある質問にアシスタントが答えます。運用操作は、承認されたロールと承認ゲート付きのワークフローに限定されたままです。 メリットを受けるのは誰か BasisPilot は企業内のさまざまなロールに、それぞれの責任に応じたアクセスで価値を提供します。プラットフォームから最も大きなメリットを得るのは次のグループです。 SAP Basis およびプラットフォームエンジニア – 承認ゲート付きのワークフローを操作します。起動/停止、OS パッチ適用、カーネルおよび HANA リビジョンのアップグレード、HA クラスター操作、DR 訓練、ストレージ移行などです。 SAP 運用担当者およびオンコール対応者 – アクショントラッカーで長時間の作業を追跡し、記憶から Runbook を組み立て直すことなく、永続化された状態に戻れます。 アプリケーションおよびプロダクトチーム – 依存している SAP ワークロードのシステムヘルス、コンポーネントのステータス、有効なメンテナンスウィンドウを、手動更新を待たずに確認できます。 インフラおよびサポートチーム – 読み取り専用の可視化とアシスタントを使い、アカウントやリージョンをまたいだ一次トリアージを行います。 セキュリティおよびコンプライアンスチーム – SAP Security Audit Log のイベントを監視し、ベースラインコンプライアンスのチェックを実行し、検出結果を全社の SIEM にエクスポートします。 FinOps およびコスト責任者 – マルチアカウントの支出トレンド、ライトサイジングの推奨、Savings Plans のカバレッジ、古いバックアップの削除をレビューします。 監査および変更管理の関係者 – 変更を全社の ITSM や SAP Cloud ALM と結び付ける、完全なアクティビティ証跡とエビデンスパックを活用します。 継続的な監視と SLA トラッキング ダッシュボードの裏側では、スケジュール実行されるコレクター群が、手動ポーリングなしにランドスケープの状態を最新に保っています。 5 分ごとのライブメトリクス – CPU、メモリ、SAP プロセスのステータス、クラスターの状態を、SSM を通じて全ホストから並列に収集します。コレクターは EC2 の状態を認識するため、停止中のインスタンスが古い「グリーン」を表示することはありません。 1 時間ごとのトレンド履歴 – パフォーマンス（CPU/メモリ/ディスク/ロードアベレージ）とファイルシステムごとの使用量を、TTL による 90 日間保持の専用履歴テーブルに書き込み、推定ではなく実データに基づくトレンドチャートを実現しています。 5 分ごとの SLA 測定 – システムごとの可用性サンプルを、環境別の目標値（開発/テストは 99.0%、ステージングは 99.5%、本番は 99.9%）に対する月次の達成率に集計し、専用の SLA ダッシュボードに表示します。 セキュリティおよびコンプライアンスのチェック – SAP Security Audit Log のイベントを 5 分ごと、セキュリティベースラインのコンプライアンスを 30 分ごとに確認します。 重大アラート – コンポーネント停止、バックアップ失敗、リソースのしきい値超過といった状態を、確認（Acknowledge）ワークフローとともにダッシュボードに表示します。 図 2 – SLA ダッシュボード メンテナンスウィンドウ 計画停止は第一級の概念として扱われています。専用のメンテナンス API により、エンジニアは任意のシステムを個別または一括でメンテナンスウィンドウに入れることができ、開始/終了時刻、理由、担当エンジニアが記録されます。ウィンドウが有効な間はそのシステムのアラートが抑制されるため、計画作業で誰かが呼び出されることはなく、作成/更新/削除はすべて監査ログに書き込まれます。AI アシスタントもこれに関与します。現在および今後のウィンドウの一覧表示、会話による新しいウィンドウのスケジュールが可能で、アシスタント自身の長時間ワークフロー（カーネルアップグレード、パッチ適用）もメンテナンス状態を尊重・参照します。 「BasisPilot で最も感銘を受けたのは、Manish の設計と実装の独創性、深さ、完成度でした。彼はこれを既存の SAP 機能の導入や、バラバラなツールの寄せ集めとして扱いませんでした。ユーザーインターフェース、API、データベース、認証と認可、ロールベースのアクセス制御、バックエンドサービス、AI 機能、そしてそれらを責任をもって運用するために必要なガバナンスモデルを含む、エンドツーエンドのエンタープライズプラットフォームを構想し、構築したのです。このプラットフォームは、アーキテクチャを稼働させるために開発された Python、React、JavaScript にまたがる広範で深く統合されたコードベースを持つ、相当なエンジニアリングの成果です。 最も重要なアーキテクチャ上の選択の 1 つは、データおよびインテリジェンスのプレーンと、統制されたコントロールプレーンを明確に分離したことです。この分離により、ID、認可、承認、実行、検証、監査を決定論的かつ統制された状態に保ちながら、インサイトや AI 機能を進化させることができます。Manish は SAP の依存関係モデルから、AWS アーキテクチャ、アプリケーションアーキテクチャ、セキュリティモデル、実装に至るまで設計を主導しました。単に導入方法を提案するのではなく、SAP 運用の深い知見を、実際に動くクラウドネイティブなシステムへと落とし込んだのです。このアプローチの効果はすでに表れ始めており、複雑な SAP ランドスケープへの理解が深まり、より根拠のある意思決定ができるようになり、SAP に依存するビジネス運用の信頼性、レジリエンス、継続性に対する確信も高まっています。」 Anshuman Kowtha、Manager、Toyota Motor North America 難しい問題: SAP の時間は HTTP の時間に収まらない SAP のメンテナンスイベントは、単一のコマンドで完結するものではありません。セントラルサービスを停止する前に、アプリケーションサーバーをドレインする必要があります。共有またはマルチテナントのデータベースは、依存するアプリケーションが稼働している間は停止してはなりません。SAP HANA はフラッシュして検証済みの状態に達するまで時間を要します。起動時は Amazon EC2、AWS Systems Manager、データベース、セントラルサービス、アプリケーションインスタンスの順に待つ必要があります。通常の操作でも 10〜90 分かかり、データベースやアップグレードのワークフローの中には数時間続くものもあります。これらはいずれも同期的な Web リクエストとは相容れません。 そこで BasisPilot は、リクエストの時間と操作の時間を分離しています。アクション API は、長時間の作業を開始する前に永続的なトラッカーを作成します。Amazon DynamoDB には、アクション ID、現在のフェーズ、進捗、完了した結果、承認、エラーが保存されます。ホスト側の作業は AWS Systems Manager Run Command が実行し、ダッシュボードとチャットインターフェースはどちらも同じトラッカーを参照します。Lambda 関数自身の残り時間が少なくなると、状態をチェックポイントして自分自身を非同期に再呼び出しし、ブラウザは単にトラッカーのレコードをポーリングします。同じパターンが、AI エージェントの長時間タスク、OS パッチ適用時の再起動、カーネルアップグレード、マルチテラバイト規模のストレージ移行を支えています。このフェーズベースの自己チェックポイント型の設計は、同期リクエストの時間を超える作業に対して AWS が推奨するパターンであり、これによりトヨタは接続を開いたままにすることなく、数時間に及ぶ SAP 操作を Lambda 上で実行できています。 ブラウザを閉じたり更新したりしても、SAP の停止処理が続くかどうかには影響しません。エンジニアは記憶から Runbook を組み立て直すことなく永続化された状態に戻ることができ、より長いアップグレードでは、監視のチェックポイントにより、変更をやみくもに再実行することなく観測を再開できます。 依存関係ゲートが稼働時間と制御されたダウンタイムの両方を守る シーケンスは画面に表示されるだけでなく、コードで強制されます。停止時、BasisPilot はアプリケーションインスタンスを停止し、停止したことを検証してから、セントラルサービス、データベース、そして要求された場合は Amazon EC2 を停止します。データベースの停止を検証できない場合、インフラの停止はブロックされます。起動時はこの順序が逆になり、EC2 と Systems Manager の準備完了、データベースのヘルス、セントラルサービス、アプリケーションインスタンスの順に進みます。並列作業は安全なレイヤー内では許可されますが、順序を守るべき依存関係をまたいで行われることはありません。 BasisPilot は「コマンドが受け付けられた」ことを中間状態として扱います。成功とするには意図した結果のライブ検証が必要であり、これにより、データベース、エンキューサービス、アプリケーションプロセスがまだ完了していないのに、ランドスケープが利用可能であると報告してしまうことを防いでいます。 ダッシュボードからアシスタントまで共通のエビデンスモデル ランドスケープダッシュボード、Systems ビュー、Host Manager、Backup Status、アクショントラッカー、AI アシスタントは、同じ運用エビデンスを異なる視点で見せるものです。システムカードはコンポーネントのロールとワークプロセスのヘルスを示します。ホストビューは CPU、メモリ、ディスク、ファイルシステム、上位プロセスを追加します。Backup Status は、フル、差分、増分、ログの各バックアップ履歴に加え、欠落、失敗、古い状態、継続性の状況を追加します。 そのため、「このシステムはメンテナンスしても安全か？」といった質問に対して、アシスタントはシステムの状態、ホストの負荷、バックアップによる保護状況、クラスターの状況、メンテナンスウィンドウ、最近のアクション履歴をまとめることができます。その後に承認済みのアクションが続く場合は、決定論的なワークフローのコードがシーケンス、認可、実行、検証、監査を制御します。生成されたテキストがシェルコマンドになることは決してありません。 ガードレールはアシスタントが「しないこと」も定義する BasisPilot は、漠然とした質問をランドスケープ全体を調べる許可とはみなしません。たとえばバックアップステータスは、意図的に単一の SAP システムに範囲を限定しています。これは、バックアップやリカバリポイントの情報を返す前に、プラットフォームが正しい HANA データベースのホストとカタログを特定する必要があるためです。ユーザーが「バックアップステータス」とだけ尋ねた場合、アシスタントはどの SAP システムを確認するかを尋ねます。無関係なシステムを統合したり、直近の文脈から対象を推測したりはしません。 この境界は、モデルやツールが実行される前に強制されます。ユーザーがシステム ID を指定すると、リクエストは読み取り専用のバックアップツールにルーティングされます。同じ原則がすべての機能に適用されます。アシスタントは型付けされ範囲が限定されたツールへのインターフェースであり、あらゆるものを調べたり変更したりする包括的な権限ではありません。 図 3a・3b: 実際の BasisPilot チャットボットのやり取り。漠然としたバックアップステータスの要求はスコープ境界で止められ、アシスタントはバックアップデータを照会する前に SAP SID を 1 つ指定するよう求めています。マスキングしているのは例示の SID の値のみで、リクエスト、レスポンス、タイムスタンプ、画面は改変していません。 アーキテクチャ BasisPilot はハブアンドスポーク型の設計を採用しています。中央のハブアカウントがプラットフォーム（フロントエンド、API、AI エージェント、すべての DynamoDB の状態）をホストします。スポークアカウント（ステージング、本番、DR）には実際の SAP ワークロードが含まれます。ハブからスポークへのアクセスは、厳密に範囲を限定したクロスアカウントロールへの STS AssumeRole のみを介して行われ、ホストレベルの作業はすべて AWS Systems Manager Run Command を経由します。プラットフォームが管理する操作では SSH キーもインバウンドアクセスの開放も不要です。AWS STS と AWS Systems Manager を用いたこのハブアンドスポークモデルは、クロスアカウント運用に対して AWS が推奨するアプローチに沿ったものであり、トヨタは常設の認証情報やインバウンドのネットワークアクセスなしに、すべてのスポークアカウントにアクセスできています。 以下の図では、ハブアンドスポークの全体像から、サーバーレス、AI、監視、アクションの各レイヤーへと、同じアーキテクチャを段階的に詳しく示します。続くデータフローのセクションでは、これらのコンポーネントが実行時にどのように連携するかを説明します。 図 4 – BasisPilot のリファレンスアーキテクチャ: 認証済みユーザーはサーバーレスのハブプラットフォームにアクセスし、Bedrock の AI エージェントと API Lambda は STS と AWS Systems Manager のみを通じてスポークアカウントの SAP システムに作用します。 図 5 – コンポーネントの詳細ビュー: ハブ内のサーバーレスプラットフォームの各レイヤーと、STS AssumeRole と SSM のみを通じてアクセスされるスポークアカウント内の SAP ワークロード。 データフロー プラットフォームのレイヤー構成を踏まえると、実行時の流れは次のように追うことができます。 検出（Discovery）。フィーダー Lambda がリソースタグを使って SAP の EC2 インスタンスを検出し（1 つのデータベースが複数の SAP システムに対応するマルチテナント HANA のマッピングも含む）、DynamoDB 内のホスト/システムのインベントリを作成します。 収集（Collection）。EventBridge がコレクター Lambda をトリガーします（ライブメトリクス、クラスターの状態、SLA サンプル、セキュリティイベントは 5 分ごと、パフォーマンスとファイルシステムのトレンドは 1 時間ごと、HANA バックアップカタログは 1 日 3 回）。コレクターは SSM を通じてホスト上で読み取り専用コマンドを並列に実行し、CPU、メモリ、ファイルシステム、SAP プロセス、バックアップ、セキュリティ、SLA のデータを DynamoDB に書き込みます。コレクターは EC2 の状態を認識しており、停止中のインスタンスではキャッシュされたプロセス数を積極的にゼロにするため、ダッシュボードが古い「グリーン」を表示することはありません。 提供（Serving）。API Lambda が DynamoDB から読み取り、保護されたルートには Cognito の JWT オーソライザーを設定した API Gateway を通じて React フロントエンドにデータを提供します。EC2 の状態が常に最初に確認され、停止中のインスタンスはキャッシュされたプロセスデータよりも優先されます。 アクション（Action）。変更を伴う操作（起動/停止、パッチ適用、アップグレード、ストレージ変更）は、フェーズベースのワークフローとして実行されます。各 API 呼び出しはゲートウェイのタイムアウトより十分短く完了し、進捗は DynamoDB で追跡され、UI はトラッカーをポーリングし、停滞したフェーズは回数制限付きの冪等なリトライで自己修復します。 設計上の教訓: すべてをフェーズベースに SAP の操作は通常 10〜90 分かかり、API Gateway や Lambda の制限をはるかに超えます。BasisPilot は長時間の操作をすべて小さなフェーズに分割し、状態を DynamoDB にチェックポイントします。Lambda は自身の残り時間が少なくなると自分自身を非同期に再呼び出しし、ブラウザ（またはチャット UI）は単にトラッカーのレコードをポーリングします。同じパターンが、AI エージェントの長時間タスク、OS パッチ適用時の再起動、カーネルアップグレード、マルチテラバイト規模のストレージ移行を支えています。 使用している AWS サービス サービス BasisPilot での使い方 Amazon Bedrock AI アシスタントの推論レイヤー。BasisPilot はツール使用（tool use）を伴う Converse API を利用し、モデルが構造化されたバックエンドツールを要求できるようにしています。アプリケーションはそれらのツールを検証・認可したうえで実行します。単純なステータスの質問は低レイテンシーの Claude モデルが処理し、診断、根本原因分析、レポートの統合には、より推論能力の高いモデルを使い分けています。 AWS Lambda バックエンド全体。API、スケジュール実行のコレクター、AI チャットハンドラー、非同期ワークフローワーカー、SAP Cloud ALM / ITSM 連携ワーカーを含む 40 以上の関数で構成されています。Python 3.x で、モジュール化された共有コードレイヤーを使用しています。 Amazon DynamoDB 40 以上のリクエスト課金テーブルにまたがるプラットフォームのすべての状態。システム/ホストのインベントリ、アクショントラッカー、AI タスクと承認、セッションと OTP、セキュリティイベント、ベースラインコンプライアンス、SLA 履歴、バックアップジョブ、メンテナンスウィンドウ、クラスター情報、コストキャッシュ、アップグレードジョブ、DR テスト、検出結果を保存し、一時的なデータには TTL による有効期限を設定しています。 AWS Systems Manager プラットフォームが管理するホストへの唯一の経路。Run Command は許可リストに登録されたコマンド（sapcontrol、HDB ツール、読み取り専用の hdbsql、df、crm など）を実行し、Patch Manager は OS パッチのコンプライアンスとベースラインを管理します。SSM for SAP は、該当する場合に SAP アプリケーションの可視化や構成チェックに使用します。 Amazon API Gateway Lambda バックエンドの前段に置く HTTP API。200 以上のルートを持ち、そのうち 160 以上を Cognito の JWT オーソライザーで保護し、CORS はマネージドで設定しています。 Amazon Cognito パスワードとメール OTP によるサインイン方式でのユーザー認証を行い、API オーソライザーが使用する JWT トークンを発行します。ロールのクレームがフロントエンドのルートガードとバックエンドの RBAC を制御します。 Amazon CloudFront + Amazon S3 React シングルページアプリケーションのグローバル配信と、デプロイ時のキャッシュ無効化を行います。 Amazon EventBridge すべてのスケジューリング。ライブメトリクス、クラスターの状態、SLA サンプル、SAP セキュリティ監査イベントの 5 分ごとの収集、パフォーマンス・ファイルシステム・クラウドメトリクスのトレンドの 1 時間ごとの収集、30 分ごとのセキュリティベースラインコンプライアンスのチェック、1 日 3 回の HANA バックアップカタログの収集、夜間のクリーンアップジョブ、さらにリリースワークフロー連携のためのイベントルーティングを担います。 AWS Security Token Service (AWS STS) 各スポークアカウント内の範囲を限定したロールへの、短期間（15 分のセッション）のクロスアカウント認証情報。プラットフォームが管理する操作において、ハブとスポークを結ぶ唯一の橋渡しです。 AWS Elastic Disaster Recovery 重要な SAP システムの継続的なレプリケーションと、人による承認ゲートを伴う切り替えステップを含む DR 訓練のオーケストレーションを行います。 AWS Backup / Amazon EBS リスクの高い変更前の AMI 取得、サイズ変更前のスナップショットによる安全確保、ストライプ化したマルチボリュームの HANA レイアウト、リカバリポイントの衛生状態のレポートに使用します。 AWS CloudTrail セキュリティ監査ツールのデータソース。不正アクセスの検知、権限昇格の監視、構成変更の追跡、通常と異なる API アクティビティの検出に使用します。 Amazon CloudWatch Lambda のログ（チャットエージェントからクロスアカウントで検索可能）、メトリクス、S3 の休眠分析に使用するストレージサイズの時系列データを提供します。 AWS Cost Explorer / AWS Compute Optimizer ライトサイジング、リザベーション、Savings Plans の推奨を、ファンアウト型のコレクターで 1 つのランク付けされた削減リストに集約します。 Amazon SES OTP の配信、承認通知、実行されたアクションの監査証跡メールを送信します。 AI アシスタント: 制約されているからこそ役に立つ AI アシスタントは、権限を持つエンジニア、プロダクトオーナー、サポートチームを支援するために設計されており、運用上の責任を置き換えるものではありません。Amazon Bedrock のツール使用を利用し、モデルはプラットフォームの 68 個の型付きツールのいずれかを要求できますが、アプリケーションがその要求を検証し、RBAC を確認し、承認ポリシーを適用したうえで、安全な場合にのみツールを実行します。この分離が重要です。モデルはタスクを推論する手助けはできますが、認可、検証、実行、監査の責任はプラットフォームが負い続けます。 ツールのカテゴリ カテゴリ 代表的な機能 監視とステータス システムの一覧、コンポーネントのヘルスを含むシステム/ホストの詳細、上位プロセス、ファイルシステムの使用量、バッチのステータス、パフォーマンストレンド、SLA の概要、メンテナンスウィンドウ、ランドスケープの朝のヘルスチェック。 診断と RCA インベントリの情報、ホスト横断の並列ライブ SSM チェック、支援付きの根本原因分析を組み合わせた調査パイプライン。症状に応じた診断、SAP・HANA・OS・クラスターのログレビュー、HANA の容量分析。 ライフサイクル操作 SAP とデータベースのレイヤーを正しい順序で起動/停止、EC2 の制御、承認ゲート付きの SAP カーネルアップグレードワークフロー、hdblcm を使った HANA リビジョンのアップグレード、再起動オーケストレーションを伴う SAP を考慮した OS パッチ適用、メンテナンスのスケジューリング。 HANA の高度な操作 原因となったユーザーの特定を含むテーブル肥大化の RCA、デルタマージのステータス確認/強制実行、ガベージコレクションの滞留、DDL 生成と事前バックアップを伴うテーブルパーティショニング、テナント管理、トレース検索、レプリケーション（HSR）のセットアップ/ステータス/テイクオーバー。 ストレージ（LVM）ワークフロー 論理ボリュームの作成/拡張/縮小をフェーズ化したワークフローとして実行: AMI による安全バックアップ → SAP のグレースフル停止 → 並列データコピー（非常に大きな HANA データファイル向けのマルチプロセスのバイト範囲コピー）→ 旧ボリュームを即時ロールバック経路として保持したボリュームの入れ替え → 検証 → 起動。 クラスターと HA 1 回の呼び出しで全ノードにまたがるクラスター調査、制御されたフェイルオーバー/スイッチバック、制約のクリーンアップ、ログに十分なエビデンスがある場合は原因の特定を伴うフェイルオーバー履歴。 コストとセキュリティ コストの概要、EC2 のライトサイジング、休眠検知を伴う単一バケットの詳細な S3 監査、CloudTrail によるセキュリティ監査、SAP ベースラインコンプライアンスの照会、セキュリティイベントの検索。 レポート 自己完結型のダウンロード可能な HTML ヘルスレポート（システムごと（ライブの SSM データ）またはランドスケープ全体）。 リクエストがエージェント内をどのように流れるか インテントルーティング。 モデルがリクエストを受け取る前に、軽量なルーティングで利用可能なツールを最も関連性の高い候補に絞り込みます。これによりプロンプトの範囲が狭まり、誤ったツール選択が減ります。「はい」や「進めて」のような単純な確認は直前の保留中のアクションに紐付けられ、信頼度の高い入力（たとえば、エージェントが求めた後に指定されたカーネルメディアのパス）では、追加のモデル呼び出しの代わりに決定論的なファストパスを使用できます。 RBAC ゲート。 呼び出し元のロールは JWT のクレームから取得され、ツールに必要な権限と照合されます。閲覧者ロールは読み取り専用のままで、オペレーターおよび管理者ロールは制御されたアクションを要求できます。 承認ゲート。 環境に応じたポリシーにより、本番環境のアクション、マルチテナントのデータベースホスト、破壊的な操作は、実行されずに必ず保留中の承認が作成されます。ユーザーは何が実行されるかを正確に確認できます。カーネルアップグレードのような複雑なワークフローでは、ライブの事前チェックレポート（現行バージョンと目標バージョン、実行中のプロセス、メディアの検証）が、選択可能な確認/キャンセルボタンとともに表形式で提示された後にのみ承認が求められます。古い承認は自動的に失効します。 入力の検証。 システム ID はパターンで検証され、SSM コマンドは許可リストに登録された操作から組み立てられ、安全でないシェルのメタ文字は拒否されます。アシスタントが自由形式のシェルを受け取って実行することはありません。 実行と検証。 長時間の操作は、チャット内にライブの進捗カードを表示する非同期タスクとして実行されます。ワークフローはキャッシュされた状態を信頼するのではなく、ライブのプロセスチェックで結果を検証し、リスクの高いワークフローには、起動の検証に失敗した場合にバックアップしたカーネルを復元するといったロールバック経路が含まれています。 監査。 すべてのツール呼び出し、承認、結果は、ユーザー ID とともにアクションログに記録されます。これは Activity Log ページが表示するものと同じ証跡です。 ケーススタディ: AI アシスト型の SAP カーネルアップグレードワークフロー 代表的なワークフローの 1 つが、意図した運用モデルをよく示しています。エンジニアが主導権を保ち、アシスタントがチェックと承認済みの実行ステップを調整します。 エンジニアが、あるシステムのカーネルアップグレードを依頼します。アシスタントは、カーネルメディアの場所（ホストのパスまたは S3 のロケーション）を尋ねます。 エンジニアがパスを指定すると、決定論的なファストパスにより非同期の事前チェックが開始されます。現在のカーネルレベル、目標メディアの検証、パッチレベル混在の警告、各ホストで実行中のインスタンス、ディスク容量のチェックです。 アシスタントは、続行/キャンセルボタンとともに計画を表形式で提示します。この時点では何も変更されていません。 承認後、ワークフローはホストごとに実行されます: メディアのステージングと展開 → 現行カーネルのバックアップ → システムのインスタンスを想定どおりの順序で停止 → デプロイ → セントラルサービスから起動 → プロセスのヘルスとカーネルレベルを検証。起動の検証に失敗した場合、ワークフローはシステムを部分的にアップグレードされた状態のまま放置せず、バックアップを復元します。 旧パッチレベルから新パッチレベルへの変化やバックアップの場所を含む最終結果が、チャットに投稿され監査ログに記録されます。パイロット利用期間中、エンジニアの役割は手動の Runbook を実行することから、承認済みワークフローを監督することへと変わりました。2026 年 5 月に実施した 15 件以上のパイロットのカーネルアップグレードの観察に基づくと、システムあたりの推定所要時間は約 2.5 時間から 45 分に短縮され、約 70% 削減されました。エンジニアの実作業工数は個別には測定していません。 得られた教訓: AI ワークフローは他の自動化と共存しなければなりません。初期の社内テスト中、AI アシストによるアップグレードが成功してシステムが再起動した数分後に、停滞していたダッシュボードの停止トラッカーの自己修復リトライが発動し、競合する停止アクションが生じました。修正は表面的なものではなく体系的なものでした。システムごとのワークフローロック、リトライと承認の鮮度ウィンドウ、アクション後の再検証ウィンドウです。複数の自動化が同じランドスケープを共有する場合、リトライは状況が変わっていないと決して仮定してはならず、アクションの前に状態を再確認しなければなりません。 モデル戦略 階層化されたモデル: 単純なステータスの質問は低レイテンシーでコスト効率の高い Claude の階層に、調査、マルチステップのワークフロー、レポートの統合はより推論能力の高い階層に振り分けます。階層はセッション単位ではなくリクエスト単位で選択されます。 ツールループの上限設定: 1 リクエストあたりのツール使用ターンを最大 7 回に制限し、最終ターンでは強制的に回答をまとめることで、レイテンシーとコストを予測可能に保ちます。 結果のキャッシュ: 読み取り専用ツールの結果はツールごとの TTL でキャッシュされ、「refresh」と言えばキャッシュを回避できます。破壊的な操作や確認済みのアクションでは、キャッシュは決して使用されません。 組み込みのナレッジベース: SAP Basis の Runbook（起動/停止のシーケンス、OOM 分析、スプリットブレインからの復旧、EBS の拡張手順）を Lambda にパッケージ化し、アシスタントがワークフローを推奨または開始する前に低レイテンシーで検索できるようにしています。 セキュリティとガバナンス ID。保護された API ルートでは JWT 検証を伴う Amazon Cognito を使用し、ユーザー ID は常にトークンのクレームから取得し、リクエストボディからは取得しません。 最小権限。スポークアカウントのロールは、プラットフォームが必要とする SSM と読み取りの権限のみを公開し、セッションは短期間です。 ホストを公開しない。プラットフォームが管理する操作では SSH はゼロで、すべてのホストとのやり取りは許可リストのコマンドセットを使った監査可能な SSM Run Command です。 変更管理。本番環境のアクションは常に人が承認します。エビデンスパックとリリースワークフロー連携により、変更を全社の ITSM および SAP Cloud ALM のプロセスに結び付けます。 監査とコンプライアンス。プラットフォームが管理するリソースは全社のタグ付け標準に従い、監査ログはコンプライアンスのトレーサビリティを支え、セキュリティモジュールはイベントを標準形式で全社の SIEM にエクスポートします。 リカバリ。リスクの高いワークフローでは、プラットフォームが対象の状態を変更する前に、安全確保のためのエビデンス（AMI、カーネルのバックアップ、スナップショット）を取得し、ロールバックの選択肢を確保します。 これらの制御を組み合わせることで、AWS のセキュリティのベストプラクティス、最小権限のスポークロール、短期間の STS セッション、Amazon Cognito によるトークンベースの ID が適用され、AI とデータのレイヤーが進化しても、トヨタは ID、認可、監査を決定論的に保つことができています。 「BasisPilot は、断片化したツールと手動の Runbook による SAP 運用を、インテリジェントで統制された 1 つの運用プラットフォームへと変革します。リアルタイムの可視化、AI アシストによる診断、制御された自動化を、エンタープライズ環境が求める承認、検証、監査可能性、ロールバックと組み合わせています。Manish のリーダーシップにより、SAP 運用の深い専門知識が、企業全体に拡張できる能力へと変わりました。」 Ashish Patel、Senior Manager、Toyota Motor North America 成果 アーキテクチャ、運用上のガードレール、人によるレビューのモデルを組み合わせることで、次のような実践的な成果が得られました。 1 つのプラットフォーム: BasisPilot は、SAP アプリケーション、データベース、AWS インフラの情報を、環境やアカウントをまたいで 1 つのインターフェースに集約することで、ターミナル、コンソール、スプレッドシートの間を行き来する必要を減らします。チームは、運用情報の収集と分析に費やす時間が少なくとも 20% 削減されたと見積もっています。これは、画面の切り替えが減ったことと、アシスタントがシステムのエビデンスをまとめ、エンジニアによる結果の解釈を助けることの両方を反映しています。このプラットフォームは、基盤となる SAP や AWS のサービスを置き換えるのではなく、これらのワークフローを統合するものです。 セルフサービスの拡大: 権限を持つチームはシステムのヘルス、アラート、トラブルシューティング情報を直接確認できるため、ステータス確認のために Basis チームに頼る必要が減ります。チームの報告によると、セルフサービスの可視化を導入した後、ステータス関連のチケットが推定 25% 減少しました。この数値はシステムステータスに関する問い合わせに適用されるもので、インシデントの総数やインシデントの解決時間を示すものではありません。 手作業の削減: BasisPilot は、日々のヘルスチェック、SAP プロセスとホスト負荷の分析、バックアップの確認、レポート作成から、ランドスケープの協調的な起動/停止、パッチ適用、アップグレード、ストレージ変更に至るまで、SAP 運用サイクル全体の作業を支援します。エンジニアはダッシュボードと範囲を限定した AI ツールを使って、エビデンスの収集、問題の調査、サポート対象のアクションの調整を行います。プラットフォームは、これらのワークフロー内で依存関係のシーケンス、必要な承認、進捗の追跡、検証、監査記録を処理します。コスト最適化、セキュリティとコンプライアンスのチェック、高可用性と災害対策のビューも、日常的な運用レビューに必要な情報を提供します。 パイロットでの見積もりは、この幅広い対象範囲のうち 2 つの部分を示しています。2026 年 5 月の 15 件以上のカーネルアップグレードの経験に基づくと、エンジニア 1 人・システム 1 つあたりの実作業工数は約 2.5 時間から 45 分に減少し、実作業工数が約 70% 削減されました。また別途、2026 年 3 月の 30 件以上のファイルシステム縮小の観察では、推定所要時間は以前の 3〜4 時間に対して約 1 時間となり、所要時間が約 67〜75% 短縮されました。 より安全な運用: サポート対象の操作は、ロールベースの権限、環境に応じた承認ポリシー、監査ログ、結果のライブ検証に従います。リスクの高いワークフローにはバックアップとリカバリのステップが含まれます。たとえばカーネルアップグレードのワークフローでは、起動の検証に失敗した場合に以前のカーネルを復元できます。これらの制御は、すべての変更が自動的に元に戻せると仮定するのではなく、実装されている箇所で明確なリカバリ経路を提供します。 サーバーレスの運用モデル: BasisPilot のプラットフォームレイヤーは、管理やパッチ適用が必要な専用のアプリケーションサーバーを持たず、マネージドな AWS サービス上で稼働します。コレクターと API は需要に応じてスケールします。2026 年 9 月 25 日時点で、チームの AWS インベントリレビューでは、プライマリのハブリージョンで BasisPilot に関連する 47 個の AWS Lambda 関数と 53 個の Amazon DynamoDB テーブルが確認されました。これらの数にはパイロットおよびレガシーのコンポーネントも含まれます。 まとめ BasisPilot は、SAP プラットフォームの専門知識を、サーバーレスの AWS サービスと、厳格な認可・監査の制御を中心に構築された AI アシスタンスと組み合わせることで何が可能になるかを示しています。そのアーキテクチャパターン（STS と SSM によるハブアンドスポーク、フェーズベースの長時間ワークフロー、RBAC と承認ゲートの背後でのツール呼び出し、検証ファーストの自動化）は、AWS 上で大規模かつ規制の厳しいワークロードを運用する企業が応用できるものです。 はじめてみましょう BasisPilot の背後にあるパターンは、お客様自身の SAP やエンタープライズの運用プラットフォームに導入できるマネージドな AWS サービスに基づいています。次のリソースは良い出発点になります。 Amazon Bedrock – バックエンドツールへの統制されたアクセスを備えた、ツール呼び出し型の AI アシスタントを構築できます。 Amazon Bedrock のドキュメント を参照してください。 AWS Systems Manager – SSH を使わずに、EC2 ホスト上でエージェントレスかつ監査可能なコマンドを実行 できます。 AWS Lambda と Amazon DynamoDB – 永続的な状態追跡を伴う、フェーズベースの自己チェックポイント型ワークフローを実装 できます。 AWS STS によるクロスアカウントアクセス – 短期間で範囲を厳密に限定したロールを通じて、スポークアカウントのワークロードにアクセス できます。 SAP on AWS – AWS 上で SAP ワークロードを実行する ためのリファレンスアーキテクチャと運用ガイダンスです。 これを組織で実践するには、まず運用上の判断、つまり依存関係、承認ゲート、検証ステップをプラットフォームの振る舞いとして書き起こし、そのうえで、統制されたワークフローへの範囲を限定したインターフェースとして AI アシスタントを追加することから始めてください。 著者: Manish Kumar は、Toyota Motor North America（トヨタ）の SAP BTP Platform チームの Senior SAP Product Owner です。SAP のソリューションアーキテクチャ、クラウド移行、システムアップグレード、エンタープライズのモダナイゼーションにわたる経験を持ちます。BasisPilot を構想し、その設計・アーキテクチャ・実装を主導し、SAP の専門知識と、AWS 上での AI アシストによる分析および統制された運用を結び付けました。プロダクトオーナーシップと実践的なエンジニアリングを組み合わせ、信頼性、セキュリティ、人による監督を重視しています。プラットフォームが作業を準備し、すべての変更はエンジニアが承認するという考え方です。SAP BTP ソリューションアーキテクチャ、TOGAF 9、AI ガバナンス（IAPP AIGP）の認定を保有し、IEEE Senior Member および IAPP Fellow of Information Privacy (FIP) でもあります。 Anshuman Kowtha は Toyota Motor North America の Technical Manager で、同社の SAP および AWS クラウド環境全体のプラットフォーム戦略とデリバリーを率いています。エンタープライズテクノロジーで 23 年、エンタープライズ規模の SAP ランドスケープの統括で 15 年以上の経験を持ち、オンプレミスのインフラからハイパースケールクラウドへ、レガシー SAP から S/4HANA へといった大きなプラットフォームの転換を導き、移行・変革・継続的なモダナイゼーションの期間を通じてミッションクリティカルなシステムを構築・拡張してきました。実践的な技術基盤、徹底した運用の厳格さ、ガバナンスとセキュリティへの強いこだわりをもって、企業がクラウドと ID のプラットフォームを大規模に導入できるよう支援しています。 Ashish Patel は Toyota Motor North America の SAP Technology 担当 Senior Manager で、トヨタでの 7 年以上を含む 24 年の SAP プラットフォームの経験を持ちます。SAP および ERP プラットフォーム、クラウドインフラ、システム統合を専門とし、テクノロジー戦略をビジネスの優先事項と整合させることに注力しています。プラットフォームの信頼性向上、運用効率の改善、デジタルトランスフォーメーションの支援に向けた取り組みを率いています。そのリーダーシップは、協働、継続的改善、そして複雑な技術課題を実践的なビジネスソリューションに変えるチームの育成を重視しています。複数の SAP Technology Associate および Specialist 認定に加え、AWS Certified Solutions Architect – Associate を保有しています。 Neill Reidy は AWS の Principal Technical Account Manager で、企業がレジリエントで運用上優れたクラウド環境を構築できるよう支援しています。Linux とネットワークで 29 年の経験を持ちます。AWS re:Invent で登壇し、複数の AWS Professional 認定を保有し、AWS Systems Manager、Amazon Connect、AWS Unified Operations、災害対策に関する AWS ブログ記事やお客様事例を執筆しています。 Vijay Sitaram は AWS の Principal Technical Account Manager です。データベースと SAP テクノロジーを中心に IT 分野で 26 年の経験を持ち、自動車・製造業のお客様の AWS 上の SAP ワークロードのサポートリーダーを務めています。レジリエンス、コスト、運用の卓越性に重点を置き、お客様が SAP ワークロードを運用・拡張できるよう支援しています。AWS for SAP のブログ記事を複数執筆し、バックアップ、レジリエンス、および SAP 運用向けの MCP を用いた AI 主導の kiro-cli に関する AWS ワークショップを作成しました。AIOPS for SAP MCP Server のオーナーであり、AWS re:Invent の登壇者でもあります。AWS Solutions Architect Professional と GenAI Professional の認定を保有しています。余暇には CrossFit、ウェイトリフティング、マウンテンバイク、原野でのバックパッキングを楽しんでいます。 © Toyota Motor North America. 本ドキュメントは、知見共有を目的として社内ツールのアーキテクチャを説明するものです。環境固有の識別子は、トヨタの公開コンテンツガイドラインに従いすべて省略しています。AWS のサービス名は Amazon.com, Inc. またはその関連会社の商標です。SAP および SAP HANA は SAP SE の商標です。 <!-- '"` --> 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

2026 年 11 月 5 日 : 11 月の全日程（6 回）を掲載しました。11 月 6 日の回は満席のため、同じ内容の回を 11 月 27 日 に追加しました。 2026 年 10 月 30 日 : 11 月 11 日の回を掲載しました。 2026 年 10 月 29 日 : 初版を公開しました。 AWS Japan では、2026 年 11 月から、AWS のセキュリティサービスを実際に操作するオンラインハンズオンを週次で開催します。各回は座学とハンズオンの 2 部構成で、AWS Security Agent (now part of AWS Continuum)、AWS WAF、Amazon Inspector などを題材に、ご自身の組織で試すための最初の一歩までをお伝えします。業界を問わず、ユーザー企業・団体の方を対象としています。 本記事はその案内ページです。2026 年 11 月の開催日程（6 回）がすべて決まりました。12 月以降の日程も決まり次第この記事に追記していきますので、ブックマークしてご活用ください。 これまでの取り組み AWS Japan パブリックセクター技術統括本部では、2026 年 4 月から、座学とハンズオンを組み合わせたセキュリティワークショップを月 1 回開催してきました。6 月からはフロンティア AI 時代の脅威対策をテーマにしており、7 月には本シリーズで使う AWS Security Agent のハンズオンも実施しています（開催報告: ランサムウェア対策（脅威検知・統合セキュリティ管理） ／ Claude Mythos 時代の脅威対策（脆弱性管理・AI エージェントによるセキュリティ評価） ／ 耐障害性ライフサイクル ／ AI 時代の Web アプリケーション防御 ）。 10 月には「 ［臨時開催］FY2026 AWS セキュリティセミナー ― フロンティア AI 時代のサイバー攻撃に備える ― 」を開催し、多くの方にご参加いただきました。10 月 30 日にも、同じ内容で 第 2 回 を開催しました。 これらのセミナーでお伝えしたのは「いま何をすべきか」です。次の一歩は、実際に手を動かして、自組織のアプリケーションで試せる状態になることです。 なぜ月 1 回から週次に広げるのか AI の活用が進み、脆弱性を見つけて直す取り組みを、これまでより早く進められるようになっています。本シリーズは、その取り組みを実際に体験していただく場です。 10 月の臨時セミナーには想定を大きく上回るお申し込みをいただき、あわせて案内した 11 月の対面ハンズオンも、募集開始後すぐに満席となりました。そこで開催の頻度を増やし、より多くのお客様に手を動かして試していただけるよう、ハンズオンをオンラインで毎週繰り返し、日程の合う回にご参加いただける形にしました。 どんなことを体験できるか 各回とも、座学とハンズオンの 2 部構成です。座学で考え方を整理したうえで、ハンズオンでは AWS のセキュリティサービスを実際に操作していただきます。ハンズオンで使う環境は AWS 側で用意します。 現在、次のようなテーマを予定しています。各回のテーマは開催日程の表をご覧ください。 AWS Security Agent (now part of AWS Continuum) : AI エージェントによるアプリケーションのセキュリティレビューとペネトレーションテスト AWS WAF : 公開 Web アプリケーションの入り口での防御 Amazon Inspector : OS やミドルウェアの脆弱性管理 Claude/GPT などのフロンティアモデルを活用したソースコードの脆弱性対策 : フロンティアモデルを使ってソースコードの脆弱性を見つけ、対策する方法 AI エージェントと進めるマイグレーション・モダナイゼーション : サポートが終了したランタイムやフレームワークで動くアプリケーションを、AI エージェントと一緒に新しい環境へ移行する方法 テーマは、お寄せいただくご要望に応じて追加・変更します。各回の詳しい内容は、決まり次第この記事と申込ページでお知らせします。 対象となる方 ソフトウェア開発者、DevSecOps エンジニア、セキュリティエンジニアの方 公開 Web アプリケーションや API を開発・運用している組織の方 前提知識: 最新のブラウザが使えること 本ハンズオンは、ご自身のシステムをお持ちのユーザー企業・団体の方を対象としています。パートナー企業の方は、担当の AWS パートナー部門へご相談ください。 開催日程 同じテーマを複数回開催します。ご都合の合う回にお申し込みください。いずれもオンライン開催です。日程が決まり次第、この表に行を追加します。終了した回は一覧から下げていきます。 日時 テーマ 申込 2026 年 11 月 6 日（金）14:30 – 17:30 AWS Security Agent (now part of AWS Continuum) ハンズオン ※ 満席のため、同じ内容の回を 11 月 27 日 に追加しました 満席 2026 年 11 月 11 日（水）15:00 – 17:00 Claude/GPT などのフロンティアモデルを活用したソースコードの脆弱性対策 ハンズオン 申込ページ 2026 年 11 月 18 日（水）14:30 – 17:30 AI エージェントと進めるマイグレーション・モダナイゼーション ハンズオン 申込ページ 2026 年 11 月 20 日（金）14:30 – 17:30 AWS WAF ハンズオン 申込ページ 2026 年 11 月 25 日（水）14:30 – 17:30 Amazon Inspector ハンズオン 申込ページ 2026 年 11 月 27 日（金）14:30 – 17:30 AWS Security Agent (now part of AWS Continuum) ハンズオン （11 月 6 日の回と同じ内容） 申込ページ 2026 年 12 月（日程調整中） AWS WAF AWS Security Agent Amazon Inspector Claude/GPT などのフロンティアモデルを活用したソースコードの脆弱性対策 準備中 お申し込みについて 申込ページからお申し込みいただくと、参加用の URL がメールで届きます 申込には AWS のイベントサイト（Connected Community）への会員登録（無料）が必要です。勤務先のメールアドレスでご登録ください 定員を超えた場合はキャンセル待ちとなります。枠が空くと自動的に繰り上がり、確認メールが届きます 各回の定員は、当日のサポート体制に合わせて設定しています ハンズオンの先にあるもの このハンズオンのゴールは、体験した内容を ご自身の組織のシステムで実際に試せる状態 になることです。 そのために、各回の最後には、ご自身の環境で始めるときの最初の一歩をご案内します。たとえば、どのシステムから始めるか、まず何を有効にして何を確認するか、といった点です。ハンズオン後に具体的なご相談がある場合は、担当の AWS アカウントチームまでお問い合わせください。 著者 梅田 昌太 (Shota Umeda) アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 シニアソリューションアーキテクト パブリックセクターのお客様の技術支援を担当。2026 年 4 月から、本記事で紹介したセキュリティワークショップシリーズと 10 月の臨時セミナーの企画・運営に携わっています。

本記事は 2026 年 10 月 26 日 に公開された「 Embracing Observability for the AI era at re:Invent 2026 」を翻訳したものです。 クラウドの利用規模が拡大し、AI エージェントを本番環境に導入する組織が増えるなか、運用の質がこれまで以上にビジネスの成否を左右するようになっています。AWS re:Invent 2026 の Cloud Operations トラックでは、業界のエキスパート、AWS のリーダー、そしてお客様が集まり、アプリケーションとそれに並行して稼働する AI エージェントのモニタリングとオブザーバビリティをどうモダナイズしているかを共有します。 本記事では、Monitoring and Observability のラインナップの主要テーマを紹介し、クラウド運用戦略の変革に役立つセッションを取り上げます。全体を貫くテーマは、 Amazon CloudWatch における AI を活用した調査です。 Monitoring and Observability トラックの参加計画を立てる Monitoring and Observability のラインナップは 6 つの主要テーマにまたがる 25 のセッションで構成され、ハンズオンのワークショップからエキスパート向けのディスカッションまで、幅広い内容を用意しています。re:Invent を最大限に活用するために、次の点をおすすめします。 優先事項に集中する: 組織が直面している運用課題に沿ったセッションを選びましょう。 形式を組み合わせる: 講義形式のセッションと、インタラクティブなワークショップやビルダーズセッションを組み合わせましょう。 スキルアップを計画する: 現在のスキルレベルに合ったセッションと、一歩先に挑戦できるセッションの両方を選びましょう。 早めに予約する: 人気のセッションはすぐに満席になるため、予約受付が始まったらすぐに席を確保しましょう。 本番環境の AI エージェントを観測する これからのクラウド運用は AI が主導します。以下のセッションでは、推論し、ツールを呼び出し、自律的に行動するエージェントを観測する方法を紹介します。 COP304 | Observability and operations in the AI era | ブレイクアウトセッション 日時・会場: 12 月 1 日 (火) 4:00 PM–5:00 PM PST | Wynn/Encore · Level 1 · Encore Ballroom 5 生成 AI は従来のモニタリングが前提としていた考え方を崩しました。非決定的なシステムに対して予測可能で説明可能、かつ手頃なコストに保つことに多くのチームが苦労しています。本セッションではまずこの課題を取り上げ、続いて最新のオブザーバビリティ機能を使い、トレース、スパン、信頼度スコアリングによって AI スタック全体のモデル品質、コスト、エージェントの動作を可視化する方法を、実際のお客様のパターンを交えて紹介します。 対象者: 生成 AI ワークロードを運用し、モデル品質、コスト、エージェントの動作を可視化する必要がある SRE やプラットフォームチーム COP309 | I didn’t know my AI agent was doing that! | ビルダーズセッション 日時・会場: 11 月 30 日 (月) 1:30 PM PST | Wynn/Encore · Convention Promenade · Latour 7 AI エージェントは非決定的です。前触れなくトークンを浪費したり、処理が止まったり、誤った動作に逸れたりすることがあり、多くのチームは問題が起きるまで状況を把握できません。このハンズオンのビルダーズセッションでは、Amazon CloudWatch を使い、コンソールと IDE の両方から稼働中のエージェントを観測します。エージェントが実際に何をしたかをトレースし、障害を見つけ、異常な動作を検出します。本番用エージェントとカスタムチャットボットという実際のエージェントを使って検出とアラートを自分で構築し、本番環境で運用しているエージェントに適用できるスキルを身につけます。 対象者: 本番環境でエージェントを運用しており、コンソールと IDE からのトレースや異常検出をハンズオンで学びたいエンジニア COP318 | Catch it before production: Instrument your AI agents | ワークショップ 日時・会場: 11 月 30 日 (月) 12:00 PM–2:00 PM PST | Wynn/Encore · Level 1 · Brahms 4 AI ワークロードの可視化は、障害が起きてからではなく本番環境に到達する前に必要です。しかし、多くのチームはエージェントのテレメトリをまったく取得していません。このワークショップでは、稼働中の AI エージェントをエンドツーエンドで計装し、トークンコスト、レイテンシー、ツール呼び出し、推論トレースを取得します。計装の方針を自分で決め、ダッシュボードと異常アラートを構築します。自社のエージェント型ワークロードに適用できる、実際に動作する環境を持ち帰れます。 対象者: 初めて AI エージェントを本番環境に導入し、リリース前に計装する必要があるチーム COP319 | Observe AI agents beyond your perimeter | ビルダーズセッション 日時・会場: 12 月 1 日 (火) 1:00 PM PST | Caesars Forum · Level 1 · Forum 120 · Content Hub · Builders’ Session 2 開発者は AI コーディングエージェントでトークンを消費していますが、その状況はまったく見えていません。Claude Code や OpenAI Codex は組織の境界の外にあるノート PC 上で動作し、テレメトリがオブザーバビリティバックエンドに届きません。本セッションではこの問題を解決します。ネイティブの OpenTelemetry エクスポートと、単一のベアラートークンで利用できる Amazon CloudWatch の OTLP エンドポイントを使い、コレクターもサイドカーも認証情報の設定も不要で、メトリクス (トークン使用量、コスト、生産性)、ログ (ツールの判断、エラー)、トレース (エージェントの推論チェーン) を開発者のマシンから直接送信します。さらに、チームごとのコスト配分と異常アラートを備えたライブダッシュボードを構築し、すべてを PromQL でクエリできるようにします。数分でデプロイできる状態で会場を後にできます。 対象者: 境界の外で動作する AI コーディングエージェントのテレメトリを必要とするプラットフォームチームやセキュリティチーム COP325 | Observability patterns for agentic AI in production | チョークトーク 日時・会場: 11 月 30 日 (月) 1:00 PM–2:00 PM PST | Wynn/Encore · Convention Promenade · Latour 5 AI エージェントは非決定的で、複数のステップを踏み、自律的に判断を下すため、従来の APM だけでは不十分です。推論チェーンのトレース、トークンコストの配分、ガードレールのモニタリング、マルチエージェントの連携といった、エージェント型ワークロード向けのオブザーバビリティパターンを探ります。ホワイトボードを使ってその場でアーキテクチャを描きます。本番環境のエージェントモニタリングに関する難しい疑問を持ち寄り、すぐに実践できるパターンを持ち帰ってください。 対象者: エージェント型ワークロードのオブザーバビリティを設計しており、実績のあるパターンを求めるアーキテクトや SRE COP337 | Wrong, Not Broken, &amp; Why your Observability should know the difference | ブレイクアウトセッション 日時・会場: 12 月 2 日 (水) 12:00 PM–1:00 PM PST | Wynn/Encore · Upper Convention Promenade · Cristal 2 · Content Hub · Purple Theater エージェント型アプリケーションには、従来のアプリケーションとは異なるアクセスパターンとツールが必要です。「エージェントはビジネスが求めることを実行しているか」という基本的な問いに答えるだけでも、複数のツールをつなぎ合わせ、人間がオーケストレーターの役割を担っているチームは少なくありません。エージェントがあるクラウドで動作し、別のクラウドのモデルや API を呼び出す場合、状況はさらに難しくなります。本セッションでは、CloudWatch Omni によって複数のクラウドにまたがる AI エージェントとアプリケーションを 1 つのビューにまとめ、原因がパフォーマンス、可用性、応答品質のいずれであっても根本原因の特定を迅速化する方法を紹介します。 対象者: 複数のクラウドにまたがってエージェントやアプリケーションを運用し、根本原因分析のための統合ビューを必要とするチーム COP349 | Build a per-tenant observability stack for Agentic SaaS | ビルダーズセッション 日時・会場: 11 月 30 日 (月) 4:30 PM PST | Wynn/Encore · Convention Promenade · Latour 7 マルチテナントの ISV には、従来のダッシュボードでは実現できないテナントごとのオブザーバビリティが必要です。集計されたメトリクスでは問題を起こしているテナントが埋もれてしまい、共有のトレースからはどのテナントのエージェントが異常な動作をしたのかがわかりません。本セッションでは、エージェント向けにテナントごとのオブザーバビリティスタックを構築します。テナントを識別できるトレースとセッションリプレイでエージェントの呼び出しを計装し、ノイジーネイバーやレイテンシーの外れ値を把握できるテナント単位のダッシュボードを構築し、集計シグナルではなくテナントごとのしきい値で発火するアラートを設定します。セッションの最後には、別途データパイプラインを用意しなくてもテナント数に応じてスケールするオブザーバビリティ環境と、エージェントアーキテクチャの拡大に合わせて拡張するためのパターンが手に入ります。 対象者: エージェントの動作をテナントごとに可視化する必要がある ISV やマルチテナント SaaS の開発者 COP401 | Building eval-driven observability for AI agents | コードトーク 日時・会場: 11 月 30 日 (月) 4:30 PM–5:30 PM PST | Caesars Forum · Level 1 · Forum 120 · Content Hub · Code Talk マルチエージェントシステムは、ダッシュボードには現れない形で失敗します。あるエージェントが誤ったコンテキストを引き渡し、別のエージェントがリトライし、それでも API は 200 を返します。このライブコーディングセッションでは、LangGraph、Strands、CrewAI で構築したマルチエージェントアプリケーションから始め、OpenTelemetry と OpenInference で計装します。最初のプロトタイプ実行からトレースし、LLM-as-judge 評価器でエージェントをオンデマンドで評価し、本番環境に昇格する前にプロンプトやモデルのバリエーションを A/B テストします。さらに、本番環境のトレースをバージョン管理されたデータセットに取り込み、障害をローカルで再現して修正をリリースします。ここまでの作業をすべて、ツールを切り替えずに IDE で完結させます。 対象者: マルチエージェントシステムを構築しており、評価駆動のオブザーバビリティをワークフローに取り入れたい開発者 COP407 | Build-time context for faster agentic incident response | コードトーク 日時・会場: 12 月 3 日 (木) 10:30 AM–11:30 AM PST | Wynn/Encore · Convention Promenade · Margaux 1 AI エージェントは本番環境の問題を修正できますが、それには適切なコンテキストが欠かせません。このトークでは、AI エージェントが機能を構築し、同じプルリクエストの中で、オンコール対応に必要なコンテキスト (計装、アラーム、ダッシュボード、スキル) をすべてコードとして作成します。その後、稼働中のアプリケーションを意図的に壊します。エージェントが作成済みのスキルを Amazon CloudWatch Omni や AWS DevOps Agent と組み合わせて使い、トリアージを行い、根本原因を特定して修正をリリースする様子をご覧ください。自ら構築したものを運用するためのコンテキストをエージェントに与えるパターンを持ち帰れます。 対象者: ビルド時に作成したコンテキストを使い、構築したものを AI エージェントに運用させたいチーム INV521 | Teaching Telemetry to Think: From Raw Signals to Root Cause | チョークトーク 日時・会場: 12 月 2 日 (水) 1:00 PM–2:00 PM PST | Wynn/Encore · Convention Promenade · Latour 5 インシデントを調査する AI エージェントは、何の前提知識もない状態から始まります。何が正常かも、トポロジーも、因果関係の履歴もわからず、毎回生のドキュメントからコンテキストを組み立て直します。テレメトリ自体があらかじめ自らの意味を理解していたらどうでしょうか。本セッションでは、エージェント型オブザーバビリティのためのインテリジェンスレイヤーを検討します。ストリーミング検出器とライブのサービスグラフが数十億のシグナルをインシデントの観測結果に凝縮し、オープンウェイトの LLM をベースにファインチューニングした推論モデルがそれらを相関付けて、順位付けされた根本原因を導き出します。モデルに学習させるべきことと推論時に取得すべきことの切り分け、ドメインに特化したファインチューニングがフロンティアモデルの規模に勝る理由、推論モデルがまだ失敗するポイントといった難しい論点について、ホワイトボードを使って一緒に議論しましょう。 対象者: 推論モデルがテレメトリを順位付けされた根本原因に変える仕組みに関心のあるアーキテクトや研究者 AI 時代のオブザーバビリティ戦略を構築する AI によって運用チームの働き方が変わるなかで、オブザーバビリティの方向性を定めます。 COP335 | Evolve your observability for the agentic era | ブレイクアウトセッション 日時・会場: 12 月 1 日 (火) 11:30 AM–12:30 PM PST | Wynn/Encore · Upper Convention Promenade · Cristal 2 · Content Hub · Blue Theater 先週はすべてのテストに合格したエージェントが、今日は同じプロンプトに対して異なる、しかもコストの高い回答を返し、誰もその理由を説明できません。エージェントは裏側のモデルやプロンプトが変わるにつれて挙動がずれていきますが、ダッシュボードが正常を示していてもそのずれは検出できません。本セッションでは、評価 (eval) とは何かを解説します。評価とは、エージェントの出力を品質、正確性、コストの観点からスコアリングする自動チェックです。評価駆動のループによって、ライブトラフィック上でずれを検出し、原因となった変更までトレースし、モデルやプロンプトを比較し、コストをエージェントやユーザー単位まで配分し、リグレッションを本番環境に到達する前に防ぐ方法を学びます。さらに、Amazon CloudWatch Omni が評価駆動のループを AWS と他のクラウドにまたがって実現し、エージェントとアプリケーションを 1 か所でカバーする様子をご覧いただきます。 対象者: 大規模なトラブルシューティングのためにログ、メトリクス、トレースを統合する運用チーム COP340 | Best practices for building an observability strategy in the age of AI | チョークトーク 日時・会場: 12 月 3 日 (木) 8:30 AM–9:30 AM PST | Caesars Forum · Level 1 · Academy 409 多くのオブザーバビリティ戦略は AI 以前の世界を前提に作られており、もはや十分ではありません。データ基盤は引き続き重要ですが、そのデータの使い方は急速に変わりつつあります。このチョークトークでは、AI がオブザーバビリティを変えていくなかで、変わらないもの、進化すべきもの、新たに生まれるものを探ります。静的なダッシュボードから動的な体験へ、事後対応型のアラームから AI 主導のインサイトへの移行、そして「エージェントがどの程度うまく機能しているか」のように新たに答えるべき問いを取り上げます。AWS が AI 主導のオブザーバビリティに取り組むなかで得た学びを共有しますので、ぜひご参加ください。 対象者: AI 時代に向けてオブザーバビリティ戦略を見直しているリーダーやアーキテクト OpenTelemetry で標準化する オープンスタンダードは AWS におけるオブザーバビリティの基盤です。以下のセッションでは、オープンスタンダードを実際に活用します。 COP306 | Cut through Kubernetes signal overload with unified observability | ビルダーズセッション 日時・会場: 12 月 2 日 (水) 10:00 AM PST | Caesars Forum · Level 1 · Forum 120 · Content Hub · Builders’ Session 2 大規模な Kubernetes 環境では、高カーディナリティのシグナルが大量に発生します。従来のパイプラインではそれらが切り捨てられたり別々のバックエンドに分散されたりするため、必要な答えが 1 か所にそろうことはありません。このハンズオンのビルダーズセッションでは、EKS クラスターから OpenTelemetry のメトリクスとログを Amazon CloudWatch に送信し、Container Insights をデプロイして、本当に重要なシグナルを見極めます。自動リソースエンリッチメントを使って独自のダッシュボードとアラートを構築し、用意されたスクリプトをなぞるのではなく、何を、なぜアラート対象にするかを自分で判断します。高カーディナリティのノイズを解消し、行動につながるアラートを設定する方法を身につけられます。 対象者: EKS の高カーディナリティなシグナルに悩まされている Kubernetes チームやプラットフォームチーム COP308 | Turn raw telemetry into answers with OpenTelemetry | ビルダーズセッション 日時・会場: 12 月 2 日 (水) 11:30 AM PST | Wynn/Encore · Upper Convention Promenade · Cristal 2 · Content Hub · Builders’ Session 1 生のテレメトリはノイズが多く、ラベルもなく、クエリしにくいため、チームは行動を起こす前にデータのクリーニングに時間を取られています。このハンズオンのビルダーズセッションでは、稼働中のサンプルアプリケーションからメトリクス、ログ、トレースを取得するよう OpenTelemetry を設定し、Amazon CloudWatch のパイプラインプロセッサーを使って転送中のデータをエンリッチ・正規化します。エンリッチメントルールを自分で構築し、自然言語クエリで結果を確認して、生のシグナルを分析可能なテレメトリに変える再利用可能なパターンを持ち帰ります。 対象者: 計装を標準化しており、転送中のテレメトリをエンリッチしたいエンジニア COP336 | Elevate your observability with OpenTelemetry on AWS feat. Genesys | ブレイクアウトセッション 日時・会場: 12 月 2 日 (水) 2:30 PM–3:30 PM PST | Wynn/Encore · Upper Convention Promenade · Cristal 2 · Content Hub · White Theater スタック全体を可視化するために、バラバラのツールや独自形式をつなぎ合わせる必要はありません。AWS で OpenTelemetry に標準化すれば、コンテナ、Kubernetes クラスター、AI ワークロードなどにまたがるメトリクス、ログ、トレースから、統合された豊富なテレメトリを得られます。Amazon CloudWatch のネイティブ OpenTelemetry により、OTLP による取り込み、PromQL によるクエリ、自動エンリッチメントを使って詳細なテレメトリを収集できます。データの断片化もベンダーロックインもありません。単一のテレメトリ基盤で、環境全体で何が起きているかを把握するためのコンテキストが得られます。より豊富なデータ、統合されたオブザーバビリティ、そして成長に合わせてスケールする本番対応のアーキテクチャを実現する方法を学びます。 対象者: コンテナ、Kubernetes、AI ワークロード全体で OpenTelemetry への標準化を進めているチーム COP343 | Instrument a service with OpenTelemetry | ライトニングトーク 日時・会場: 12 月 2 日 (水) 2:30 PM–2:50 PM PST | Wynn/Encore · Upper Convention Promenade · Cristal 2 · Content Hub · Lightning Theater このライブデモでは、OpenTelemetry と Amazon CloudWatch を使い、オブザーバビリティがまったくない未計装のサービスを、相関付けられたメトリクス、ログ、トレースを備えた状態へ数分で移行させます。SDK の設定、コレクターのセットアップ、シグナルのルーティング、そして最初の実用的なインサイトの提示まで、本番品質の計装に至る最短ルートをたどります。 対象者: OpenTelemetry を初めて使い、サービスを計装する最短ルートを知りたいエンジニア ログをインテリジェンスに変える ログを保存するだけでなく、すべてのアカウントとリージョンにわたってログを活用する段階へと進みます。 COP310 | Automate threat detection and response across your logs | ビルダーズセッション 日時・会場: 11 月 30 日 (月) 1:30 PM PST | Wynn/Encore · Upper Convention Promenade · Cristal 2 · Content Hub · Builders’ Session 2 セキュリティチームは重要な 1 件のイベントを探すためにすべてのログを手作業で調べることはできず、脅威はアナリストのクエリよりも速く進行します。このハンズオンのビルダーズセッションでは、セキュリティテレメトリに対する自動検出と対応の仕組みを構築します。不審なアクティビティを検知するメトリクスフィルターと異常検出器、適切な担当者を呼び出すアラームへ検出結果をルーティング、そしてアナリストがログインする前に動作する自動修復を組み合わせます。誤検知を減らすよう検出をチューニングしたうえで、チームの代わりにログを監視するパイプラインを持ち帰れます。 対象者: ログデータに対する検出と対応を自動化するセキュリティチームや運用チーム COP339 | Follow that log from pipeline to intelligence | チョークトーク 日時・会場: 12 月 3 日 (木) 1:00 PM–2:00 PM PST | Wynn/Encore · Convention Promenade · Montrachet 1 あらゆる場所からログが流れ込んでいても、問題が複数のアカウントやリージョンにまたがると、コンソールを行き来しながら何が起きたのかをつなぎ合わせることになります。このチョークトークでは、ログが取り込みパイプラインから統合データレイヤー、そしてログ分析へと至るエンドツーエンドの経路をホワイトボードで描きます。可視性のギャップがどこで、なぜ生じるのかを分析し、これらのレイヤーをつなげて、コンテキストを失わずに環境全体で問題をトレースする方法を学びます。 対象者: アカウントやリージョンをまたいで問題をトレースしており、ログの可視性のギャップを解消したいチーム フルスタックでパフォーマンスをトレースする アプリケーションの動作が遅くなったとき、以下のセッションで、あらゆるレイヤーにわたって原因を突き止める方法を学べます。 COP322 | Where’s the slowdown? Build observability from frontend to databases | ワークショップ 日時・会場: 11 月 30 日 (月) 12:00 PM–2:00 PM PST | MGM Grand · Level 1 · Grand 120 アプリケーションが遅くなったとき、原因はフロントエンドからデータベースまでのどこにでも潜んでいる可能性があり、ツールがサイロ化していると推測に頼るしかありません。このワークショップでは、アプリケーション、インフラストラクチャ、データベースの各レイヤーにわたるフルスタックのオブザーバビリティを構築します。RDS と Aurora のシグナルやデータベースログを 1 つのストアに集約し、監査アクティビティと相関付けます。何をトレースするかを自分で決め、症状と根本原因を結び付けるダッシュボードを構築します。あらゆる遅延を 1 つの画面でレイヤーをまたいでトレースするスキルを身につけられます。 対象者: アプリケーション層とデータ層にまたがる遅延を診断するフルスタックチームやデータベースチーム COP338 | High latency! Is it the code, the container, or the host? | チョークトーク 日時・会場: 11 月 30 日 (月) 10:00 AM–11:00 AM PST | MGM Grand · Level 3 · Premier 311 アプリケーションが遅いとき、原因はコードでしょうか、コンテナでしょうか、それとも基盤となるホストでしょうか。スタックがクラウド、ハイブリッド、オンプレミスにまたがっている場合、アプリケーションのパフォーマンスとインフラストラクチャの健全性を相関付けるには、ツールを行き来しながら根本原因を推測することになります。本セッションでは、トレース、エラー、レイテンシーといったアプリケーションのシグナルを、実行場所を問わずインフラストラクチャに直接マッピングする方法を紹介します。ダッシュボードを手作業でつなぎ合わせることなく、問題がアプリケーションにあるのか、アプリケーションを実行しているコンピューティング基盤にあるのかを特定する方法をご覧いただけます。 対象者: クラウド、ハイブリッド、オンプレミスにまたがってアプリケーションのパフォーマンスとインフラストラクチャを相関付ける SRE COP342 | Optimize container observability to reduce cost | チョークトーク 日時・会場: 11 月 30 日 (月) 4:30 PM–5:30 PM PST | MGM Grand · Level 1 · Boulevard 165 大規模なコンテナ環境では、メトリクスとログが大量に生成され、エンジニアリングチームにとってコストとノイズの両方が増大します。本セッションでは、OpenTelemetry を使ってコンテナ化されたワークロード全体のオブザーバビリティデータを管理するアーキテクチャ戦略を探ります。メトリクスのカーディナリティを制御する方法、重要なシグナルを維持するサンプリングポリシーの設計方法、マネージドバックエンドのトレードオフを評価する方法を学びます。コストを意識したコンテナのオブザーバビリティを構築するためのフレームワークを持ち帰れます。 対象者: 大規模環境でオブザーバビリティのコストを制御する必要があるコンテナプラットフォームチーム COP408 | Correlate database query latency to user impact | コードトーク 日時・会場: 12 月 4 日 (金) 9:00 AM–10:00 AM PST | Wynn/Encore · Convention Promenade · Margaux 1 分散アプリケーション全体のパフォーマンス低下を診断するには、データベースやアプリケーションのメトリクスを個別に見るだけでは足りず、相関付けられたエンドツーエンドのテレメトリが必要です。このコードトークでは、OpenTelemetry と Amazon CloudWatch を使い、データベースのパフォーマンスシグナルとアプリケーション層のテレメトリを統合するシナリオをデモします。トレースとクエリの相関付けを実装する方法、根本原因分析を迅速化するログ集約パターンの設計方法、スタック全体のボトルネックを浮かび上がらせるメトリクスの関連付けの構築方法を学びます。遅いデータベースクエリを、その下流にあるユーザーへの影響と結び付けられるようになります。 対象者: クエリレイテンシーとユーザーへの影響を結び付けたいデータベースチームやアプリケーションチーム COP409 | Pinpoint latency in microservices with distributed tracing | コードトーク 日時・会場: 11 月 30 日 (月) 1:30 PM–2:30 PM PST | Wynn/Encore · Convention Promenade · Margaux 1 Pod が動的にスケールし、トレースコンテキストがサービスの境界を越えて伝播しない大規模な Amazon EKS 環境では、レイテンシーの診断が複雑になります。このコードトークでは、コンテナ化されたマイクロサービスを OpenTelemetry で計装し、サービス間のホップでコンテキストを伝播させ、Amazon CloudWatch でスパン、メトリクス、ログを相関付けます。ライブコーディングを通じて、対象を絞ったスパン属性とエグザンプラーを使って Kubernetes 規模のトレースをたどれるようにし、1 つの遅いリクエストから性能低下の原因となったコンテナとコードパスを正確に特定する方法を示します。また、本番規模での負荷、忠実度、コストに影響するサンプリング戦略とコレクターのデプロイトポロジーのトレードオフも紹介します。 対象者: EKS 上で分散トレーシングを使ってレイテンシーを特定したいマイクロサービスチーム オープンソースのオブザーバビリティをマネージドな規模で運用する チームが頼りにしているオープンソースツールはそのままに、バックエンドの運用は AWS に任せられます。 COP307 | Keep your open source observability, move to managed scale | ビルダーズセッション 日時・会場: 12 月 2 日 (水) 9:00 AM PST | Wynn/Encore · Upper Convention Promenade · Cristal 2 · Content Hub · Builders’ Session 2 Prometheus、Grafana、OpenSearch に標準化しているチームが、スケーラビリティを確保し運用負荷を減らすためにツールを手放す必要はありません。このハンズオンのビルダーズセッションでは、OpenTelemetry による計装と収集について学び、そのテレメトリをマネージドなオープンソースサービスで活用します。メトリクスは Amazon Managed Service for Prometheus に送信して PromQL でクエリし、ログとトレースは Amazon OpenSearch Service に送信し、すべてのシグナルを Amazon Managed Grafana で相関付けます。オープンスタンダードと AWS のマネージドサービスで、テレメトリパイプラインをエンドツーエンドで自ら管理できます。 対象者: Prometheus、Grafana、OpenSearch を利用しており、ツールを変えずにマネージドな規模を実現したいチーム COP410 | Build a fully managed open source observability stack on AWS | コードトーク 日時・会場: 12 月 4 日 (金) 8:30 AM–9:30 AM PST | Wynn/Encore · Upper Convention Promenade · Cristal 2 · Content Hub · Code Talk オープンスタンダードを使いたいけれど、バックエンドを自分で管理する運用負担は避けたい。このコードトークでは、オープンソースのオブザーバビリティアーキテクチャ一式をライブコーディングします。OpenTelemetry でサービスを計装 (自動と手動) し、OTel Collector のパイプラインを設定して、メトリクスを Amazon Managed Service for Prometheus に、ログとトレースを Amazon OpenSearch Service にルーティングします。SDK の選定からコレクターのトポロジーまで、統合に関する各判断を順にたどり、インフラストラクチャを管理する必要がなく、すべてオープンソースの標準で構築された本番対応のスタックを、動作する状態で持ち帰れます。 対象者: AWS でフルマネージドのオープンソースオブザーバビリティスタックを構築するチーム まとめ re:Invent 2026 の Monitoring and Observability のラインナップは、AI エージェントの観測、OpenTelemetry による標準化、ログのインテリジェンス化、フルスタックでのパフォーマンストレース、マネージドな規模でのオープンソース運用まで幅広くカバーしています。テーマを確認して早めに席を予約し、最も解決したいオブザーバビリティの課題をぜひコメントでお聞かせください。ラスベガスでお会いしましょう。 まだ登録していない方も、今からでも参加できます。 re:Invent ポータル から登録してください。