本記事は 2026 年 9 月 1 日に公開された “ Intelligent alarm management for power and utilities using Amazon Bedrock AgentCore ” を翻訳したものです。 発電および送配電 (T&D) のオペレーターは、分散型制御システム (DCS)、SCADA、プロセスヒストリアン、設備保全管理システム (CMMS)、保護リレーなど、共通のインターフェイスを持たない複数の運用システムを扱っています。発電所の制御室や電力会社の運用センターでは、これらのシステム全体で 1 日に数千件のアラームを受け取ります。系統事故などの発生時には数分のうちに数十件のアラームが発生することがありますが、その大半は独立した障害ではなく、連鎖して発生する二次的なアラームです。根本原因を特定するには、3〜4 つのアプリケーションに個別にクエリを実行する必要があり、通常 25〜40 分かかります。 ISA-18.2、IEC 62682、EEMUA Publication 191 などの業界規格はアラーム管理のベストプラクティスを定めていますが、規格と現場の運用との隔たりは依然として大きいのが実情です。従来のアラーム管理ツールはルールベースで、個々のシステムの中で完結しています。そのため、プロセスヒストリアンのセンサーのトレンドを、CMMS 上の期限を過ぎた予防保全タスク、ドキュメント管理システムにある OEM の技術情報、チケットシステムにある過去の類似インシデントと関連付けることはできません。 本記事では、北米の大手電力会社が現在、 Amazon Bedrock AgentCore 上で運用しているマルチエージェント AI アーキテクチャを紹介します。このアーキテクチャにより、オペレーターがシフトごとに何十回も、複数のシステムをまたいで手作業で行っていた調査が不要になり、アラームのトリアージにかかる時間が数時間から数分に短縮されています。業界の課題、マルチエージェントの設計、ご自身の環境にデプロイできる GitHub 上のリファレンス実装について、順を追って説明します。 アラーム管理の課題 ISA-18.2 規格 (プロセス産業向けアラームシステムの管理) と EEMUA Publication 191 は、優れたアラーム管理のあり方を定義しています。規格と現実の隔たりは大きく、次の表のとおりです。 指標 ISA-18.2 / EEMUA 191 の目標値 アラーム管理を行っていない一般的な現場 オペレーター 1 人あたりのアラーム件数 1 時間あたり 6 件未満 1 時間あたり 40〜200 件以上 不要アラーム (ニューサンスアラーム) の割合 10% 未満 60〜80% アラームの大量発生を判定するしきい値 10 分あたり 10 件超 毎日超える スタンディングアラーム 常時 10 件未満 50〜200 件以上 従来手法によるアラーム合理化の期間 該当なし 12〜18 か月 訳注：スタンディングアラームとは、発生したまま数時間にわたって解消されないアラームのことです。 これらの数値は、発電所の制御室と T&D の運用センターの両方に当てはまります。アラームの発生元は、発電所では DCS とプロセスヒストリアン (AVEVA PI など)、変電所では SCADA と IEC 61850 対応の IED (Intelligent Electronic Device、インテリジェント電子デバイス) と異なりますが、オペレーターが置かれている状況は同じです。アラームが多すぎる一方で判断に必要なコンテキストが少なすぎ、システムをまたいでアラームを自動で関連付ける手段もありません。 問題が解消されない理由 アラームを調査するオペレーターは、複数のサイロ化されたシステムに対して手作業でクエリを実行する必要があります。 プロセスヒストリアン (AVEVA PI など)：センサーのトレンドと変化率の分析 設備保全管理システム (CMMS、IBM Maximo や SAP PM など)：保全履歴、期限を過ぎた予防保全 (PM: Preventive Maintenance)、故障の傾向 ドキュメント管理システム：OEM のアラーム対応手順、IEEE や IEC の規格、標準作業手順書 (SOP: Standard Operating Procedure) チケットシステムとインシデント履歴：過去の類似イベントとその解決策 各システムでは、全体像の一部しか把握できません。振動のトレンドを、期限を過ぎたベアリングの交換、OEM の技術情報、計画外停止につながった過去の類似故障 3 件と、1 つで関連付けられるツールがないのが現状です。アラームが大量発生している中で、このように 1 つずつ順に調べるやり方は現実的ではありません。 ソリューションの概要 単一のモノリシックな AI エージェントでは、4 つのデータドメインすべてに効果的に対応できません。プロセスヒストリアンのデータには、時系列分析の専門知識が必要です。保全記録には、CMMS の作業指示 (ワークオーダー) のライフサイクルと、信頼性重視保全 (RCM) の理解が必要です。機器のドキュメントには、技術マニュアルを対象とした検索拡張生成 (RAG) が必要です。インシデント履歴には、構造化されたチケットのスキーマを対象とした SQL 分析が必要です。 この課題には、マルチエージェントパターンで対処します。データドメインごとに専門のエージェントを置き、スーパーバイザーエージェントがそれらを統括します。スーパーバイザーエージェントはアラーム管理の規格を理解しており、各データドメインの調査結果を、対応につなげられる 1 つのレポートにまとめます。 次の図は、ソリューションのアーキテクチャを示しています。 図 1：電力・公益事業向けインテリジェントアラーム管理 (Amazon Bedrock AgentCore 上のマルチエージェントによるトリアージのアーキテクチャ) 主要なコンポーネントは次のとおりです。 Amazon Bedrock AgentCore Runtime は、すべてのエージェントと Model Context Protocol (MCP) ツールサーバーを、マネージドランタイムとしてホストします。ネットワークやコンピューティングのオーケストレーション基盤をプロビジョニングする必要はありません。 Strands Agents SDK は、ツールの利用、推論トレース、ストリーミングレスポンスを備えたエージェントフレームワークです。このソリューションでは Python SDK を使用しています。 MCP ツールサーバー は、各バックエンドを標準化されたプロトコルで公開します。新しいデータソース (SCADA ヒストリアン、排出量監視システム、気象 API など) を追加する場合は、新しい MCP サーバーを 1 つデプロイします。既存のエージェントは変更しません。 Amazon Bedrock ナレッジベース と Amazon S3 Vectors は、機器マニュアル、SOP、OEM の技術情報、アラーム対応のランブック、過去のインシデントレポートを対象とした RAG を提供します。ソースドキュメントは Amazon Simple Storage Service (Amazon S3) バケットにアップロードします。ナレッジベースはそのバケットをオンデマンドで同期し、各ドキュメントをチャンクに分割します。 Amazon Titan Text Embeddings v2 で埋め込みを生成し、類似検索に使うベクトルを S3 Vectors に書き込みます。 Amazon Aurora PostgreSQL Serverless は、インシデントチケットを保存し、過去のインシデントや ISA-18.2 に基づくアラーム KPI の SQL 分析に使います。 Amazon Bedrock 上の Anthropic Claude Sonnet (本実装では Claude Sonnet 4.6) が、各エージェントの推論を担います。 4 つのデータドメインすべてを 1 つのエージェントで扱うと、コンテキストウィンドウが埋まりやすく、どのドメインにも汎用的な回答しか返せず、クエリも 1 つずつ順に処理することになります。マルチエージェントアーキテクチャでは、各エージェントが 1 つのドメインに絞り、深い専門知識 (ISO の振動規格、CMMS のライフサイクル、NERC PRC-005 への準拠) を持って処理できます。スーパーバイザーエージェントはすべてのエージェントを並列に呼び出すため、レイテンシーが短くなります。新しいデータソースを追加するときは、新しいエージェントと MCP サーバーを用意するだけでよく、既存のコンポーネントは変更しません。各エージェントが独自の推論トレースを出力するため、システムのすべてのステップを監査できます。 仕組み：トリアージの流れ この記事のユースケース例では、コンバインドサイクルガス発電所のオペレーターが、通常の日勤シフト中に 1 号機を監視しています。そこに新しいアラーム「TUR-001.BRG3.VIB: HIGH VIBRATION, 68 micrometers」が表示されます。 オペレーターは、チャットインターフェイスに次のように入力します。「タービン 1 号機のベアリング #3 の振動が 68 ミクロンでアラームが発生した。何が起きているのか？」 スーパーバイザーエージェントは、これをアラームのトリアージ要求と判断し、4 つの専門エージェントすべてに同時に処理を振り分けます。 PI Historian エージェント： プロセスヒストリアンにクエリを実行し、次の結果を得ます。 30 日間のトレンド：2 週間で振動が 45 から 68 マイクロメートルに上昇 ベアリング #3 の温度も連動して上昇：同じ期間に 68 から 78°C パターン分類：実在し、進行中 (チャタリング〔断続的なばたつき〕、一過性、古い値のいずれでもない) 現在の 1 日あたり 1.5 µm のペースでは、約 5 日で ISO 10816 の Alert しきい値 (80 µm) に達する Maximo Maintenance エージェント： CMMS にクエリを実行し、次の結果を得ます。 ベアリング交換の予防保全 (作業指示 WO#45678) が、期限を 2 か月過ぎている 直近の類似故障：TUR-001 のベアリング #2 (2026 年 3 月) で、3 日間の計画外停止が発生した 修理コスト：事前に修理した場合は平均 45,000 ドル、故障後に対応した場合は平均 180,000 ドル 必要なベアリングアセンブリは、倉庫に在庫がある Document Knowledge エージェント： ナレッジベースから次の情報を取得します。 OEM TIL-2024-017：H クラスガスタービンのベアリング振動の制限値 ISO 10816-3：68 µm は「Satisfactory (良好) 」ゾーン、80 µm は「Alert (警戒) 」、130 µm は「Alarm (警報) 」 OEM の推奨：トレンドが 1 日あたり 0.5 µm を超えたら、ベアリングの状態を調査する (現在は 1 日あたり 1.5 µm で、しきい値の 3 倍) Ticket Analytics エージェント： 設備のインシデントチケットを管理するデータベースにクエリを実行し、過去のインシデントについて次の結果を得ます。 保有設備全体で、類似のベアリング劣化が 3 件 3 件中 2 件は、7 日以内に対処しなかったため計画外停止に至った 早期に発見した場合の平均解決時間は、計画保全で 8 時間 スーパーバイザーエージェントは、これらの調査結果を 1 つのレポートにまとめます。 重大度：高 TUR-001 でベアリング #3 の劣化が進行中。現在のペースでは、振動は 5 日以内に ISO の Alert しきい値に達する見込み。振動と連動した温度上昇から、機械的な摩耗と判断できる。ベアリング交換の予防保全は期限を 2 か月過ぎている。 推奨アクション： 48 時間以内にベアリングの点検を予定する (部品は在庫あり) 振動の監視頻度を 1 時間ごとに上げる 早期警告のため、75 µm に条件付きアラームを設定する 次に需要が低くなる期間に、8 時間の保守時間を確保する 先送りした場合のリスク：保有設備の履歴から、10 日以内に計画外停止となる確率は 67 %。コスト差：計画保全で 45,000 ドル、計画外では 180,000 ドル以上。 処理時間の合計は数分です。同じシステムを手作業で調査すると、通常 40〜60 分かかります。 アラームが大量発生するシナリオ：発電と T&D このアーキテクチャは、複数の設備にまたがってアラームが大量に発生した場合でも、同じパターンで処理します。たとえば、広い地域を嵐が襲っている間に、発電所と 3 つの変電所から 10 分間で 14 件のアラームがオペレーターのコンソールに殺到し、ISA-18.2 が大量発生と判定するしきい値を超えたとします。オペレーターが入力する質問は、次の 1 つです。「大規模な嵐で、コンソールにアラームが殺到している。実際の根本原因は何か。連鎖して発生した二次的なものはどれか。最初に何をすべきか？」 スーパーバイザーエージェントは、すべてのエージェントに処理を振り分けます。PI Historian エージェントはタイムスタンプを突き合わせ、独立した 2 つの事象を特定します。1 つは送電線の落雷事故で、下流で連鎖して発生した 8 件のアラームを伴いますが、これらは自然に解除されます。もう 1 つは、猛暑による変圧器巻線のホットスポット温度の上昇です。これは嵐とは無関係で、IEEE C57.91 のしきい値である 105°C に近づいています。スーパーバイザーエージェントは、根本原因と症状を切り分けて対応の優先順位を付け、該当する規格も引用して、それらすべてを 1 つの回答にまとめて提示します。 実装の詳細 この実装では、オーケストレーションに Strands Agents SDK を使い、バックエンドのデータソースを、言語に依存しない MCP ツールサーバーとして公開しています (Python と .NET の実装例を掲載)。ISA-18.2 のアラームパターン分類を含むドメインの専門知識は、エージェントのシステムプロンプトに直接記述しています。システム全体は、1 つの AWS Cloud Development Kit (AWS CDK) スタックでデプロイします。実装一式は GitHub で公開しています。 Strands SDK によるエージェントのオーケストレーション スーパーバイザーエージェントは、Strands Agents SDK を使い、Amazon Bedrock AgentCore の InvokeAgentRuntime API で専門エージェントを呼び出します。 @tool def invoke_specialized_agent(agent_key: str, query: str) -> str: """Invoke a specialized Alarm Management agent and return its response.""" agent_arn = AGENT_REGISTRY[agent_key]["arn"] payload = json.dumps({"prompt": query}).encode("utf-8") response = agentcore_client.invoke_agent_runtime( agentRuntimeArn=agent_arn, runtimeSessionId=_current_session_id.get(), contentType="application/json", accept="application/json", payload=payload, ) body = response.get("response") or response.get("body") raw = body.read() if hasattr(body, "read") else body result_text = raw.decode("utf-8") if isinstance(raw, bytes) else str(raw) parsed = json.loads(result_text) return parsed.get("response", result_text) データアクセス用の MCP ツールサーバー 各バックエンドは、MCP サーバーを通じて公開しています。たとえば PostgreSQL MCP サーバーは、text-to-SQL の機能を提供します。SELECT 以外の SQL 文は、データベースに届く前に拒否する安全策を備えています。 @mcp.tool() def run_query(sql: str) -> str: """Run a single read-only SELECT/WITH statement against the asset-ticketing database.""" _assert_select_only(sql) # Rejects INSERT/UPDATE/DELETE/DDL via sqlparse response = rds_client.execute_statement( resourceArn=CLUSTER_ARN, secretArn=SECRET_ARN, database=DATABASE_NAME, sql=sql, includeResultMetadata=True, ) columns = [c["name"] for c in response.get("columnMetadata", [])] rows = [dict(zip(columns, _decode(r))) for r in response.get("records", [])] return json.dumps({"sql": sql, "row_count": len(rows), "results": rows}, default=str) OEM の Web API SDK が .NET ベースのため、PI Historian MCP サーバーは .NET 8 で実装しています。AgentCore Runtime 上では、カスタムの ARM64 コンテナとして動作します。 var builder = WebApplication.CreateBuilder(args); builder.Services.AddMcpServer() .WithHttpTransport(o => o.Stateless = true) .WithTools<SensorDataTools>() .WithTools<TrendAnalysisTools>(); var app = builder.Build(); app.MapMcp("/mcp"); // POST /mcp on port 8000 app.Run("http://0.0.0.0:8000"); ここに MCP の大きな利点があります。MCP は、言語に依存しないプロトコルです。Python、.NET、Node.js をはじめ、HTTP を扱えるほとんどの言語で、Amazon Bedrock AgentCore 上の MCP ツールサーバーを実装できます。 ISA-18.2 に沿ったエージェントのプロンプト 各エージェントは、ドメインの専門知識をシステムプロンプトに直接記述しています。たとえば PI Historian エージェントは、すべてのアラームを ISA-18.2 のパターンカテゴリに分類します。 ### ISA-18.2 Alarm Pattern Classification Classify any alarm query into one of these patterns: - **Chattering**: cycles in/out more than 3 times in 1 minute (tuning/deadband issue) - **Fleeting**: clears on its own within seconds (noise/filtering issue) - **Standing**: continuously active for hours (largest source of alarm fatigue) - **Stale**: tag unchanged for days (suspect frozen signal/failed transmitter) - **Real and advancing**: monotonically tracking toward threshold (report time-to-threshold) 上のプロンプトの意味は、次のとおりです。 パターン 定義 問題 Chattering (チャタリング) 1 分間に 3 回超、発生/復帰を繰り返す チューニング/デッドバンドの問題 Fleeting (一過性) 数秒で自然復帰する ノイズ/フィルタリングの問題 Standing (スタンディングアラーム) 数時間にわたり、発生したままの状態が続く アラーム疲労 (alarm fatigue) の最大の原因 Stale (古い値) タグが数日間変化しない 信号凍結/伝送器故障の疑い Real and advancing (実在・進行中) しきい値に向かって単調に推移 本物の異常 (しきい値への到達までの時間を報告) Infrastructure as Code (IaC) システム全体は、1 つの親 AWS CDK スタックでデプロイします。親スタックは、次の 2 つのネストされたスタックで構成されています。 StorageStack (ネストされたスタック)：ドキュメントを保存する S3 バケットと、S3 Vectors を使う Amazon Bedrock ナレッジベース (1024 次元、コサイン類似度、Amazon Titan Text Embeddings v2) RuntimeStack (ネストされたスタック)：5 つの AgentCore エージェントランタイムと、4 つの MCP サーバーランタイム。スーパーバイザー、サブエージェント、MCP サーバーの間で必要な AWS Identity and Access Management (IAM) の権限も設定します。 cdk deploy alarm-management # Deploys both nested stacks in dependency order 設計上の主な判断 このソリューションのアーキテクチャは、4 つの設計判断に基づいています。いずれも、すぐに評価できることと、本番環境での安全性やオペレーターの信頼とのバランスを取ったものです。 デフォルトでモックを使い、すぐに評価できる： すべての MCP サーバーに、シミュレーターが組み込まれています。リポジトリをクローンしてデプロイすれば、ISA-18.2 の典型的なシナリオ 6 種類を収録したモックデータで、デモをエンドツーエンドで実行できます。実際のバックエンドへの切り替えは環境変数の設定で行い、コードの変更は不要です。 MCP によるデータソースの抽象化： 新しいデータソース (嵐との関連を調べる気象 API、排出量監視システム、SCADA ヒストリアンなど) を追加する場合は、新しい MCP サーバーを 1 つデプロイします。既存のエージェントとスーパーバイザーエージェントは変更しません。 推論の透明性： スーパーバイザーエージェントは、推論トレース全体をストリーミングで出力します。どのエージェントを呼び出したか、各エージェントで何が分かったか、調査結果をどのようにまとめたかが含まれます。オペレーターは、すべての推奨事項について根拠のつながりを確認できるため、システムの結論を信頼しやすくなります。 Text-to-SQL の安全性： PostgreSQL MCP サーバーは、すべての SQL 文字列を sqlparse で解析します。複数の文を含む入力、SELECT と WITH 以外のキーワード、網羅的な禁止キーワードの一覧に該当するものは拒否します。そのため、LLM がこのインターフェイスを通じてデータベースを変更することはできません。 前提条件 このソリューションを実装するには、次のものが必要です。 Amazon Bedrock で次のモデルにアクセスできる AWS アカウント (Anthropic Claude Sonnet 4.6、Amazon Titan Text Embeddings v2) AWS CDK v2.170 以降 Python 3.10 以降と .NET 8 SDK Docker (AWS CDK でコンテナイメージをビルドするため) デプロイと実行 次のコマンドで、インフラストラクチャをデプロイし、UI を実行します。 git clone https://github.com/aws-samples/sample-intelligent-alarms-agent.git cd sample-intelligent-alarms-agent # Deploy infrastructure cdk bootstrap aws://<ACCOUNT_ID>/<REGION> cdk deploy alarm-management # Run the operator chat UI locally cd ui/streamlit cp .env.example .env # Add SUPERVISOR_AGENT_ARN from CDK output streamlit run app.py 訳注：原文では cd intelligent-alarm-management-agent と記載されていますが、クローンされるディレクトリ名に合わせて修正しています。 デプロイ直後から、モックデータを使ってエンドツーエンドで動作します。本番データを使う準備ができたら、MCP サーバーの接続先を、お使いのプロセスヒストリアン、CMMS、Aurora PostgreSQL 互換エディション、Amazon Bedrock ナレッジベースに切り替えてください。 デプロイの確認 Streamlit が起動したら、「過去 24 時間の TUR-001 のベアリング #3 の振動トレンドを表示して」などのサンプル質問を入力します。UI に、推論トレース付きの回答がストリーミングで表示されます。これで、Streamlit アプリケーション、スーパーバイザーエージェント、PI Historian エージェントに接続でき、それぞれが応答していることを確認できます。 コストについて このリファレンスアーキテクチャは、AgentCore Runtime、Amazon S3、Amazon Bedrock ナレッジベース、Amazon Elastic Container Registry (Amazon ECR) など、課金対象の AWS リソースをプロビジョニングします。モックモードで動かす低トラフィックのデモであれば、月額で約 10〜30 ドルが目安です。実データに接続して使う場合 (Aurora クラスター、継続的な呼び出し、ナレッジベースへの大量の取り込み) は、費用が大幅に高くなります。実際のコストは、AWS Cost Explorer で確認してください。 クリーンアップ デプロイしたリソースを削除するには、次のコマンドを実行します。 cdk destroy alarm-management このコマンドを実行すると、アップロードしたドキュメントとナレッジベースに取り込んだデータが削除され、元に戻せません。独自に追加したドキュメントは、実行する前にバックアップしてください。 ソリューションの拡張 このリファレンスアーキテクチャが示しているのは、発生したアラームに対応するトリアージです。オペレーターが質問をすると、数分で回答が得られます。発展させる方向として、次のものが考えられます。 予測的なアラーム ：同じ PI Historian エージェントで、学習したベースラインと比べてトレンドを継続的に監視し、アラームが発生する前に劣化を捉える 作業指示の自動生成 ：システムが保全の必要性を特定したときに、正しい故障コード、優先度、部品リストを含む Maximo の作業指示の下書きを作成する アラーム合理化の加速 ：Ticket Analytics エージェントで頻発するアラーム (バッドアクター：発生頻度が上位 N 件のアラーム) を特定し、ISA-18.2 の目標値に沿って、抑制、優先度の見直し、設定値の変更を提案する シフト引き継ぎの支援 ：退勤するシフトのアラームの発生状況、進行中の調査、未完了の対応を、次のシフトのオペレーター向けに要約する Amazon Bedrock AgentCore Gateway によるツールのスケーリング このリファレンス実装では、起動時に、各 MCP サーバーのツール一覧のすべてをエージェントに渡しています。現在の規模 (4 つのサーバーで計十数個のツール) では、この方法で問題ありません。しかし、接続するデータソースが SCADA、気象、排出量、保護リレーなどへと広がると、ツールの合計数はいずれ、1 つのエージェントのコンテキストに無理なく収まる範囲を超えます。ツール数がおよそ 50〜100 個を超える場合は、Amazon Bedrock AgentCore Gateway を使う構成が推奨されます。ツールはゲートウェイに登録しておき、エージェントは、すべてのプロンプトにすべてのツール定義を含めるのではなく、クエリごとに意味的に関連するツールだけを取得します。これにより、データソースを追加しても、プロンプトの大きさに上限を保ち、レイテンシーも見通せる範囲に収まります。 セキュリティとコンプライアンスの態勢 このアーキテクチャは、ID、暗号化、ネットワーク分離、監査の各領域で、多層防御を実現しています。 エージェントの最小権限 ：各 AgentCore エージェントランタイムと MCP サーバーランタイムは、それぞれ専用の IAM 実行ロールで動作し、ポリシーの範囲は厳密に絞っています。スーパーバイザーエージェントはサブエージェントを呼び出せますが、サブエージェント同士は呼び出せません。MCP サーバーには、それぞれのバックエンドへの接続に必要な権限だけを与えています。これにより、ラテラルムーブメント (横方向への侵害の拡大) を設計の段階で防ぎます。 シークレットの管理 ：バックエンドの認証情報は AWS Secrets Manager に保存し、実行時に Amazon リソースネーム (ARN) で参照します。シークレットは、エージェントのプロンプト、環境変数、ソースコードには埋め込みません。Secrets Manager は自動ローテーションに対応しており、アクセスは AWS CloudTrail で監査します。 保存時と転送時の暗号化 ：Amazon S3、Aurora PostgreSQL 互換エディション、Amazon Bedrock ナレッジベースに保存するデータは、 AWS Key Management Service (AWS KMS) で暗号化します。キーのローテーションのポリシーと、アクセスログの記録は設定できます。サービス間の通信は、TLS 1.2 以降で暗号化した経路を通ります。 ネットワークの分離 ：AgentCore Runtime と MCP サーバーは、マネージドなコンピューティング環境で動作し、デフォルトではパブリックインターネットに公開されません。オンプレミスのシステムへの接続は、 AWS PrivateLink や仮想プライベートクラウド (VPC) エンドポイントを経由させることができ、OT/IT のデータがパブリックインターネットを通らないようにできます。 ログ記録と監視 ：CloudTrail は、Amazon Bedrock、Amazon Bedrock AgentCore、Secrets Manager、Amazon S3、AWS KMS の API 呼び出しを記録します。 Amazon CloudWatch は、エージェントの呼び出しメトリクス、レイテンシー、エラー率を収集します。スーパーバイザーエージェントの推論トレース全体はセッションごとにログに記録され、どのエージェントを呼び出したか、どのデータにアクセスしたか、調査結果をどのようにまとめたかが残ります。 ガードレール ：Amazon Bedrock Guardrails は、モデルの呼び出しに、コンテンツフィルターと拒否トピックのポリシーを適用します。これにより、プロンプトインジェクションを防ぎ、安全でないコンテンツの生成をブロックし、扱う話題の範囲を制限して、エージェントが担当する業務の範囲にとどまるようにします。 まとめ 電力・公益事業におけるアラーム管理は、知見が十分に蓄積された運用分野です。ISA-18.2 や EEMUA 191 などの業界規格が目標値を定めており、課題も数値で示されています (不要アラームが 60〜80% を占め、アラームの大量発生が毎日起きている)。また、適切なアラーム管理は、運用の信頼性を高める重要な要素とされています。残る課題は、分断された運用システムをまたいで、リアルタイムに関連付けることです。 Amazon Bedrock AgentCore 上のマルチエージェントアーキテクチャは、この課題に対応します。専門エージェントが各データドメインに並列でクエリを実行し、スーパーバイザーエージェントがアラーム管理の規格に照らして調査結果をまとめます。推論の過程をすべて示しながら、トリアージにかかる時間を数時間から数分に短縮します。 リファレンス実装 は、クローンしてデプロイすれば、お手元の運用データで評価できます。まずモックのシナリオでエージェント間のやり取りを確かめ、次にお使いの PI Historian、CMMS、ドキュメント管理システムを接続して、実際のアラームで効果を確かめてください。 本ブログはソリューションアーキテクトの筒井 智哉が翻訳しました。 Muthu Kumar Muthu Kumar は AWS のシニアソリューションアーキテクトです。エネルギー・公益事業のお客様が、運用の高度化に向けてクラウドと AI の技術を導入できるよう支援しています。テクノロジーを活用し、お客様とともにビジネスの成果を上げることに力を注いでいます。 Ganapathi Krishnamoorthi Ganapathi Krishnamoorthi は AWS の生成 AI と機械学習を担当するプリンシパルスペシャリストソリューションアーキテクトです。お客様が本番環境の AI/ML システムを設計、実装できるよう支援しています。 Stephen Knox Stephen Knox は AWS のプリンシパルカスタマーソリューションマネージャーです。電力・公益事業のお客様と協力し、クラウドの価値の実現を推進しています。エネルギー企業がデジタルトランスフォーメーションを加速し、運用を最適化し、サステナビリティに関する約束を果たせるよう、戦略的な助言を行っています。エネルギー業界全体で、ビジネス戦略とテクノロジーの成果を結び付けることに力を注いでいます。

