Agentic AI を搭載したスマートグリッドマネジメントプラットフォーム

ソリューション概要

電力会社は大規模な高頻度のスマート メーター データを収集しますが、チームはモニタリング、予測、カスタマー分析、AI ワークフローを別々のシステムで管理することが多くあります。

この分断により、データ パイプラインの重複、意思決定の遅延、オペレーション コストの増加が発生します。

スマート グリッド インテリジェント プラットフォームは、リアルタイム モニタリング、ネットワーク 操作、需要予測、カスタマー インテリジェンス、およびグリッド サポート エージェントに対して 1 つの操作データ レイヤーを使用することで、MongoDB Atlas でこれらのワークロードを実行できる方法を示します。

このソリューションは、次の目的に使用します。

• グリッドをリアルタイムでモニターする: 停止時を検出し、力率を追跡し、異常 (電圧スパイク、通常ではない消費) をデータベースで直接フラグを付けます。

• ネットワークの操作: グリッドトポロジー (電力会社 → 変電所 → 配電線 → 変圧器) を視覚化し、変電所の健康状態をスコアリングし、ライブのキャパシティー利用率からピーク負荷警告と停止時のリスクを明らかにします。

• 気象で需要を予測: 外部の気象データ（暖房度日と冷房度日）で強化されたリージョン別の予測需要とピークタイミングをプロジェクトし、キャパシティーを計画して過負荷を防止します。

• カスタマーを理解する: 同じメーターデータから、料金の推奨、消費倫向、アプライアンス別の内訳、および使用セグメントを明らかにします。

• 自然言語で操作する: グリッドサポートエージェントを介して、グリッド、ネットワーク、知識ベース、カスタマーデータをクエリします。

MongoDB Atlas は、時系列データ、柔軟なデータモデリング、インデータベースプロセシング、AI 検索の組み込み機能により、このデザインをサポートしています。

• MongoDB Atlas 時系列: ネイティブ時系列コレクションは、高頻度のメーター読み取りを効率的に保存します。また、高速の一時的クエリを実行できます。

• 集計フレームワーク: アプリではなくデータベース内で実行される分析、$setWindowFields を使用した停止時の欠陥と分離の検出、$group と $stdDevSamp を使用した異常と需要の統計、および各アセットの定格キャパシティに対して測定される給電器/変電所の利用率。高頻度の読み取り（需要、予測）は、既にグリッドコンテキストを持つ読み取りに対して単一のコレクションスキャンとして実行されます。

• 柔軟な document model: メーター、カスタマー、グリッド ネットワークの階層は関連するドキュメントとして存在し、ネットワークの進化に合わせて移行する必要のある固定されたスキーマはなく、オンデマンドで結合されます。

• 自動化された Voyage AI 埋め込みを使用した Atlas Vector Search：別の埋め込みサービスを操作する必要なく、ドメイン知識ベースについてセマンティック検索を実行します。Voyage AI を参照

• ハイブリッド検索: ベクトルと全文検索の結果を相互順位融合 (RRF) して、より関連性の高い取得を実現します。

• MongoDB における Agentic AI: Atlas に永続化されたドメイン別の実力と会話メモリを持つ LangGraph のマルチエージェントアシスタント。これにより、コンテキストは運用データとともに保存され、外部の状態保存は不要です。

図 1Smart Grid Intelligent Platform の主な機能

クリックして拡大します

参照アーキテクチャ

プラットフォームは、単一の MongoDB Atlas クラスター上で次のレイヤーを組み合わせます。

• モニタリング、ネットワーク、予測、およびカスタマーの表示を動作させる操作データ レイヤー

• ユーザーが自然言語ですべてをクエリできる、エージェント AI レイヤー。

どちらも同じドキュメントから読み取るため、情報をコピーまたは同期する別個のシステムは必要ありません。

図 2ハイレベル Smart Grid アーキテクチャ - Operational Data Layer

クリックして拡大します

Agentic AI Layer

ユーザーの自然言語の質問は、質問を検討し、適切なツールを呼び出し、MongoDBからデータを取得し、根拠のある回答を返すLangGraphのマルチエージェントオーケストレーターを介して流れます。その間、会話メモリと検索データは同じAtlasクラスター内に存在します。

