Amazon Web Services ブログ
Amazon Bedrock を活用した太陽光発電データの異常検知・分析システムの構築事例
本ブログは、株式会社エナリス 星野 友宏 氏、KDDI アジャイル開発センター株式会社 御田 稔 氏、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 安藤 が共同で執筆しました。
みなさん、こんにちは。AWS ソリューションアーキテクトの安藤です。
電力分野、特に再生可能エネルギーの普及が進む中で、正確な発電予測は電力系統の安定運用に欠かせません。今回は、株式会社エナリス（以下、エナリス）と KDDI アジャイル開発センター株式会社（以下、KAG）が共同で取り組む、太陽光発電データの異常検知システムについてご紹介します。このシステムは生成 AI の活用と人間の知見を組み合わせた HCAI（Human-Centered AI）アプローチを採用しており、Amazon Bedrock を中心としたアーキテクチャで構築されています。HCAI は、人間の能力を置き換えるのではなく増強・拡張する AI システムの構築を目指す新しい分野で、透明性、公平性、プライバシーを重視し、特に重要な意思決定では人間が主導権を保持することを重視しています。今回のシステムでは、AI の出力結果を別の AI が評価し、最終的に人間がフィードバックすることで AI の精度を継続的に向上させるアプローチを実現しています。
導入背景
電力は貯蔵が困難なエネルギーであり、供給と需要を常にバランスさせる必要があります。特に太陽光発電などの再生可能エネルギーは気象状態に依存して変動するため、正確な発電量予測は電力系統の安定運用において重要な要素です。エナリスは電力需給管理業務を創業事業とし、早くから AI を活用した発電量予測に取り組んできました。同社では Amazon SageMaker AI で構築した独自の AI モデルを用いて、時系列予測による太陽光発電量予測を行っています。 しかし、天候急変、災害、設備故障など予測困難な要素により、実績値と予測値に大きな乖離が生じるケースが発生していました。このような異常値が検出された場合、データ欠損の確認や原因分析を人手でチェックする必要があり、相応の工数を要することや、属人化が課題となっていました。
これらの課題解決に向けて生成 AI の活用を検討する中で、「ハルシネーション」や判断根拠の不透明性といった課題が浮上しました。社会インフラを支えるエネルギー分野では AI の出力結果に対する信頼性と説明可能性が重要であり、慎重なアプローチが求められていました。
ソリューション：HCAI による異常検知システム
エナリスと KAG は、AI の能力を活用しながらも人間の判断を重視する HCAI（Human-Centered AI）アプローチに着目し、AI の出力結果を別の AI が分析・評価し、それをさらに人間が評価して改善指示するサイクルを回す異常検知システムの構築に着手しました。このアプローチにより、AI の精度を継続的に向上させながら、安心して活用できるシステムの実現を目指しています。
システムアーキテクチャの変遷と特徴要素
【ステップ 1：Amazon Bedrock API（Claude）ベースのシンプルシステム】
最初に構築したシステムは、Amazon Bedrock の Claude モデルを使用して実績/予測データを分析し、異常の有無を判定してテキストとして画面に出力する Web アプリケーションでした。システム構成は、フロントエンドに Vue.js on AWS Amplify（Gen 2）、バックエンドに AWS Lambda を使用しています。
このステップでは、データ処理の基盤として以下の Lambda を構築しています：
- 乖離検知 Lambda: 実績発電データと予測発電データを比較して乖離を検知
- 異常検知 Lambda: 予測発電データとマスターデータを使用して異常を検知
これらの Lambda で検知された結果は Amazon Redshift Serverless に格納されます。Amazon Bedrock は、このデータを元に異常の原因分析や対応策の提案を行います。データ取得には Amazon Bedrock Knowledge Base の Text-to-SQL 機能を使用し、Amazon Redshift Serverless に格納された検知結果から必要なレコードのみを自然言語から SQL で取得しています。一般的なベクトル検索の RAG（Retrieval Augmented Generation）で処理するとデータが断片化されてしまうため、構造化データは SQL で直接取得する方針を採用しました。
アーキテクチャ図_ステップ1
このような構成で開始しましたが、大量の元データを効率よく処理する方法や、Web 情報など外部の情報をいかに取り込むか、また複数のエージェントを協調させる方法といった課題がありました。
【ステップ 2：Amazon Bedrock Agents マルチエージェントコラボレーション】
ステップ 1 の課題を解決するため、Amazon Bedrock Agents を用いて大幅にアーキテクチャを改良しました。Amazon Bedrock Agents は、自律的な AI エージェントを構築・設定できるサービスです。今回は Amazon Bedrock Agents のマルチエージェントコラボレーションを活用して、複数のエージェントが協調して動作する構成を実装しました。
ステップ 1 で構築した乖離検知・異常検知 Lambda から Amazon Redshift Serverless へのデータ格納までの基盤はそのまま活用し、このステップではマルチエージェントシステムを構築しました。
各エージェントの役割は以下のとおりです。
監督者エージェント：スーパーバイザーエージェントとして機能し、各サブエージェントの結果を取りまとめます。またツールとしては当該地点の天候情報などを取得する Lambda function を構築し、Amazon Bedrock Agents のアクショングループに紐付けました。
検知結果取得エージェント：ステップ 1 で実装した Amazon Bedrock Knowledge Base の Text-to-SQL 機能を活用して、Amazon Redshift Serverless に格納された検知結果から必要なレコードのみを自然言語から SQL で取得します。
過去ナレッジ検索エージェント：こちらは Amazon S3 と Amazon OpenSearch Serverless を組み合わせた Knowledge Base のベクトル検索で社内のナレッジドキュメントを検索し、どういった場合にどのような有人対応が必要となるかのアドバイスをユーザーに提示します。過去の対応策が記載されたファイルを Amazon S3 に格納し、Amazon OpenSearch Serverless をベクターストアとして活用しています。
システムの実際の動作フローは以下のとおりです。ユーザーが入力した日付の分析結果ファイルを検索し、ファイルが存在しない場合は監督者エージェントを起動して分析用コンテキストを収集します。この際、外部の気象情報を取得して天候特徴を抽出し、これらのコンテキストを利用して LLM が分析結果ファイルを出力します。一方、分析結果ファイルが既に存在する場合は、そのファイル内容を取得してフロントエンドに連携します。
また、LLM-as-a-Judge 機能を実装し、分析結果の確からしさを LLM 自身に評価させてランク付けして画面に表示することにより、ユーザーがどこを疑って見るべきかの示唆を与えます。LLM-as-a-Judge とは、LLM 自身が生成した結果の品質や信頼性を評価する手法で、今回は RAG システムの品質を定量的に評価するためのオープンソースフレームワークである RAGAS を活用しています。
アーキテクチャ図_ステップ2
【ステップ 3（現在）：AWS Step Functions ワークフロー】
ステップ 2 の運用を進める中で、「AI が過度に汎化して評価の精度が低下する」という課題が判明しました。そこで RAGAS の評価精度を向上させるため、評価対象の処理区間や中間データを扱いやすいよう、Amazon Bedrock Agents を使用せずに AWS Step Functions で AWS Lambda を直接制御するカスタムワークフローに変更しました。AWS Step Functions は、分散アプリケーションのワークフローを視覚的に構築・管理するサービスです。
ステップ 2 で実現した各種情報収集機能（天候情報取得、検知結果取得、過去ナレッジ検索）を基盤として活用し、AWS Step Functions で AWS Lambda を直接制御するカスタムワークフローで以下の情報収集・評価 Lambda を順次実行します。
- 異常乖離検知結果取得 Lambda: Amazon Bedrock Knowledge Base の Text-to-SQL 機能で Amazon Redshift Serverless に格納された検知結果を取得し、そのデータを元に Amazon Bedrock が生成した分析結果を RAGAS で評価して Amazon DynamoDB に保存します。
- 当時の天候情報取得 Lambda: Tavily Search API で天候情報を取得し、Amazon S3 のマスターデータからデバイスの位置情報を取得し、これらをコンテキストとして Amazon Bedrock で異常値の発生原因を分析し、RAGAS で評価して Amazon DynamoDB に保存します。
- 対応策取得 Lambda: Amazon S3 と Amazon OpenSearch Serverless を組み合わせたベクター検索で過去のナレッジを取得し、RAGAS で評価して Amazon DynamoDB に保存します。
- 分析レポート作成: 上記 3 つの Lambda から収集した情報を統合し、AWS Lambda と Amazon Bedrock で総合的な分析レポートを作成し、Amazon S3 に格納します。
最終的に、Amazon S3 に保存された分析結果と Amazon DynamoDB に保存された RAGAS 評価結果を組み合わせてフロントエンドに出力します。AWS Step Functions への変更により、各処理段階をより細かく制御できるようになり、中間データの可視化やデバッグ性も向上しました。
また、HCAI アプローチの核心である人間のフィードバックループも実装しています。ユーザーは出力された分析情報を確認し、対応を決定して、その対応結果を入力します。この対応結果は過去の対応策ファイルとして Amazon S3 に格納され、上述した対応策取得 Lambda で活用される継続的な学習サイクルを形成しています。
アーキテクチャ図_ステップ3
システムアーキテクチャの継続的な改善として、ベクターストアの選択についても検討を進めています。現在はAmazon OpenSearch Serverless を使用していますが、よりコスト最適化できる選択肢として 2025 年 12 月に一般提供が開始された Amazon S3 Vectors を検討しています。Amazon S3 Vectors は S3 バケット内でベクターデータを直接格納・検索できる新機能で、従来のベクターデータベースと比較してコスト効率に優れており、大規模な過去ナレッジデータの管理において運用コストの削減が期待できます。
システムの実行結果
以下は、実際にシステムを動作させた際の画面例です。異常検知の結果とLLM-as-a-Judge 機能による評価結果が統合されたダッシュボードで確認できます。左側には検知された異常データの詳細（デバイス ID、時刻、実績値、予測値、誤差率など）が表示され、右側には異常値分析と乖離値分析それぞれについて A〜C 評価とスコアが表示されます。
また、RAGAS 評価の詳細画面では、忠実度、コンテキスト精度、回答関連性などの各評価指標について、重要度とスコアが可視化されており、ユーザーは分析結果のどの部分を重点的に確認すべきかを把握できます。RAGAS 評価では、各 Lambda がそれぞれ異なる質問（異常値抽出、対応策検討、原因分析）を LLM に 2 回投げ、1 回目の回答を Ground Truth（想定回答）とし、2 回目の回答と比較することで評価を実施しています。通常、RAGAS 評価では人間が作成した正解データを Ground Truth として使用しますが、太陽光発電異常分析のような専門性の高い領域では、事前に決まりきった正解を用意することが困難なため、LLM 自身に Ground Truth を生成させる手法を採用しました。これにより、コンテキスト精度（適切な資料を取得できたか）、忠実度（取得した情報に基づいて回答しているか）、回答関連性（質問に適切に答えているか）などの指標を定量的に測定し、RAG システムの検索精度と生成品質を客観的に評価できています。なお、最終的な品質保証は人間による確認と組み合わせることで信頼性を担保しています。
システム画面 1
システム画面 2
期待される効果と今後の展望
このシステムの導入によって、以下の効果が期待できます。
- 人間のフィードバックを継続的に学習データに反映することで、太陽光発電量の予測精度を段階的に改善
- 従来の手作業による調査・分析作業を、AI が AI を評価する仕組み（LLM-as-a-Judge）の活用により迅速化・効率化し、異常原因の特定時間を短縮
- HCAI アプローチにより AI 出力の信頼性を可視化し、エネルギー分野での生成 AI 活用を促進
- 予測精度向上により電力需給のミスマッチを削減し、インバランス料金の発生を抑制
現在は PoC（概念実証）環境の構築が完了し、チューニングのフェーズに入っています。今後の本格運用を視野に入れていますが、現状では、取り込むコンテキスト量の問題や、LLM の API 利用における処理速度や回数の制約といった大量データ処理の困難さ、また、電力データ自体がリアルタイムで取得できないことによるリアルタイム処理の難しさといった技術的課題が残っています。そのため、まずはこれらの課題解決を優先し、少数のデバイスデータを選定運用することから始めます。この最小構成での運用を通じてシステムの精度向上を図り、その上で将来的な本格運用を検討していく予定です。
また、今回のフィールドは太陽光発電量予測ですが、今後はこの HCAI アプローチを、エナリスが推進する電力マネジメントサービスの品質を下支えする仕組みとして横断的に活用していきます。具体的には、創業以来の強みである需給管理業務に関連する発電量や需要量の予測精度向上をサポートするとともに、企業の CO2 排出量削減や再エネ導入を多角的に支援する脱炭素ソリューションをはじめとする自社の多様なサービスへ横展開し、事業全体の高度化を図っていくことを目指しています。
まとめ
エナリスと KAG による本取り組みは、エネルギー分野における生成 AI の実用化に向けた重要な一歩です。特に、AI の出力結果を別の AI が評価し、最終的に人間がフィードバックする HCAI のアプローチは、生成 AI の信頼性向上と実用化の両立を目指す取り組みといえます。 ステップ 1 のシンプルな Amazon Bedrock API ベースのシステムから、ステップ 2 のマルチエージェントシステム、そしてステップ 3 の AWS Step Functions ワークフローへと、実際の運用から得られた知見に基づいて段階的に進化させてきた過程は、多くの企業にとって参考になるでしょう。今後の展開と成果に注目していきたいと思います。
著者
 |
星野 友宏 株式会社エナリス 事業企画本部 みらい研究所 技術開発部門 |
 |
御田 稔 KDDI アジャイル開発センター株式会社 テックエバンジェリスト |
 |
安藤 麻衣 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部
|