世界の電力・再エネAPI/MCP/AIエージェント事例42選：エネルギー事業は「APIで売る」時代に入った
はじめに：電力会社のDXは「アプリ化」ではなく「API化」で決まる
電力会社、ガス会社、再エネ会社、脱炭素スタートアップのデジタル化を見ていると、勝ち筋はかなりはっきりしている。
それは、単にWebアプリを作ることではない。電力データ、料金データ、排出係数、需要家データ、系統データ、DR制御、経済効果シミュレーションを、APIとして外部システムやAIエージェントから呼び出せる状態にすることだ。
欧米、豪州、北欧では、すでにこの流れがかなり進んでいる。
英国のOctopus EnergyはKraken APIをGraphQL/RESTで公開し、英国のNESOやElexonは電力需給・市場データをAPI化している。欧州ではENTSO-E Transparency Platform、Nord Pool、EPEX SPOT、SMARD、Elia、Fingrid、Energinetなどが、開発者や市場参加者向けに電力データのプログラマブルアクセスを提供している。豪州ではAEMO、OpenElectricity、Amber Electric、Wattwatchersが、NEM/WEM、動的料金、需要家データ、IoTメーターデータをAPIで扱えるようにしている。([Octopus Energy Docs][1])
一方で、MCP、つまりModel Context Protocolはまだ黎明期だ。MCPは、LLMやAIエージェントが外部データ・ツール・アプリケーションとやり取りするためのオープン標準として位置づけられており、Anthropicが2024年11月に導入したものとして解説されている。電力会社自身が公式MCPサーバーを広く提供する段階にはまだ達していないが、ENTSO-E、EnergyPlus、エネルギーインフラ制御などを対象にしたコミュニティMCPや研究実装は出始めている。([Google Cloud][2])
この記事では、世界の電力・ガス・再エネ・脱炭素API事例を 42件 に分解し、日本のエンジニア、PdM、エネルギー事業のサービス開発責任者向けに、何を学ぶべきかを整理する。
この記事の主張はシンプルだ。
エネルギー事業の次の競争軸は「発電量」や「料金メニュー」だけではない。
データをどうAPI化し、AIエージェントが意思決定に使える形へ変換できるかで決まる。
そして日本では、電力市場データを取得するAPIだけでなく、太陽光・蓄電池・EV/V2H・PPA・電気料金・補助金条件をもとに、経済効果や提案資料へ変換する“試算API” が重要になる。ここで、エネがえるAPIのような再エネ経済効果シミュレーションAPIは、海外API事例でいう「データ取得API」の次に来る、Decision API のレイヤーとして位置づけられる。
この記事で扱うAPIの分類
この記事では、APIをざっくり5層に分ける。
| レイヤー | 何をAPI化するか | 主なプレイヤー | 日本での示唆 |
|---|---|---|---|
| Grid / Market Data API | 需給、価格、発電、送電、卸市場、需給調整 | ENTSO-E、Elexon、NESO、AEMO、Nord Pool、SMARD | 電力市場・需給・出力制御・DR予測の基盤 |
| Customer / Utility Data API | 需要家の電気・ガス使用量、請求、メーター | UtilityAPI、Arcadia、Green Button、Wattwatchers | 需要家同意ベースの診断・提案自動化 |
| Carbon / Emissions API | CO2排出係数、限界排出係数、電源構成 | WattTime、Electricity Maps、Ember、UK Carbon Intensity | 脱炭素KPI、24/7 CFE、DR制御に接続 |
| Retail / Tariff / DER API | 動的料金、家庭・事業所エネルギー、DER連携 | Octopus、Tibber、Amber、nemy | 電気料金最適化、EV充電、蓄電池制御 |
| Simulation / Agent API | 経済効果、PPA、蓄電池、EV/V2H、AIエージェント | EnergyPlus-MCP、DEWA Rammas、エネがえるAPI | 試算、稟議、提案生成、AI営業支援 |
大事なのは、APIの価値は「データを返すこと」だけではないという点だ。
データを返すだけなら、CSVダウンロードの少し便利な版で終わる。事業価値が出るのは、APIが 判断・制御・提案・契約・収益化 に接続されたときである。
42事例マップ：世界の電力・再エネAPI/MCP/AIエージェント
1. Octopus Energy / Kraken API：小売電力をGraphQL化した象徴例
Octopus EnergyのKraken APIは、RESTとGraphQLを含むAPI群として公開されており、Octopus Energyの開発者向けドキュメントではAPIサイトと認証サーバーが明示されている。米国向けドキュメントにもGraphQLとRESTのセクションが存在し、日本向けKraken系APIを扱うサンプル実装ではGraphQLエンドポイントを利用する例も確認できる。([Octopus Energy Docs][1])
PdM視点の学び
Octopusが面白いのは、「電力小売の業務」をSaaS/APIプラットフォーム化している点だ。単なる請求APIではなく、料金、顧客、メーター、契約、需給、顧客体験を統合する中核OSに近い。
日本で再エネ・蓄電池・EV/V2H提案をAPI化する場合も、単発の計算APIでは弱い。
本当に価値が出るのは、料金プラン、設備、需要データ、補助金、PPA条件、レポート出力までを一つの流れにすること。エネがえるAPIが担える領域も、まさにこの「提案・試算業務の中核OS」側にある。
エネがえる共通 公開用 API https://www-apidoc.enegaeru.com/sys/
2. NESO Data Portal API：英国の電力システムデータをSQL的に扱う
英国のNESO Data Portalは、GUIでデータを眺めるだけでなく、データポータルAPIを使ってプログラムからアクセスできる。公式ガイダンスでは、APIはUIからのダウンロードではなく、プログラムとSQLの知識を前提にしたアクセス手段として説明されている。([National Energy System Operator (NESO)][3])
PdM視点の学び
良いデータポータルは、きれいなグラフを出すだけでは足りない。
開発者がデータを取り、モデルへ渡し、予測し、業務アプリへ組み込めることが重要になる。
日本で言えば、JEPX価格、需給、再エネ出力制御、エリア予備率、需要家負荷データをAPIで取れるだけでなく、提案現場が使える判断に変換するレイヤーが必要だ。
3. Elexon Insights API：英国バランシング市場データの開発者向けAPI
Elexon Insights APIは、APIエンドポイントを開発者やデータ利用者が発見・利用できるセルフサービス領域として公開されている。ElexonのAPIは、英国の電力バランシング、需給、市場情報を扱うデータ利用者にとって重要な基盤になっている。([Elexon BMRS][4])
PdM視点の学び
Elexon型のAPIは、エネルギーSaaSの「市場データインフラ」になる。
たとえば蓄電池の収益性、DR参加、需給調整市場、PPA価格設計のアプリケーションは、こうした市場データAPIを基盤に作られる。
4. UK Carbon Intensity API：炭素強度をAPIで返す公共インフラ
英国のCarbon Intensity APIは、OpenAPI仕様でエンドポイント、モデル、サンプルが公開されている。電力の炭素強度をアプリやサービスから利用できる形にした代表例だ。([カーボンインテンシティ][5])
PdM視点の学び
脱炭素SaaSでは、「CO2を計算する」だけでなく、いつ電気を使うと排出が低いかをAPIで返せることが価値になる。
EV充電、蓄電池充放電、ヒートポンプ運用、工場の生産タイミング最適化に直結する。
5. National Gas Transmission Data Portal API：ガスもREST API化する
英国National Gas TransmissionのData Portal APIは、公開データへREST APIでアクセスできる仕組みで、多くのデータ項目について5年分のローリング履歴を提供すると説明されている。([National Gas Transmission][6])
PdM視点の学び
電力だけを見ていると、脱炭素の意思決定は歪む。ガス需要、熱需要、電化余地、ヒートポンプ導入、ボイラー更新をAPIで接続して初めて、GX提案の全体像が見える。
6. ENTSO-E Transparency Platform API：欧州電力データの巨大標準
ENTSO-E Transparency Platformは、欧州各国の電力需給、発電、送電、価格などを扱う巨大データ基盤だ。RESTful APIやAPI利用のためのガイド、Postman Collectionが存在し、2025年11月更新の参照資料も公開されている。([Postman][7])
Pythonクライアントのentsoe-pyも存在し、ENTSO-E APIからデータを取得する開発者に広く使われている。([GitHub][8])
PdM視点の学び
ENTSO-Eは、電力APIの「公共データ基盤」として強い。
ただし、公共データAPIはそのままでは顧客価値になりにくい。日本のPdMが見るべきは、「このデータを使って何を判断させるか」だ。
7. EPEX SPOT / EEX API：市場データは有償APIビジネスになる
EPEX SPOTは市場データサービスを提供し、契約ベースでMATS APIやM7 APIなどのリアルタイム市場データAPIを提供している。公開資料では、日中・前日市場の読み取り専用APIや、対象市場エリアが整理されている。EEX側でもガススポット市場データ向けのCloud Stream APIが提供されている。([EPEX SPOT][9])
PdM視点の学び
市場データは無料公開だけでなく、有償APIとして成立する。
この発想は日本の電力・再エネ事業者にも刺さる。たとえば、JEPX価格、FIP、出力制御、インバランス、蓄電池収益性、PPA価格設計を組み合わせたAPIは、単なるデータ販売ではなく、事業判断の部品として売れる。
8. Elia Open Data API：送電会社データを自動でAPI化するポータル設計
ベルギーのEliaは、グリッドデータを一つのプラットフォームに集約し、APIからアクセスできるようにしている。OpendatasoftベースのExplore API v2を使い、データの説明、表、チャート、ダウンロード、APIアクセスを自動的に扱える設計になっている。([Elia][10])
PdM視点の学び
データポータルの本質は、見た目ではない。
データセットの説明、検索性、API、可視化、ライセンス、更新性が揃って初めて、外部開発者が使える。
9. RTE éCO2mix：フランスの電力データをリアルタイム可視化・公開
フランスのRTEは、éCO2mixで電力消費、発電、CO2排出、商業取引などのデータをリアルタイムおよび履歴で公開している。データは全国・地域単位、30分値などで扱われる。([RTE France][11])
PdM視点の学び
リアルタイム電力データは、一般向けアプリにも専門家向け分析にも使える。
日本でも、系統混雑、出力制御、需給逼迫、CO2排出を需要家の行動に結びつける余地は大きい。
10. SMARD / BundesAPI：ドイツ電力市場データのAPIアクセス
ドイツのSMARDは、電力市場データを無料で公開し、CC BY 4.0で利用できる。非公式または周辺的なAPIドキュメントとしてBundesAPIもあり、Bundesnetzagenturの電力市場データへGETリクエストでアクセスする方法が整理されている。([SMARD][12])
PdM視点の学び
ドイツ型の学びは、データのライセンスと再利用性だ。
データが公開されても、商用利用・再配布・引用条件が曖昧だと、プロダクトに組み込みにくい。
11. Fraunhofer Energy-Charts API：研究機関データが産業アプリへ接続する
Fraunhofer ISEのEnergy-Chartsは、欧州・ドイツの電力データを可視化・公開しており、OpenAPI仕様も存在する。Energy-Chartsのデータは、家電メーカーのアプリなど産業用途への応用例も紹介されている。([Energy-Charts API][13])
PdM視点の学び
研究機関のデータは、論文やグラフで終わらせるには惜しい。
API化されると、家電、HEMS、EV、蓄電池、DR、エネルギーマネジメントアプリの信号になる。
12. Fingrid Open Data API：フィンランドの系統データAPI
フィンランドのFingridはOpen Data APIを提供しており、REST API、登録、APIキー、機械可読形式のデータ公開を前提にしている。実測データや予測データも含まれる。([Fingrid Avoin Data][14])
PdM視点の学び
北欧の強さは、単に再エネ比率が高いことではない。
系統運用データを開発者が扱える形で出し、アプリケーション層を育てている点にある。
13. Energinet Energi Data Service：デンマークの電力・ガス・環境データAPI
デンマークEnerginetのEnergi Data Serviceは、電力、補助サービス、電力市場、環境、ガスなどのカテゴリーを持ち、APIでデータを取得できる。公式ガイドでは、無料API、ベストプラクティス、制限事項も説明されている。([Energinet][15])
PdM視点の学び
電力APIとガスAPIを分けず、エネルギーデータ基盤として統合する発想が重要だ。
脱炭素は、電力だけでは完結しない。
14. Nord Pool Data API v2：市場取引データをAPI商品化する北欧モデル
Nord PoolはData API v2をOpenAPI 3.0形式で提供し、オークション、価格曲線、バランス市場、電力システム、為替、インタラデイ、システムデータなどを扱っている。2024年にはMarket Data API v1の終了とv2への移行案内、新エンドポイント追加も公開されていた。([Nord Pool Data][16])
PdM視点の学び
APIは作って終わりではない。
バージョン移行、廃止告知、互換性、ドキュメント更新まで含めてプロダクトである。
15. Tibber GraphQL API：家庭向け電力サービスのGraphQL活用
Tibberは家庭向けエネルギーサービスとしてGraphQL APIやAPI Explorerを公開している。GraphQLスキーマ参照も自動生成されており、家庭の電力データやスマート機器連携に向いた開発者体験が設計されている。([Tibber Developer][17])
PdM視点の学び
家庭向けエネルギーSaaSでは、RESTよりGraphQLが向くケースがある。
顧客、契約、メーター、デバイス、価格、使用量の関係が複雑だからだ。
16. Statnett Download Center：ノルウェーの電力バランス・流量・発電消費データ
ノルウェーのStatnettは、電力バランス、フロー、発電・消費、輸出入、予備力などのデータをダウンロードできるセンターを提供している。([Statnett][18])
PdM視点の学び
北欧は「市場」「系統」「需要」のデータ公開が厚い。
日本のエネルギーSaaSが学ぶべきは、データ粒度そのものより、データを業務アプリへ繋げる設計だ。
17. eSett Open Data：北欧電力市場の参加者・構造データ
eSettは、電力市場や市場参加者に関する構造データを機械可読形式で提供するOpen Dataプラットフォームを持つ。([eSett][19])
PdM視点の学び
市場参加者データは地味だが、プロダクト設計では重要だ。
誰が発電し、誰が小売し、誰がバランシング責任を持つかが分からないと、取引や契約の自動化は難しい。
18. PSE Raporty：ポーランドの電力システムデータ公開
ポーランドのPSEは、Raporty PSEでシステムデータや市場データを公開している。ピーク時間、負荷、市場価格、インバランスエネルギーなどのデータを扱う。([Polskie Sieci Elektroenergetyczne][20])
PdM視点の学び
東欧でも、電力データの公開・可視化は進んでいる。
API成熟度は地域差があるが、データ公開を前提とした市場透明性の方向は共通している。
19. Ukrenergo / Ukraine Energy Map：戦時下でも電力データは公開される
ウクライナでは、電力輸出入などの時間別データが公開されており、2022年以降はウクライナ系統がENTSO-E系統と同期した単一取引ゾーンとして扱われている。Ukrenergoは2024年1月1日にENTSO-Eの正式メンバーになったと欧州委員会も発表している。([map.ua-energy.org][21])
PdM視点の学び
電力データは平時だけのものではない。
レジリエンス、防災、BCP、国際連系、地政学リスクに接続する。
20. UtilityAPI / Green Button：需要家データを同意ベースで取得する米国モデル
UtilityAPIは、Green Button標準に基づく電力・ガス等の顧客使用量・請求データ共有を支援する。Green ButtonはREST API、XML、OAuthなどを用いて、顧客の同意に基づきユーティリティデータへアクセスする仕組みとして説明されている。Consumers Energyでも、Green Button Connect My DataとUtilityAPIを使った顧客データリクエスト基盤が紹介されている。([UtilityAPI][22])
PdM視点の学び
ここは日本にとって非常に重要だ。
電気料金削減、太陽光・蓄電池・EV提案、PPA、デマンドレスポンスの入口は、結局「需要家データをどう安全に取得するか」で決まる。
日本でこの領域が標準化されれば、エネがえるAPIのようなシミュレーションAPIに需要データを渡し、投資回収・料金削減・CO2削減・PPA条件比較を自動化できる。
エネがえる共通 公開用 API https://www-apidoc.enegaeru.com/sys/
21. Arcadia Plug API：世界中のユーティリティデータ取得をAPI化する
ArcadiaのPlug APIは、電力会社や公共料金データへプログラムからアクセスするためのAPIで、世界50か国以上、数千のプロバイダーから自動化されたユーティリティデータ取得を提供すると説明されている。([Arcadia][23])
PdM視点の学び
Arcadia型のモデルは、ユーティリティデータ取得を「インフラAPI」として商品化している。
日本でも、需要家の請求書・デマンドデータ・検針データ・料金プラン情報をAPIで取得できる基盤があれば、再エネ提案の生産性は一段変わる。
22. WattTime API：限界排出係数をAPIで返す
WattTimeは、リアルタイム、予測、履歴のグリッドデータを世界規模で提供し、限界排出係数であるMOERを扱う。MOERは、ある時点の負荷変化に応答する発電機の排出率を表す指標として説明されている。([WattTime][24])
PdM視点の学び
脱炭素では、平均排出係数と限界排出係数を混同すると判断を誤る。
EV充電や蓄電池制御では、「この時間に1kWh増減したら、どの電源が反応するか」が重要になる。
23. Electricity Maps API：電源構成・炭素強度をグローバルAPI化する
Electricity Maps APIは、リアルタイムおよび将来予測の電力ミックス、炭素強度データを提供する。past、latest、forecast のような用途別エンドポイントがある。([Electricity Maps][25])
PdM視点の学び
電力のCO2を扱うプロダクトは、国境を越える。
多国籍企業、データセンター、サプライチェーン、24/7 CFEでは、地域別・時間別の電力排出データが必要になる。
24. EIA Open Data API：米国政府のエネルギーデータAPI
米国EIAは、エネルギーデータをAPIで公開しており、時系列データやカテゴリー別のエネルギーデータへアクセスできる。([U.S. エネルギー情報局][26])
PdM視点の学び
政府統計APIは、商用プロダクトの裏側で効く。
価格、燃料、需給、発電構成、州別比較、政策分析の土台になる。
25. Grid Status API：米国電力データを開発者向けに束ねるスタートアップ型API
Grid Statusは、エネルギーデータへアクセスするAPIプロダクトを提供している。電力市場・系統データをアプリケーションに組み込む開発者向けのAPIとして位置づけられる。([グリッドステータス][27])
PdM視点の学び
公的データがある国でも、スタートアップが「使いやすいAPI」として再パッケージ化する余地がある。
これは日本でも成立し得る。
26. AEMO APIs / NEMWEB：豪州電力・ガス市場データの中核
AEMOは豪州の電力・ガスシステムと市場を運営し、開発者向けポータルでAPIアクセス、ペイロード、業務ルール、認証方法、認定などの情報を提供している。NEMWEBやNEMデータには、補助サービス、計量、ネットワーク、精算、MMSデータフィードなどが含まれる。([AEMO APIs][28])
PdM視点の学び
豪州は、電力市場APIとDER・蓄電池・動的料金の接続が面白い。
市場データと需要家制御が近い。
27. OpenElectricity API：豪州の電力データをAPI・Python・TypeScriptで提供
OpenElectricityは、豪州の電力データを可視化・追跡するプラットフォームで、リアルタイム発電、需要、価格、履歴データをAPIで提供している。公式クライアントとしてPythonとTypeScriptも用意されている。([Open Electricity Documentation][29])
PdM視点の学び
APIだけでなく、SDKがあると採用速度が上がる。
Qiita読者向けに言えば、「pip installで試せる」は強い。
28. Amber Electric API：動的料金を家庭・蓄電池・EV制御へつなぐ
Amber Electricは、公式REST APIとOpenAPIドキュメントを提供し、価格、予測、使用量データを扱える。APIトークンはWebアプリで作成し、利用にはアクティブなアカウントが必要と説明されている。([Amber Electric][30])
PdM視点の学び
動的料金APIは、単なる料金表示ではない。
蓄電池をいつ充電するか、EVをいつ充電するか、家庭が市場とどう接続するかの制御信号になる。
29. Wattwatchers API：IoTメーターデータをAPI化する豪州モデル
Wattwatchersは、API v3を提供し、開発者・パートナーがメーターデータやエネルギーデータを利用できるようにしている。2025年にはOpenAPI仕様の追加も発表されている。([Wattwatchers Docs][31])
PdM視点の学び
需要家データは、スマートメーターだけでなく、IoTメーターや分電盤データからも取れる。
B2Bのエネルギー提案では、この粒度が営業生産性を左右する。
30. nemy API：再エネが豊富な時間へ需要を寄せるB2B API
nemyは、豪州AEMO NEMWEBのスポット価格・市場データと連携し、使用量を再エネが豊富な時間へ寄せるためのB2B APIを提供している。([Nemy][32])
PdM視点の学び
脱炭素は、設備を入れるだけではない。
需要を動かす、時間をずらす、再エネが多い時間へ寄せる。これがAPIでできるようになる。
31. New Zealand Electricity Authority APIs：ICP・リアルタイムディスパッチAPI
ニュージーランドのElectricity Authorityは、ICP APIやリアルタイムディスパッチAPIなどを公開し、GitHubやデータセット、ツール群も提供している。([Electricity Authority][33])
PdM視点の学び
電力システムAPIは、卸市場だけではなく、接続点・需要家・ディスパッチデータまで広がる。
日本でも、地点・契約・設備・負荷をどう結びつけるかが重要になる。
32. DEWA Rammas：中東のAIエージェント型ユーティリティ事例
ドバイのDEWAは、AIとChatGPTに支えられた仮想職員Rammasを活用し、発電、送配電、顧客サービスなど複数領域にサービスを広げている。2025年の発表では、AIエージェントやコンピューター利用型エージェントにも言及されている。DEWAはDubai Pulse経由で公開APIデータも提供している。([ディワ][34])
PdM視点の学び
AIエージェントはチャットボットではない。
本質は、社内外の業務データ、運用データ、顧客接点をつなぐ「実行インターフェース」になることだ。
33. Saudi Energy Open Data：中東のエネルギーデータ公開
サウジアラビアでは、エネルギー関連のオープンデータが政府プラットフォーム経由で提供されており、電力関連データも検索できる。サウジエネルギー省は2026年2月更新のオープンデータハブ戦略も公開している。([السعودية للطاقة][35])
PdM視点の学び
中東では、巨大なエネルギー産業と政府主導のデータ公開が結びつく。
APIプロダクトとしてはまだ欧州・豪州ほど開発者体験が厚くない領域もあるが、国家戦略としてのデータ基盤化は進んでいる。
34. SP Group / SP Digital GET Insights：シンガポールのユーティリティ×EMS
SP Groupはシンガポールの電力・ガス送配電を所有・運用し、アジア太平洋のユーティリティ事業者として約170万顧客へサービスを提供している。SP DigitalのGET Insightsは、エネルギー管理ダッシュボードとして、ユーティリティ使用量、太陽光発電、契約容量、制約通知などを扱う。([SPグループ][36])
PdM視点の学び
シンガポール型の価値は、都市インフラとEMSの近さだ。
需要家の電力・太陽光・蓄電池・契約容量を一体管理する方向は、日本の工場・商業施設向けにもそのまま応用できる。
35. Singapore EMA / data.gov.sg：公式統計・市場データのAPI基盤
シンガポールではdata.gov.sgを通じてEMA関連データセットが提供され、API利用時のレート制限やサインアップも説明されている。Open Electricity Marketの統計も公式に公開されている。([data.gov.sg][37])
PdM視点の学び
国家データ基盤とエネルギー市場データの接続は、都市型GXの土台になる。
特にB2G、都市OS、スマートシティ系プロダクトでは効く。
36. India CEA API / data.gov.in：インドの電力統計API
インドでは、Central Electricity AuthorityのデータAPIがあり、設備容量、地域・州別データ、電力需給、ピーク、発電、再エネなどを扱う。data.gov.inにもPower & Energy領域のAPIが提供されている。([Central Electricity Authority][38])
PdM視点の学び
インド型の特徴は、巨大市場、地域差、電源構成、再エネ成長の組み合わせだ。
APIプロダクトでは、全国平均ではなく州・地域別の差分を見る設計が必要になる。
37. Taipower Open Data：台湾の電力会社データ公開
台湾電力はオープンデータを公開しており、過去の各ユニットの発電量、電力使用統計などのデータセットが存在する。10分ごとの発電データや、電力使用統計の更新情報も確認できる。([taipower.com.tw][39])
PdM視点の学び
台湾のように半導体産業と電力が強く結びつく市場では、電力データは産業政策そのものになる。
データセンターや半導体工場の立地、再エネ調達、電力安定供給の判断に直結する。
38. Ember API：世界の電力・排出データをAPI化する
Ember APIは、各国の月次・年次の発電、需要、電力部門排出、炭素強度などのオープン電力データを提供している。([Ember Energy][40])
PdM視点の学び
グローバル比較系のAPIは、国内だけを見ていると見えない差分を出す。
企業のサプライチェーン排出、海外拠点の再エネ調達、データセンター立地に使える。
39. China State Grid / China Southern Power Grid：公開APIよりデジタルグリッド・AI運用色が強い
中国のState Grid Corporation of Chinaは中国の電力網の大部分を担う巨大事業者であり、China Southern Power Gridは南部5省区を中心に供給する大規模事業者だ。公開されている情報を見る限り、欧米のような開発者向け公開APIの事例よりも、デジタルグリッド、AI運用、エネルギービッグデータセンターの色が強い。([World Benchmarking Alliance][41])
PdM視点の学び
中国型のデジタル電力は、公開APIエコシステムというより、巨大運用基盤・AI運用・国家インフラの文脈で見るべきだ。
日本企業が真似するなら、対外公開APIよりも、まず社内外の業務データ統合とAI運用支援から入る方が現実的かもしれない。
40. Korea KPX / KEPCO：OpenAPIと電力データ基盤
韓国では、Korea Electric Power Exchange関連のOpenAPIが政府データポータル上に掲載されており、KEPCOも環境、電力インフラ、電力サービスなどのESG関連データを公開している。([데이터.go][42])
PdM視点の学び
韓国型の示唆は、政府データポータルと電力会社データをどう接続するかだ。
APIの公開粒度だけでなく、産業利用・AI利用・開発者体験まで設計しないと、データは使われない。
41. OpenADR / OpenLEADR：DR制御をAPI・プロトコル化する
OpenADRは、電力グリッドにおける自動デマンドレスポンスのためのプロトコルとして説明されており、Rust実装のOpenLEADRやPython実装が存在する。クライアントとサーバーの両方を実装できるため、DRイベント、動的料金、負荷制御などの技術基盤になる。([GitHub][43])
PdM視点の学び
データAPIと制御APIは違う。
DRやVPPでは、「情報を見る」だけではなく、「負荷を動かす」「蓄電池を制御する」「EV充電を抑制する」までがプロダクトになる。
42. EnergyPlus-MCP / ENTSO-E MCP / Luminus：エネルギーMCPの初期実装群
EnergyPlus-MCPは、EnergyPlusシミュレーションワークフロー向けのオープンソースMCPサーバーとして紹介されている。ENTSO-E MCP ServerやLuminusのように、ENTSO-E、Energy-Charts、Nord Pool、SMARD、ElexonなどをAIエージェントから扱いやすくするコミュニティMCPも登場している。([サイエンスダイレクト][44])
PdM視点の学び
MCPはAPIの代替ではない。
APIをAIエージェントが使いやすい形に包む「道具箱」だ。
つまり、エネルギー企業がまず作るべきものはMCPではなく、監査可能で安定したAPI。その次にMCP化である。
事例から見える6つの本質
本質1：電力APIの成熟度は「データ公開」ではなく「開発者体験」で決まる
データが公開されていても、開発者が使えなければプロダクトにはならない。
ENTSO-E、Nord Pool、Octopus、AEMO、OpenElectricity、Amberのような事例を見ると、価値が出るAPIには共通点がある。
- 認証方式が明確
- API仕様が公開されている
- エンドポイントの意味が分かる
- サンプルやSDKがある
- データ更新頻度が分かる
- ライセンスや利用条件が明示されている
- バージョン移行・廃止告知がある
これがないAPIは、現場では「触れないAPI」になる。
本質2：市場データAPIだけでは儲からない。判断APIに変換して初めて儲かる
JEPX価格、需給、電源構成、CO2排出、出力制御、デマンドデータ。
どれも重要だが、顧客はデータそのものにお金を払うのではない。
顧客が知りたいのは次の問いだ。
- この工場に太陽光を入れるべきか
- 蓄電池を入れるなら何kWhか
- PPAと自己所有はどちらがよいか
- EV充電器を何台入れるべきか
- 料金プラン変更でどれだけ削減できるか
- 補助金を入れると投資回収はどう変わるか
- CO2削減量をどう社内説明するか
つまり、データAPIの次に必要なのは、意思決定API である。
エネがえるAPIのような経済効果シミュレーションAPIは、この「判断に変換するレイヤー」に位置づけられる。
エネがえる共通 公開用 API https://www-apidoc.enegaeru.com/sys/
本質3：脱炭素APIでは「平均排出係数」と「限界排出係数」を混ぜると事故る
WattTimeのMOERのような限界排出係数は、負荷変化に反応する発電の排出を見る。一方、一般的なCO2排出係数は平均的な電源構成に近い。([WattTime][45])
この違いは、EV充電や蓄電池制御ではかなり大きい。
- 平均排出係数：報告、集計、比較に向く
- 限界排出係数：制御、DR、充電タイミング最適化に向く
- 電源構成API：可視化、理解、説明に向く
- 経済効果API：投資判断、稟議、営業提案に向く
日本の脱炭素サービスでよくある失敗は、報告用KPIと制御用KPIを混ぜることだ。
ここはプロダクト設計で分けた方がよい。
本質4：需要家データAPIは、再エネ提案のボトルネックを壊す
太陽光・蓄電池・EV・V2H・PPA提案で最も面倒なのは、実はシミュレーションロジックではない。
多くの場合、最初の壁はデータ取得だ。
- 電気料金明細がない
- 30分デマンドがない
- 料金プランが分からない
- 契約電力が分からない
- 使用量が月次しかない
- 複数拠点のデータが揃わない
UtilityAPI、Arcadia、Wattwatchersの事例は、この壁をAPIで壊しにいっている。([UtilityAPI][22])
日本でも、需要家同意ベースの使用量データ取得APIと、エネがえるAPIのような経済効果シミュレーションAPIが接続されると、提案業務はかなり変わる。
エネがえる共通 公開用 API https://www-apidoc.enegaeru.com/sys/
本質5：AIエージェントは「データ取得」より「判断と実行」に向かう
DEWA RammasのようなAIエージェント事例を見ると、単なる問い合わせ対応から、発電、送配電、顧客サービス、社内業務へ広がっている。([ディワ][34])
エネルギー領域のAIエージェントは、今後こう進む。
Step 1: データ検索
Step 2: 状況要約
Step 3: 試算
Step 4: 提案書生成
Step 5: 実行承認
Step 6: 制御・更新・再提案
ここで重要なのは、AIエージェントが勝手に動くことではない。
監査可能なAPI、前提条件、承認フロー、ログが必要になる。
本質6：MCPはAPIを置き換えない。APIをAIエージェントに渡す翻訳層である
MCPは、LLMと外部データ・ツール・サービスの接続を標準化するものとして説明されている。([Google Cloud][2])
ただし、エネルギー事業者がいきなりMCPだけを作っても弱い。
MCPの裏側に、安定したAPI、データ権限、契約、ログ、再現性が必要だからだ。
エネルギーPdMが考えるべき順序はこうだ。
energy_agent_architecture:
layer_1_data_sources:
- market_data_api
- grid_data_api
- customer_usage_api
- carbon_intensity_api
- tariff_api
layer_2_decision_api:
- pv_battery_roi_simulation
- ppa_vs_ownership_comparison
- ev_v2h_tco_simulation
- demand_response_value_estimation
layer_3_agent_interface:
- mcp_server
- cli
- slack_agent
- internal_copilot
layer_4_governance:
- audit_log
- versioned_assumptions
- approval_flow
- customer_consent
日本のエネルギー事業者が今すぐ真似すべき設計
1. APIを「機能単位」ではなく「意思決定単位」で切る
悪いAPI設計はこうだ。
/pv/calc
/battery/calc
/tariff/get
/report/export
一見分かりやすいが、顧客の意思決定単位ではない。
良いAPI設計はこうだ。
/cases/{case_id}/simulate
/cases/{case_id}/compare
/cases/{case_id}/decision-packet
/customers/{customer_id}/tariff-fit
/sites/{site_id}/pv-battery-ppa-options
顧客は「太陽光の計算」をしたいのではない。
「この条件で導入すべきか」を判断したい。
2. 取得APIと試算APIを分ける
世界の事例を見ても、APIは大きく2つに分かれる。
| API種別 | 代表例 | 返すもの | 顧客価値 |
|---|---|---|---|
| 取得API | ENTSO-E、AEMO、SMARD、Elexon | 市場・需給・発電・価格データ | 分析の材料 |
| 試算API | エネがえるAPI、PPA/TCO/ROI系API | 経済効果、回収年数、比較結果 | 意思決定の材料 |
| 制御API | OpenADR、Amber、nemy | 充放電・負荷調整の信号 | 実行・最適化 |
| 説明API | Carbon Intensity、Electricity Maps、WattTime | CO2、電源構成、排出係数 | 説明・報告・制御 |
日本で新規事業を作るなら、取得APIだけを作るより、取得API × 試算API × レポートAPI まで組む方が顧客価値が高い。
3. YAML/JSONで「試算条件」を契約化する
再エネ提案で事故が起きるのは、計算式が難しいからではない。
前提条件が消えるからだ。
simulation_case:
site:
region: "JP-13"
contract_power_kw: 500
annual_usage_kwh: 1200000
tariff:
utility: "example_power"
plan: "high_voltage_standard"
assets:
pv_kw: 300
battery_kwh: 500
ev_chargers: 10
assumptions:
pv_degradation_pct_per_year: 0.5
battery_roundtrip_efficiency_pct: 90
electricity_price_escalation_pct: 2
subsidy_jpy: 0
outputs:
- annual_saving_jpy
- payback_year
- co2_reduction_tco2
- ppa_unit_price_sensitivity
このような前提をAPIリクエストとして残せば、AIエージェントが後から再試算できる。
営業、CS、BPO、開発、監査が同じ条件を見られる。これが地味に強い。
4. APIの価値は「SDK」「CLI」「Notebook」で跳ねる
Qiita読者に刺さるのは、ここだ。
APIドキュメントだけでは、社内の一部エンジニアしか触らない。
だが、Python SDK、TypeScript SDK、CLI、サンプルNotebookがあれば、PdM、データサイエンティスト、営業企画、BPO担当も触れる。
energy-case create --site factory-a.yaml
energy-case simulate --engine enegaeru --scenario pv_battery_ppa
energy-case compare --options ownership,ppa,lease
energy-case report --format markdown
これがあるだけで、APIは「仕様書」から「業務道具」になる。
日本で狙える新規サービス案
案1：JEPX × 蓄電池 × 出力制御 × エネがえるAPI
市場データAPIでJEPX価格や需給を取得し、エネがえるAPIで需要家併設蓄電池の経済効果を試算する。
そこに出力制御やDR価値を入れれば、蓄電池提案はかなり高度化する。
案2：需要家データ取得API × 太陽光・蓄電池自動提案
UtilityAPIやArcadia型の需要家データ取得を日本市場向けに構想する。
電気料金明細、30分デマンド、契約電力、料金プランを取得し、エネがえるAPIで自動診断する。
案3：自治体施設ポートフォリオ診断API
自治体の庁舎、学校、体育館、避難所、浄水場、下水処理場などを一括で診断する。
施設ごとに、太陽光、蓄電池、PPA、自己所有、補助金、BCP価値を比較する。
案4：EV充電・商用EV TCO API
商用EV、充電器、太陽光、蓄電池、電力契約をまとめて試算する。
車両単体のTCOではなく、施設電力と充電インフラを含めたTCO APIにする。
案5：AIエージェント向け再エネ試算MCP
エネがえるAPIや市場データAPIをMCP化し、AIエージェントから以下を実行できるようにする。
「この工場の30分デマンドCSVから、太陽光300kW・蓄電池500kWh・PPA単価3案で比較して」
「補助金なし・ありで回収年数を出して」
「営業担当向けの提案メモをMarkdownで作って」
エネがえる共通 公開用 API https://www-apidoc.enegaeru.com/sys/
この世界はかなり近い。
エネがえるAPIを世界のAPI文脈でどう見るか
世界のAPI事例を見ると、エネがえるAPIは「市場データAPI」ではなく、再エネ導入判断を返すDecision API として見るのが自然だ。
エネがえるは、太陽光、蓄電池、EV/V2H、PPAなどの経済効果シミュレーションやBPOを含むプロダクト群を持つため、電力データを「判断結果」に変換するレイヤーに位置づけられる。
エネがえる共通 公開用 API https://www-apidoc.enegaeru.com/sys/
海外事例との対応関係はこうなる。
| 海外APIの型 | 代表例 | エネがえる文脈での対応 |
|---|---|---|
| 市場データAPI | ENTSO-E、AEMO、Nord Pool、Elexon | JEPX、出力制御、需給、市場価格データの入力 |
| 需要家データAPI | UtilityAPI、Arcadia、Wattwatchers | 電気料金明細、30分デマンド、契約情報の入力 |
| CO2 API | WattTime、Electricity Maps、Carbon Intensity | CO2削減量、環境価値、Jクレジット検討 |
| 動的料金API | Amber、Tibber、Octopus | 料金プラン最適化、EV/V2H、蓄電池制御 |
| 試算・意思決定API | EnergyPlus-MCP、各種シミュレーション系 | エネがえるAPI、BPO、レポート生成 |
| AI Agent / MCP | DEWA Rammas、EnergyPlus-MCP、ENTSO-E MCP | 再エネ提案AI、社内営業支援、BPO自動化 |
つまり、日本のエネルギーSaaSで狙うべきは、海外APIをそのまま真似ることではない。
日本固有の料金制度、電力会社プラン、補助金、PPA慣行、施工・営業現場の課題を吸収したうえで、判断まで返すAPI にすることだ。
MCP時代のエネルギーAPI設計テンプレ
最後に、エネルギー事業者がMCP/AIエージェント対応を進めるときの最小テンプレを置く。
mcp_energy_stack:
name: "renewable-decision-agent"
purpose: "需要家条件から再エネ導入判断を返すAIエージェント基盤"
tools:
- name: "get_market_price"
type: "data_api"
sources:
- "JEPX"
- "ENTSO-E"
- "AEMO"
- "Nord Pool"
- name: "get_customer_load"
type: "customer_data_api"
inputs:
- "smart_meter"
- "demand_csv"
- "utility_bill"
- name: "simulate_renewable_roi"
type: "decision_api"
engine:
- "enegaeru_api"
outputs:
- "annual_saving"
- "payback_year"
- "co2_reduction"
- "ppa_comparison"
- "battery_value"
- name: "generate_decision_packet"
type: "report_api"
outputs:
- "markdown"
- "pdf"
- "excel"
- "sales_memo"
governance:
- "customer_consent"
- "audit_log"
- "assumption_version"
- "calculation_engine_version"
- "approval_required_before_submission"
MCPは派手だ。
だが、実務で効くのは、派手なAIデモではない。
前提条件が残り、再計算でき、説明でき、顧客に提出できることである。
FAQ
Q1. 電力会社や再エネ会社は、なぜAPIを公開するのか？
外部開発者、パートナー、需要家、AIエージェントが自社データやサービスを使えるようにするためだ。データ公開だけでなく、料金、契約、CO2、需給、試算、制御までAPI化されると、新しいアプリケーションや収益モデルが生まれる。
Q2. 電力APIと普通のSaaS APIは何が違うのか？
電力APIは、時間粒度、地点、契約、単位、制度、電力市場、系統制約が絡む。kWとkWh、平均排出係数と限界排出係数、卸価格と小売料金を混同すると、プロダクト判断を誤る。
Q3. MCPは電力APIを置き換えるのか？
置き換えない。MCPはAIエージェントがAPIやツールを使いやすくする接続層であり、裏側には安定したAPI、認証、権限、監査ログが必要になる。
Q4. 日本で最初にAPI化すべきエネルギー業務は何か？
実務インパクトが大きいのは、需要家データ取得、料金プラン判定、太陽光・蓄電池・EV/V2H・PPAの経済効果試算、提案レポート生成だ。市場データだけをAPI化しても、顧客の意思決定までは進まない。
Q5. エネがえるAPIは海外API事例のどこに近いのか？
ENTSO-EやAEMOのような市場データAPIというより、データを経済効果・投資判断・提案資料へ変換するDecision APIに近い。海外のデータAPIと組み合わせると、より強い提案・診断基盤になる。
エネがえる共通 公開用 API https://www-apidoc.enegaeru.com/sys/
Q6. AIエージェントに再エネ提案を任せると危険では？
危険になり得る。だからこそ、前提条件、計算バージョン、入力データ、出力結果、承認ログを残す設計が必要になる。AIに自由作文させるのではなく、監査可能なAPIを呼ばせるべきだ。
Q7. 日本の電力・再エネPdMがまずやるべきことは？
自社サービスを「画面」ではなく「APIで呼べる判断機能」として棚卸しすること。次に、需要家データ、料金データ、設備データ、試算ロジック、レポート出力を分解し、どこをAPI化すれば顧客の意思決定が速くなるかを見る。
まとめ：エネルギーAPIの勝ち筋は「データを返す」から「判断を返す」へ
世界の事例を見ると、エネルギーAPIはすでに4つの方向へ分岐している。
- 市場・系統データを公開するAPI
- 需要家データを同意ベースで取得するAPI
- CO2・電源構成・価格をリアルタイムに返すAPI
- 試算・制御・提案・AIエージェント実行へつなぐAPI
日本のエネルギー事業者が狙うべきは、単なる海外模倣ではない。
日本の料金制度、補助金、営業現場、PPA、蓄電池、EV/V2H、自治体GX、需要家稟議の摩擦を踏まえ、データを判断に変換するAPI を作ることだ。
その意味で、エネがえるAPIのような経済効果シミュレーションAPIは、単なる計算機ではない。
電力・再エネ・脱炭素事業を、AIエージェント時代の意思決定インフラへ進化させる部品になり得る。
電力APIの未来は、CSVを返すことではない。
「この条件なら、次に何をすべきか」を返すことである。
[1]: https://docs.octopus.energy/graphql/guides/basics?utm_source=chatgpt.com "GraphQL API Guides | API docs"
[2]: https://cloud.google.com/discover/what-is-model-context-protocol?utm_source=chatgpt.com "What is Model Context Protocol (MCP)? A guide"
[3]: https://www.neso.energy/data-portal/api-guidance?utm_source=chatgpt.com "API guidance"
[4]: https://bmrs.elexon.co.uk/api-documentation/introduction?utm_source=chatgpt.com "API documentation | Insights Solution"
[5]: https://carbonintensity.org.uk/?utm_source=chatgpt.com "Carbon Intensity API"
[6]: https://data.nationalgas.com/apis/rest-apis?utm_source=chatgpt.com "REST API | National Gas Transmission Data Portal"
[7]: https://documenter.getpostman.com/view/7009892/2s93JtP3F6?utm_source=chatgpt.com "Transparency Platform Restful API"
[8]: https://github.com/EnergieID/entsoe-py?utm_source=chatgpt.com "EnergieID/entsoe-py"
[9]: https://www.epexspot.com/en/marketdataservices?utm_source=chatgpt.com "Market Data Services"
[10]: https://www.elia.be/en/grid-data?utm_source=chatgpt.com "Grid data - Elia"
[11]: https://www.rte-france.com/en/data-publications/eco2mix?utm_source=chatgpt.com "éCO 2 mix, all of France's electricity data in real time"
[12]: https://www.smard.de/en/downloadcenter/download-market-data?utm_source=chatgpt.com "Download market data"
[13]: https://api.energy-charts.info/?utm_source=chatgpt.com "Energy-Charts API"
[14]: https://data.fingrid.fi/en/instructions?utm_source=chatgpt.com "API instructions"
[15]: https://www.energidataservice.dk/guides/api-guides?utm_source=chatgpt.com "API Guide"
[16]: https://data-api.nordpoolgroup.com/index.html?utm_source=chatgpt.com "API Definition | Nord Pool Data"
[17]: https://developer.tibber.com/docs?utm_source=chatgpt.com "Tibber API"
[18]: https://www.statnett.no/en/career/for-students-and-apprentices/do-you-need-data/?utm_source=chatgpt.com "Do you need data?"
[19]: https://opendata.esett.com/?utm_source=chatgpt.com "eSett Open Data: Main"
[20]: https://www.pse.pl/web/pse-eng/data?utm_source=chatgpt.com "Data"
[21]: https://map.ua-energy.org/en/resources/56df70b0-6bc1-4c7d-a82f-284cf723438d/?utm_source=chatgpt.com "Hourly electricity imports and exports"
[22]: https://utilityapi.com/docs/greenbutton?utm_source=chatgpt.com "UtilityAPI - Docs - Green Button"
[23]: https://docs.arcadia.com/v1.0-Utility-Cloud/docs/api-quick-start-guide?utm_source=chatgpt.com "API Quick Start Guide - Arcadia"
[24]: https://docs.watttime.org/?utm_source=chatgpt.com "WattTime Data API"
[25]: https://app.electricitymaps.com/docs?utm_source=chatgpt.com "API Docs | Electricity Maps"
[26]: https://www.eia.gov/opendata/?utm_source=chatgpt.com "Opendata - U.S. Energy Information Administration (EIA)"
[27]: https://www.gridstatus.io/products/api?utm_source=chatgpt.com "Grid Status API - Power Your Applications"
[28]: https://dev.aemo.com.au/?utm_source=chatgpt.com "AEMO APIs: Home"
[29]: https://docs.openelectricity.org.au/introduction?utm_source=chatgpt.com "Introduction - Open Electricity Documentation"
[30]: https://help.amber.com.au/hc/en-us/articles/360038985552-Do-you-have-an-API?utm_source=chatgpt.com "Do you have an API? - Amber Electric"
[31]: https://docs.wattwatchers.com.au/api/v3/endpoints.html?utm_source=chatgpt.com "API endpoints"
[32]: https://www.nemy.io/api?utm_source=chatgpt.com "nemy API"
[33]: https://www.ea.govt.nz/data-and-insights/tools-and-apis/?utm_source=chatgpt.com "APIs and tools"
[34]: https://www.dewa.gov.ae/en/about-us/media-publications/latest-news/2025/04/dewa-experts-highlight-the-latest-ai-advancements-in-energy-and-water-at-dubai-ai-week-2025?utm_source=chatgpt.com "DEWA experts highlight the latest AI advancements in ..."
[35]: https://www.se.com.sa/en/Open-Data/Open-Data/?utm_source=chatgpt.com "Open Data - Saudi Energy"
[36]: https://www.spgroup.com.sg/?utm_source=chatgpt.com "SP Group - Singapore"
[37]: https://data.gov.sg/datasets?agencies=Energy+Market+Authority+%28EMA%29&utm_source=chatgpt.com "EMA (Energy Market Authority)"
[38]: https://cea.adgstaging.in/api-for-central-electricity-authority-data/?lang=en&utm_source=chatgpt.com "API for Central Electricity Authority Data"
[39]: https://www.taipower.com.tw/2764/2865/2888/2889/simpleList?utm_source=chatgpt.com "Taiwan Power Company-Open Data ..."
[40]: https://ember-energy.org/data/api/?utm_source=chatgpt.com "API - Ember"
[41]: https://www.worldbenchmarkingalliance.org/company/state-grid-corporation-china?utm_source=chatgpt.com "State Grid Corporation of China"
[42]: https://www.data.go.kr/en/bbs/ntc/selectNotice.do?originId=NOTICE_0000000002568&utm_source=chatgpt.com "[Korea Electric Power Exchange] 3 types of Open API ..."
[43]: https://github.com/OpenLEADR/openleadr-rs?utm_source=chatgpt.com "OpenADR 3.0 VTN and VEN implementation in Rust · ..."
[44]: https://www.sciencedirect.com/science/article/pii/S2352711025003334?utm_source=chatgpt.com "EnergyPlus-MCP: A model-context-protocol server for ai- ..."
[45]: https://watttime.org/data-science/data-signals/marginal-co2/?utm_source=chatgpt.com "SIGNAL: Marginal CO2"