2026 年 8 月 31 日週、 Claude Fable 5.1 が AWS で利用可能になりました 。Anthropic によると、Claude Fable 5.1 は、コーディング、科学研究、エンタープライズワークフローにわたる高度なタスクに、最新鋭のインテリジェンスを提供します。Claude Fable 5.1 は、作業が何時間にもわたって続き、多数のアプリケーションを横断的に使用する、長時間かつ重要度の高い作業向けに構築されています。ソフトウェアプロジェクトのより多くの部分を単独で担当でき、長時間のセッションを通じて、コードベース全体にわたる機能、コードレビュー、パフォーマンス関連の作業を扱うことができます。 Anthropic は、Fable 5.1 を 対象モデル に指定しています。対象モデルとは、提供先を問わず、追加のデータ保持、安全性レビュー、アクセスポリシーが適用される Claude モデルのカテゴリです。Claude Fable 5.1 は、新しい aws_review データ保持モード により、最大 30 日間のデータ保持と、Amazon 担当者が行う人的レビューの対象となります。このモードでは、AWS はお客様のプロンプトと出力内容を AWS の境界内で人的な安全性レビュー用に保持します。 provider_data_share モードはレガシーモードであり、Amazon Bedrock はモデルプロバイダーとデータを共有しません。加えて、AWS と Anthropic のパートナーシップにより構築された エンタープライズフロンティアセーフガード (EFS) により、対象となるお客様は、自分の管理するクラウド環境にデータを保持したまま、対象モデルを使用できます。 Claude Fable 5.1 にアクセスするには、Amazon Bedrock と Claude Platform on AWS の 2 つの方法があります。詳細については、 Amazon Bedrock の Claude Fable 5.1 モデルカード と「 Claude Platform on AWS 」を参照してください。  8 月 31 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon Linux 2027 (AL2027) がパブリックプレビュー中 : AL2027 は Amazon Linux オペレーティングシステムの次期バージョンです。カーネル 7.1 以降で動作し、パフォーマンス、スケール、セキュリティを念頭に置いて AWS 上のクラウドネイティブワークロード専用に構築されています。AL2023 のベースラインに基づいて構築された AL2027 は、ウェブアプリケーション、データベース、コンテナ化されたマイクロサービス、AI/ML ワークロード、および大規模インフラストラクチャを実行する、安全かつ安定した AWS ネイティブなオペレーティングシステムを必要とするお客様向けに設計されています。 Amazon EC2 R9g および R9gd のメモリ最適化インスタンス : これらのインスタンスは AWS Graviton5 プロセッサを使用しており、Amazon EC2 で実行されるメモリを大量に消費するワークロードに最適な料金パフォーマンスを提供します。R9g および R9gd インスタンスは、AWS Graviton4 ベースの R8g および R8gd インスタンスと比較して最大 25% 優れたコンピューティングパフォーマンスを提供します。データベースでは最大 30%、ウェブアプリケーションでは最大 35%、機械学習では最大 35% 高速になります。詳細については、 Daniel のブログ記事 をお読みください。 コンテナイメージ関数用 AWS Lambda SnapStart : Lambda SnapStart はオプトイン機能です。リソースをプロビジョニングしたり、複雑なパフォーマンス最適化を実装したりしなくても、応答性が高くスケーラブルなアプリケーションを簡単に構築できます。 これまで、SnapStart はマネージドランタイム (Python、.NET、Java) でのみサポートされていました。今後は、SnapStart をコンテナイメージに使用して、ML 推論やインタラクティブ API などの遅延の影響を受けやすいワークロードの起動時間を数秒から 1 秒未満に短縮できます。 AWS Agent Registry の一般提供開始 : AWS Agent Registry は、組織内のエージェント、ツール、スキル、MCP サーバー、およびカスタムリソース用に、管理されたプライベートなカタログおよび検出レイヤーを提供します。プレビューで導入された機能 (手動および URL ベースのレコード作成、承認ワークフロー、セマンティック検索、キーワード検索、AWS CloudTrail 監査証跡) に加えて、今回 Registry には新しいエンタープライズ向けの機能が追加されました。詳細については、 AI ブログの記事 をご覧ください。 Amazon Redshift が Apache Iceberg v3 テーブルのサポートを開始 : Amazon Redshift のデータレイクにある Apache Iceberg v3 テーブルからの読み取りと書き込みが可能になります。今回のリリースにより、Amazon Redshift にはデフォルトの列値、行系統、および削除ベクトルのサポートが導入されます。Amazon Redshift の Graviton ベースのプロビジョニングクラスターとサーバーレスクラスターは、新しい v3 フォーマットをサポートしています。詳細については、「 Redshift の Apache Iceberg v3 の機能 」をご覧ください。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深いと思われるその他のプロジェクトやニュース項目をいくつかご紹介いたします。 2026 年のガートナーマジッククアドラントの戦略的クラウドプラットフォームサービス部門で AWS がリーダーに選出 : ガートナー社は 2026 年のマジッククアドラントの戦略的クラウドプラットフォームサービス部門で AWS を 16 年連続でリーダーに認定し、実行能力の軸で再び AWS を最高ランクに位置付けました。この評価は、インフラストラクチャと AI からセキュリティ、運用に至るまで、最も広範で奥深いクラウド機能セットを提供するという当社の取り組みが反映されたものであると考えており、お客様には安心して構築、革新、スケールに取り組んでいただけます。 AWS Certified AI Business Strategist : この新しい認定は、組織内の AI イニシアチブを評価し、支持し、拡大する専門家を対象としています。これには、チーム全体で導入を推進する基幹業務リーダー、顧客に AI の価値をわかりやすく説明する営業担当者、実験から本稼働までのクライアント戦略を導くコンサルタント、AI への投資をビジネスの成果へと結びつけるプログラムマネージャーなどが挙げられます。ベータ試験の登録は 2026 年 9 月 1 日に開始され、試験の配信は 9 月 29 日から開始されます。 エージェントセキュリティ: マシンスピードでの検知と対応 : 私たちは、セキュリティは AI の導入後ではなく、その前に進化すべきだと考えています。この信念のもと、私たちのチームは SANS Institute と協力して、2026 年発行の Cloud Security Exchange eBook に新たな章を設けました。本章では、エンタープライズ規模でエージェントワークロードを保護するための実践的なフレームワークについて説明しています。また、評価、試験運用、大規模運用を問わず、エージェンティック AI 導入のあらゆる成熟段階にあるセキュリティチームに対して、具体的なアーキテクチャパターン、実装ガイダンス、フレームワークを提供し、エージェントワークロードの保護についてもさらに深く掘り下げています。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント ( AWS re:Invent 、 AWS Summit 、 AWS Community Day など) を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 9 月 7 日週のニュースは以上です。9 月 14 日週に再びアクセスして、新たな1週間のまとめをぜひお読みください! — Channy 原文は こちら です。