図 3高レベル LLM オーケストレーション - Agentic AI レイヤー

クリックして拡大します

クエリはアーキテクチャ内をこのように流れます。

1. ユーザー クエリ（インターフェース）: ユーザーがグリッド サポート エージェントに自然言語で質問します。インターフェースはリクエスト（リクエスト: <user query>）をエージェントに送信し、後で応答（応答: <answer>）をレンダーします。

2. 認識: エージェントは、ユーザー クエリとプラットフォームのコレクションに JSON として保存されている操作データを含む MongoDB ドキュメントとして、その世界を認識します。これは、エージェントが推理するコンテキストです。

3. 計画: LangGraph オーケストレーターはリクエストを解釈し、適切なドメインワークフローにルーティングし、必要なツールを呼び出し、根拠のある回答を返します。

4. ツール: エージェントは選択されたツールを実行します。

   • 知識ベースにおけるハイブリッド検索 (RAG): ベクトル検索 (意味論)と全文検索 (キーワード)を相互順位融合 (RRF)で融合し、最も関連性の高いパッセージを検索します。

   • データ取得: 操作コレクション（グリッド、ネットワーク、カスタマー、関税）における MongoDB 集計により、ライブ データで応答します。

5. メモリ: 会話状態は MongoDB Atlas (agent_checkpoints, agent_checkpoint_writes) に永続化されます。そのため、外部の状態保存ストアを使用せずに、エージェントはターンを越えてコンテキストを記憶します。

6. 推論と生成 (オーケストレーション): LangGraph オーケストレーション レイヤーはループを調整し、LLM (Claude) は検索されたコンテキストを推論し、最終的な回答を統合してユーザーに返します。

まとめ: AI レイヤーはロジックを複製しません。データ検索ツールは、操作ダッシュボードの動作を支えるのと同じ集計を呼び出し、両レイヤーはデータ、検索、エージェントメモリに単一の Atlas クラスターを共有します。

データモデルアプローチ

このソリューションは、モニタリング、ネットワーク操作、予測、カスタマー インテリジェンス、およびグリッド サポート エージェントを単一のMongoDB Atlasデータ レイヤーで実行します。

MongoDB document model では、操作、検索、メモリのデータをフレキシブルなコレクションに編成することで、情報を保存、同期、調整するために別々のシステムを必要とせずに接続したままにすることで、これを可能にします。

このソリューションは、オペレーションワークロードと AI 機能の両方をサポートするために連携する MongoDB コレクションのセットにビルドされています。

• readings 時系列メーターデータを保存します。

• customer_db, network、meter_network_map、tariff_catalogは、コアとなるカスタマー、グリッド、マッピング、関税データを保存します。

• agent_checkpoints および agent_checkpoint_writes エージェントメモリを持続化します。

• kb_articles 知識ベースに対する AI 検索を強化します。

これらのコレクションは、モニタリング、分析、およびインテリジェントなユーザー操作のために、1 つの接続されたデータ レイヤーを提供します。次のセクションでは、各コレクションについて詳しく説明し、その構造がソリューション全体をどのようにサポートするかを説明します

• readings: 時系列コレクションに、間隔ごとのメーター読取値、電気測定値、アプライアンス レベルのサブロード、事前計算された間隔消費量 (interval_kwh)、およびその非正規化されたグリッド コンテキスト（フィーダー/変電所/電力会社）を保存 (する)します。

{
  "timestamp": {
    "$date": "2026-07-08T17:00:00.000Z"
  },
  "dataid": 661,
  "power_factor": 0.933,
  "city": "Austin",
  "frequency": 60.043,
  "voltage": 119.958,
  "energy": 53.76054,
  "feeder_id": "feeder_austin_south_02",
  "kitchen_power": 168.8,
  "power": 3246.151,
  "env_power": 1112.159,
  "heating_power": 344.741,
  "utility_id": "utility_austin",
  "laundry_power": 61.352,
  "current": 29.004,
  "_id": {
    "$oid": "6a760c8ee48b9c05164d7d57"
  },
  "avg_reading": 119.958,
  "interval_kwh": 0.81154,
  "ev_power": 0,
  "volt_leg_1": 118.982,
  "has_ev": true,
  "transformer_id": "transformer_austin_south_02_01",
  "hvac_power": 1559.099,
  "substation_id": "substation_austin_south",
  "volt_leg_2": 120.934,
  "state": "Texas"
}