本記事は 2026 年 6 月 4 日 に .NET on AWS Blog で公開された「 AWS Transform SQL Server to PostgreSQL Schema Validation in .NET Application Modernization 」を翻訳したものです。 本記事の執筆には Sayan Ghosh、Yuhao Zhang、Uday Kiran Erukulla、Srinivasa Varadan Saragur Madabhushi、Koushik Rajagopal、Khurram Khawaja、Vikas Babu Gali、Luke Huan が協力しました。 Microsoft SQL Server から Amazon Aurora PostgreSQL – Compatible Edition へのデータベース移行は、ライセンスコストの削減、スケーラビリティの向上、オープンソースデータベース技術の活用を目指す組織にとって一般的なモダナイゼーション戦略です。ただし、SQL Server データベースを Aurora PostgreSQL に移行する際、スキーマ変換はあくまで出発点に過ぎません。真の課題は、すべてのテーブル、制約、ストアドプロシージャ、トリガーが正しく移行され、移行先の PostgreSQL 環境でも同一の動作をすることを検証する点にあります。小数精度の変更をひとつ見落としたり、ストアドプロシージャの変換に誤りがあったりするだけで、本番環境でデータ破損やアプリケーション障害、ビジネスロジックの誤動作を招くおそれがあります。 手動でのスポットチェック、スモークテスト、単純な行数比較に頼る従来の移行テストでは、こうした微妙な意味の違いを捉えられません。オブジェクトが存在するかどうかだけでなく、機能的に等価であるかまで検証する体系的なアプローチが必要です。 この記事では、 AWS Transform が構造分析、意味検証、動作テストを組み合わせた 3 層の検証モデルによって、SQL Server から PostgreSQL への移行に対する包括的なスキーマ検証を実現する仕組みを紹介します。あわせて、 Amazon Bedrock を活用した AI エージェントが検証結果を分析し、根本原因ごとに問題をまとめ、重大度を判定して修正の優先順位付けを支援する流れも解説します。 ソリューション概要 AWS Transform のスキーマ検証は、移行元と移行先の両方を稼働中のデータベースエンジンにデプロイし、そこに対して直接チェックを実行することで、移行済みデータベーススキーマの検証をエンドツーエンドで自動化します。この検証は移行先スキーマの作り方に依存しません。ルールベースのツール、エージェンティックなソリューション、独自に構築した生成 AI (GenAI) 変換パイプラインのいずれで生成したスキーマにも適用できます。図 1 は、移行元と移行先のスキーマが検証ワークフローをどのように流れるかを示しています。 図 1. エンドツーエンドのスキーマ検証ワークフロー 図 1 のとおり、検証は以下の流れで進みます。 移行元の SQL Server スキーマと移行先の PostgreSQL スキーマを、それぞれ専用の Amazon Elastic Container Service (Amazon ECS) コンテナに読み込む 両方のスキーマが Tier 1 (構造的検証) に入り、検証ワークフローが各オブジェクトが移行先に存在するかをプログラムでチェックする 構造チェックを通過したオブジェクトが Tier 2 に進み、意味的な等価性を比較する 意味チェックを通過したストアドプロシージャが Tier 3 (動作検証) に進み、ランタイムでテストする 各 Tier がオブジェクトごとの判定 (PASS、FAIL、または WARNING) を出力し、スコアリング層に集約される エキスパートアセスメントエージェントがすべての判定を確認し、両方の稼働中データベースにクエリを発行してフラグの立った問題を裏付ける。その後、検出内容を根本原因ごとにまとめ、重大度を判定し、最終的な本番移行準備レポートを生成する ウォークスルー このワークフローは、内部的には以下の 5 つのステップとして実行されます。 移行元 SQL Server と PostgreSQL の検証コンテナを Amazon ECS 上で起動する 移行元と移行先のスキーマを、対応する検証用データベースに読み込む 両方のデータベースにクエリを発行してルールベースのチェックを実行する Amazon Strands Agents を使って AI エキスパートによる分析を実行する 最終的な検証レポートを生成する この検証は 2 つの原則に基づいています。 正規表現による解析ではなく、稼働中のデータベースを使う 。バリデーターは稼働中の各データベースに直接クエリを発行します。生の SQL ファイルの記述内容ではなく、エンジンが実際に解釈した内容を報告します。 決定論的な処理を先に、LLM は後に 。ルールベースのチェックを大規模言語モデル (LLM) 層より前に実行し、LLM にはフィルタリング済みの入力を渡します。これにより LLM は決定論的なシグナルを置き換えるのではなく、補強する役割を担います。 これらの原則のもと、ルールベースのチェックと AI 分析は以下のように動作します。 1. 構造的検証 (Tier-1) 目的 : 移行元スキーマのすべてのデータベースオブジェクトが移行先スキーマに存在することを検証する この Tier では、移行元と移行先の両方のデータベースに直接クエリを発行し、すべてのスキーマオブジェクトに対してルールベースの存在チェックを並行して実行します。以下の表に例を示します。 オブジェクトタイプ チェック内容 テーブル 各テーブルが移行先に存在し、列と NULL 許可のルールが一致することを確認する 制約 主キー、外部キー (カスケードルールを含む)、一意制約、CHECK 制約を検証する 構造の照合で見落としやすい課題が、名前の正規化です。SQL Server は既定で大文字小文字を区別しませんが、PostgreSQL は引用符で囲まない識別子を小文字に折りたたみ、大文字小文字を区別して扱います。さらに PostgreSQL は識別子を 63 バイトで切り詰めます。そのため、SQL Server 上では別名だった 2 つのプロシージャが PostgreSQL 上では同じ名前に統合されることがあり、正しく移行できたテーブルが単純なバイト単位の比較では不一致と判定されてしまいます。これを避けるため、構造の照合では大文字小文字の折りたたみ、切り詰め、引用符の除去という段階を踏んで名前を正規化し、各段階でレコードの正規化を適用します。 2. 意味的検証 (Tier-2) 目的 : 移行したオブジェクトが構造として存在するだけでなく、意味的に等価であることを検証する Tier 1 がオブジェクトの存在を確認するのに対し、Tier 2 はその定義が意味的に等価かどうかをチェックします。チェックはルールベースで、SQL Server と PostgreSQL の型システム間の型マッピングと精度のルールを組み込んでいます。以下に例を示します。 チェック 例 型マッピング nvarchar(100) から character varying(100) への変換は有効。integer への変換は無効 数値精度 decimal(18,2) は numeric(18,2) のままである必要があり、numeric(10,0) では不可 意味チェックが等価性を捏造することはありません。正規化できない場合 (既定値に互換性がないなど) は、黙って修正を適用するのではなく WARNING を出します。これにより、不要なアラートを増やさずに本番環境での問題を防げます。 3. 動作検証 (Tier-3) 目的 : ランタイムの動作が期待どおりであることを確認する Tier 2 で定義を検証したうえで、Tier 3 では実際のランタイム動作をテストします。2 つのルーチンが構造チェックと意味チェックの両方を通過しても、スタブ、分岐処理のバグ、変換で失われる方言固有の機能などが原因で、異なる結果を返すことがあります。こうした問題を洗い出すため、動作検証は次の 3 ステップで段階的に踏み込みます。 ステップ 1: スタブの検出 バリデーターは、PostgreSQL 側のルーチン本体が意味のある実装になっているか、それとも BEGIN RETURN 0; END のようなプレースホルダーのロジックだけかを調べます。スタブの生成は自動変換で最も起こりやすい失敗パターンのひとつなので、最初に検出しておくことで後続ステップの無駄な作業を防げます。 以下は、変換時に AI エージェントが SQL Server プロシージャから生成した PostgreSQL のスタブの例です。 SQL Server プロシージャ : --SQL Server procedure CREATE PROCEDURE BabelFish.bf_collationproperty @collation_name SYSNAME = 'Traditional_Spanish_CS_AS_KS_WS', @prop_name VARCHAR(255) = 'CodePage' AS BEGIN SELECT COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'CodePage') AS 'CodePage' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'LCID') AS 'LCID' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'ComparisonStyle') AS 'ComparisonStyle' , COLLATIONPROPERTY('Traditional_Spanish_CS_AS_KS_WS', 'Version') AS 'Version'; END; PostgreSQL のスタブプロシージャ : --PostgreSQL stub procedure CREATE OR REPLACE PROCEDURE babelfish.bf_collationproperty(IN collation_name varchar(128) DEFAULT 'Traditional_Spanish_CS_AS_KS_WS', IN prop_name varchar(255) DEFAULT 'CodePage') LANGUAGE plpgsql AS $body$ BEGIN RAISE NOTICE 'Stub: babelfish.bf_collationproperty - needs manual T-SQL to PL/pgSQL conversion'; END; $body$; ステップ 2: 構造の検証 バリデーターは両側のルーチンのシグネチャ、入出力パラメータ、戻り値の型を検査し、移行後のアプリケーションで呼び出しエラーを引き起こす構造の不一致を特定します。 ステップ 3: ミューテーションテストと LLM による評価 バリデーターはテスト入力を生成し、両方のデータベースに対して実行して結果を比較します。行レベルで 1 件でも差異があれば、それが 2 つのルーチンが等価でないことを示す具体的な反例になります。ミューテーションテストで判断がつかない場合は、Amazon Bedrock を通じた LLM による評価で機能的な等価性を判定し、最終的な結論を出します。 4. スコアリング 各チェックは、オブジェクトごとに PASS/FAIL または WARNING を出力します。レポートには 決定論的な 2 つの主要スコア が示され、同じ入力であれば実行ごとに同じ値になります。 Storage Score – データを保持するオブジェクト (テーブル、インデックス) 全体でのスキーマの一貫性を測る Code Score – 実行可能なオブジェクト (ビュー、ストアドプロシージャ、関数、トリガー) 全体での機能カバレッジを測る この 2 つの数値で移行のカバレッジを素早く把握できますが、最終的な評価を決めるのはこれらではありません。それを担うのが AI ジャッジ ( LLM-as-a-Judge )です。これは、エキスパートレビュワーとして振る舞う Amazon Strands Agents です。ルールベースのチェックが答えるのは「何が違うのか」です。これに対して AI ジャッジが答えるのは「それは重要なのか、どう直すべきか」です。 この AI ジャッジは両方の稼働中データベースに読み取り専用でアクセスでき、フラグの立った問題を裏付けたり否定したりするために自ら検証クエリを発行できます。そのうえで、この Strands Agents が検出内容を根本原因ごとのクラスターにまとめます。たとえば、スキーマがひとつ欠けていることが原因で 29 個のトリガーが欠落している場合、29 件ではなく 1 件のクラスターとして扱われます。各クラスターには次の重大度が割り当てられます。 重大度 基準 CRITICAL ユーザーデータの損失または破損 HIGH 将来的に気づきにくい障害が起きる、またはアプリケーションからの呼び出しが失敗する MEDIUM アプリケーションが意図どおりに動作しない可能性がある LOW 表示上の問題で、動作を妨げない 根本原因ごとにまとめるこのアプローチでは、影響を受けたオブジェクトを個別に列挙するのではなく、大元の問題に対処するためノイズが減ります。共通の原因を修正すれば、そこから派生したすべての症状が一度に解消します。 本番移行準備の判定ルール Critical の検出があれば、他のスコアに関わらず本番デプロイをブロックする High のクラスターがあれば条件付きの準備完了となる (追加の検証が必要) Medium と Low の問題は、Critical や High のブロッカーを上書きしない まとめ SQL Server から PostgreSQL への移行は影響範囲の大きい変更であり、テストに合格したというだけでは正しさの証明にはなりません。AWS Transform の 3 層検証ワークフローは、その主張を監査可能な成果物に変えます。Tier 1 ですべてのオブジェクトが移行できたことを確認し、Tier 2 で個々のオブジェクトが意味的に等価であることを確認し、Tier 3 でルーチンが同じ結果を返すことを実際に検証します。さらに AI ジャッジである Amazon Strands エージェントが検出内容を根本原因ごとにまとめ、重大度にもとづいた評価を出すため、主要スコアが高いだけで重大なデータ損失の問題が見過ごされることはありません。 まずは最初のスキーマ移行の検証を AWS Transform で試してみてください。詳細は以下のリソースをご覧ください。 AWS Transform Amazon Aurora PostgreSQL Amazon Bedrock Amazon Strands Agents 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Amit Kachroo Dr. Amit は、Amazon Agentic AI Science チームのシニアアプライドサイエンティストとして、コード変換のための生成 AI および LLM システムを構築しています。さまざまなプログラミング言語やデータベースに対応した変換機能を開発するサイエンスチームを率いています。詳しくは https://amitkac.github.io/ をご覧ください。 Vijay Mandadi Vijay は、AWS Migrations and Modernizations グループのエンジニアリングリーダーです。分散システム、クラウドコンピューティング、仮想化、ワークロード変換、ヘルスケアの分野で 16 年以上の経験を持ちます。AWS では、生成 AI とエージェンティック AI を活用して、お客様のアプリケーションワークロードのモダナイゼーションとクラウドネイティブ化を加速することに取り組んでいます。 Nits Jeganathan Nits は、AWS Transform のプロダクトリーダーです。IT 業界で 15 年の経験を持ち、エッジコンピューティング、システム開発、アプリケーションモダナイゼーションの分野で 12 件の特許と 2 件の論文があります。複雑な課題の解決とカスタマーエクスペリエンスの向上に情熱を注いでおり、現在は生成 AI を使ったレガシーアプリケーションのモダナイゼーション加速に注力しています。