• network: ユーティリティの階層をリンクされたドキュメントとしてモデル化します。parent_asset_id はユーティリティ → 変電所 → 配電線 → 変圧器の階層を構成し、各アセットは各自のキャパシティーとロケーションを持っています。

{
  "_id": {
    "$oid": "6a43f5a0fc0d1c3b5276bb29"
  },
  "asset_id": "transformer_austin_south_02_02",
  "asset_type": "transformer",
  "city": "Austin",
  "state": "TX",
  "name": "Austin South Transformer 02-02",
  "parent_asset_id": "feeder_austin_south_02",
  "capacity_kw": 1500,
  "voltage_kv": 0.48,
  "status": "active",
  "location": {
    "type": "Point",
    "coordinates": [
      -97.7131,
      30.263199999999998
    ]
  }
}

• tariff_catalog: 階層バンドが配列として埋め込まれた状態でレートプランを保存するため、プラン全体が 1 つのドキュメントとして読み取られます。

{
  "_id": {
    "$oid": "6a760c89e48b9c05164d7d4c"
  },
  "utilityName": "Austin Energy",
  "rateName": "Residential",
  "fixedChargeFirstMeter": 15,
  "fixedChargeUnits": "$/month",
  "energyRateStrux": [
    {
      "energyRateTiers": [
        {
          "max": 300,
          "unit": "kWh",
          "rate": 0.04106,
          "adj": 0.06455
        },
        {
          "max": 900,
          "unit": "kWh",
          "rate": 0.05138,
          "adj": 0.06455
        },
        {
          "max": 2000,
          "unit": "kWh",
          "rate": 0.07525,
          "adj": 0.06455
        },
        {
          "unit": "kWh",
          "rate": 0.10884,
          "adj": 0.06455
        }
      ]
    }
  ],
  "energyWeekdaySched": [...
  ],
  "energyWeekendSched": [...
  ],
  "effectiveDate": {
    "$date": "2025-05-01T00:00:00.000Z"
  },
  "sourceReference": "https://austinenergy.com/-/media/project/websites/shared/pdfs/rates/tariff.pdf?rev=382867d1201343b78d6a940e4ef471b5&hash=51DA5A20032359FB44C3F61BFB5E7F5E",
  "rate_type": "tiered",
  "city": "Austin",
  "state": "TX",
  "location_label": "Austin, TX"
}

• kb_articles: Atlas Vector Search (自動化された Voyage AI 埋め込み)とフルテキスト検索のインデックスを使用して、ドメイン知識ベースを保存します。埋め込みは、個別の埋め込みパイプラインなしでテキスト フィールドから Atlas によって生成されます。

{
  "_id": {
    "$oid": "6a711e3759c1cc549f2e8c42"
  },
  "slug": "what-is-power-factor",
  "category": "Glossary",
  "text": "Power factor is the ratio of real power (kW, the power that does useful work) to apparent power (kVA, the total power drawn). It ranges from 0 to 1. A power factor near 1.0 means electricity is being used efficiently; a low power factor (for example below 0.9) means a lot of reactive power is being drawn, which stresses the grid and can incur penalties for commercial customers. Motors, transformers, and other inductive loads lower the power factor.",
  "title": "What is power factor?",
  "updatedAt": {
    "$date": "2026-08-04T19:30:01.654Z"
  }
}

• meter_network_map: 各メーター（dataid）をグリッド トポロジー内の場所（フィーダー、変電所、ユーティリティ、変圧器）にマップします。同じコンテキストは各読み取りにも非正規化されるため、高頻度ビューでは結合なしで読み取ります。

• customer_db: 各カスタマーのロケーション（市と県）をメーター dataid でキー付けして保存します。料金プランと使用セグメントは、オンデマンドで（tariff_catalog から、または集計によって）導出されます。

• agent_checkpoints および agent_checkpoint_writes: LangGraph によってマネージされるエージェントメモリを保存します。ここでは、アシスタントの会話状態がスレッドによって持続的に保存されるため、ターンを超えてコンテキストが維持され、外部の状態が保存されることはありません。

document modelがこのソリューションに適している理由:

• 各リーディングには、その瞬間に関するすべての情報が含まれています: メーターリーディングは、電気測定値と電化製品レベルのサブ負荷を 1 つのドキュメントに埋め込み込みます。単一のリーディングを再構築するためのジョインは必要ありません。時系列コレクションに保存されているため、これらは高頻度で効率的に取り込み、クエリできます。

• グリッドの階層は存在するかのままモデル化されます：ネットワーク（公益事業体 → 変電所 → 配電線 → 変圧器）は、プラットフォームがトポロジービューを構築するためにウォークするリンクされたドキュメントとして保存され、各リーディングはその階層での位置を持つため、スキーマ移行なしでモデルを拡張または変更できます。

• スキーマは移行なしで進化します：新しいアプライアンスのサブロード、カスタマー属性、またはアセットフィールドを新しいフィールドとして追加できるため、既存のドキュメント、パイプライン、およびアプリケーションワークフローは、プラットフォームの拡張に伴い続続して機能します。

• 同じデータですべてのワークロードをサポート: モニタリング、予測、およびカスタマー ダッシュボードの裏で行われる集計は、グリッド モデルでのジョインをサポートする同じオペレーション コレクションで実行されます。これにより、重複が減少され、分離されたシステムが回避されます。

• AI データはオペレーションデータと共存します: 知識ベース、ベクトル検索、全文検索、およびエージェントの会話メモリはすべて同じMongoDB Atlasクラスター内に存在するため、取得、推論コンテキスト、およびオペレーション分析は分離されたインフラストラクチャなしで連携して機能します。

ソリューションのビルド

Smart Grid Intelligent Platform は、MongoDB Atlas をリアルタイム モニタリング、ネットワーク操作、需要予測、カスタマー インテリジェンス、およびグリッド サポート エージェントの単一のデータ レイヤーとして使用します。

このソリューションを配置するには、次の高レベルの手順に従ってください。詳細な設定手順、サンプルデータ、実行可能なコードについては、GitHub リポジトリを参照してください。

キーポイント

• 単一のデータプラットフォームで操作を統合する: モニタリング、ネットワーク操作、予測、カスタマーインテリジェンスを1つのMongoDB Atlasクラスターで実行すると、別々のシステム間でメーターデータをコピーして照合するコストと遅延がなくなります。このアプローチにより、総所有コストが低減され、新しい機能をより迅速に本番環境に導入できます。

• 生のメーターデータを操作上の決定に変換する: 集計パイプラインで算出された停止時間、キャパシティー使用率、および異常により、演算子はグリッド状況に対してリアルタイムで実行できます。これにより停止時間が短縮され、過負荷が連鎖的な障害に発展することを防止できます。

• 気象を考慮した予測によるキャパシティー計画: 外部の気象データ (暖房度日、冷房度日など) を使用して需要予測を強化し、電力会社がピークを予測し、キャパシティーを先手的に割り当てるのに役立てます。これにより、高コストの緊急対応が減少され、グリッドの信頼性が向上します。

• 統合されたインテリジェンスでカスタマーの成果を向上させる: 同じメーター データから料金の推奨、消費傾向、および使用セグメントを提供します。これにより、公益事業者はカスタマーに関連するパーソナライズされたガイダンスを提供し、エンゲージメントを促します。これは満足度と定着率をサポートします。

• MongoDB でエージェント AI を使用してチームの生産性を向上させる: ランググラフのマルチエージェントアシスタントを使用して、あらゆる演算子がグリッド、ネットワーク、カスタマーに対して自然言語でクエリを実行できるようにします。これにより、データへのアクセスが民主化され、専門レポートやアナリストを待つ必要がなくなり、意思決定が迅速化されます。

作成者

• Muhammad Atif

• Andrea Fatima Figueroa Lopez

• Maria José Cordova Igartua

• Javier Guajardo Canseco

• Andrea Alaman Calderon

詳細

• Atlas Vector Search.

• Atlas Vector Search による検索拡張生成（RAG）

• 製造業とモビリティ。