太陽光発電量シミュレーション技術の世界地図：PVWatts・SAM・PVGIS・PVsyst・Google Solar API・エネがえるAPIまで徹底比較

Posted at 2026-05-21

太陽光発電量シミュレーション技術の世界地図：PVWatts・SAM・PVGIS・PVsyst・Google Solar API・エネがえるAPIまで徹底比較

タグ例：太陽光発電 再エネ API GIS Python PPA EV V2H シミュレーション

30秒で結論

太陽光発電量シミュレーションは、単に「年間発電量 kWh」を出す技術ではない。
本質は、日射データ、地理空間データ、影・積雪・温度・劣化・PCS制約、需要家の負荷、電気料金、PPA単価、蓄電池・EV/V2Hの運用をどこまで同じ意思決定フローに接続できるかである。

世界の定番ツールを乱暴に分けると、こうなる。

レイヤー	主な問い	代表ツール / API
日射・気象データ	その場所にどれだけ太陽エネルギーが来るか	NEDO METPV-20、PVGIS、NSRDB、Global Solar Atlas、Solcast、SolarAnywhere、Meteonorm
発電量物理モデル	パネル・PCS条件で何kWh出るか	PVWatts、SAM / PySAM、pvlib、PVsyst、PV*SOL、SolarPro
屋根・影・3D設計	どこに何枚置けるか、影はどうか	Google Solar API、Aurora Solar、HelioScope、PV*SOL、RatedPower、PlantPredict
経済効果・提案・PPA	誰にとって得か、稟議が通るか	SAM、HOMER、RETScreen、エネがえるASP / Biz / EV・V2H / コーポレートPPA / API

結論から言えば、PVsystやSAMは“技術設計の正本”に強く、Google Solar APIは“屋根・地理空間の自動化”に強く、PVGISやGlobal Solar Atlasは“広域の初期評価”に強い。エネがえるは、それらの発電量や設備条件を、電気料金・補助金・自家消費・蓄電池・EV/V2H・PPA・提案書・API連携へつなぐ意思決定レイヤーとして使うと強い。

この記事は、エンジニア、PdM、再エネ事業開発、EPC、PPA事業者、電力小売、自治体GX担当が「どのツールを何に使うべきか」を判断するための技術地図である。

1. 太陽光発電量シミュレーションの基本式

最も単純化すると、太陽光発電量は次のように書ける。

年間発電量(kWh)
= 傾斜面日射量(kWh/㎡)
× 太陽光設備容量(kW)
× 各種損失補正

もう少し実務に近づけると、時刻ごとにこうなる。

AC発電量(t)
= POA日射量(t)
× DC容量
× モジュール温度補正(t)
× 配線・汚れ・ミスマッチ・影・積雪・劣化補正
× インバータ変換効率
× 出力抑制・クリッピング補正

ここで重要なのは、発電量の精度を決めるのは“計算式のかっこよさ”だけではないという点だ。むしろ実務では、以下のほうが効く。

日射データの粒度と鮮度
水平面日射量から傾斜面日射量への変換
直達・散乱・地面反射の扱い
気温・風速・セル温度モデル
日陰、近隣建物、樹木、積雪、汚れ
DC/AC比、PCS容量、クリッピング
蓄電池やEV/V2Hによる自家消費の変化
需要家の30分値デマンド
電気料金プラン、燃調、再エネ賦課金、PPA単価

NEDOのMETPV-20は、日本国内の日射量データベースとして、MONSOLA-20とMETPV-20を提供し、METPV-20では気象庁のアメダスデータを基に時刻別データを整備している。METPV-20の説明資料では、水平面全天日射量、直達・散乱日射量、傾斜面日射量、気温、風、降水量、積雪深などが扱われ、傾斜面日射量は直達成分、天空散乱成分、地面反射成分を合成して求める考え方が示されている。(NEDO)

ミニコラム：発電量シミュレーションは“天気予報”ではなく“会計処理”に近い

発電量シミュレーションを「未来の発電量を当てる技術」とだけ見ると誤る。
実務ではむしろ、会計処理に近い。

どのデータを採用したか。
どの損失を入れたか。
どの年度を代表年にしたか。
どの条件で比較したか。

この前提がそろっていない発電量比較は、売上だけを見て利益を語るようなものだ。
数字は出る。だが、意思決定にはまだ足りない。

2. 世界の主要ツールを4レイヤーで見る

太陽光シミュレーションツールは、同じように見えて役割が違う。
「PVsystとGoogle Solar APIはどちらが上か」と聞くのは、CADとGoogle Mapsを比べるようなものだ。比較すべきは優劣ではなく、どのジョブを解いているかである。

レイヤー1：日射・気象データ

ツール / データ	主な用途	強み	注意点
NEDO METPV-20	日本国内の標準的な発電量推計	日本向け。国内地点データ、平均年・多照年・寡照年の考え方	海外案件には向かない
PVGIS	欧州発の広域PV性能評価	世界の多くの地域で利用可能。APIも提供	詳細設計・商談資料には別ツール連携が必要
NSRDB	米国・国際日射データ	NREL系ツールとの親和性	地域・用途に応じてデータセット選択が必要
Global Solar Atlas	国別・地域別ポテンシャル把握	世界銀行/ESMAP支援の無料サービス。広域の初期評価に強い	詳細な個別設計には不足
Solcast	高頻度・高解像度の気象/日射API	APIやCSVで履歴・予測データを扱える	商用利用条件・精度検証が必要
SolarAnywhere	米国中心の商用日射・予測データ	資源評価、監視、予測用途	有償前提の設計になりやすい
Meteonorm	世界的な気象・日射DB	設計・金融・国際案件で使われることが多い	入力前提とバージョン管理が重要

PVGISは欧州委員会JRCが提供するPV性能評価サービスで、Web APIも提供されている。Global Solar Atlasは世界銀行グループ/ESMAPとSolargisの枠組みによる世界規模の太陽光ポテンシャル可視化サービスであり、初期ポテンシャル評価に使いやすい。(Joint Research Centre)

Solcast、SolarAnywhere、Meteonorm、Open-Meteoのような気象・日射API群は、発電量推計だけでなく、運用監視、予測、需給制御、蓄電池制御、PPAポートフォリオ評価にも接続しやすい。Solcastは衛星観測や気象モデルを用いた履歴・予測データ、SolarAnywhereは日射・発電予測、Meteonormは放射データや気象API、Open-Meteoは衛星放射APIなどを提供している。(Solcast)

レイヤー2：発電量物理モデル

ツール	主な用途	強み	注意点
PVWatts	ざっくり速いPV発電量推計	APIが扱いやすい。初期検討に強い	詳細設計には限界
SAM / PySAM	技術・経済性を含む詳細分析	NREL製。PV、蓄電池、PPA、金融モデルに対応	入力項目が多く学習コストあり
pvlib	PythonでのPVモデル実装	オープンソース。モデルチェーンを自作できる	エンジニア向け。業務UIは自前
PVsyst	専門家向けPV設計・銀行向け評価	国際的な定番。詳細設計・レポートに強い	商談自動化や料金計算は別レイヤー
PV*SOL	3D設計、影、蓄電池、EV等の統合設計	住宅・建物PVの設計可視化に強い	国・料金・営業フローとの統合は要設計
SolarPro	日本の設計実務で使われることが多い	日本案件の設計・図面・影解析文脈に合いやすい	API・SaaS連携は個別設計が必要

PVWatts V8はNREL系のPV発電量推計APIで、システム容量、損失率、アレイタイプ、傾斜角、方位角、データセットなどを指定し、月別・年別・時間別のAC出力などを取得できる。V8では両面モジュール、月別日射損失、アルベド、モジュール/インバータ/熱モデル更新などが扱われる。(NREL Developer Network)

SAMはNRELが提供する無償のデスクトップアプリケーションで、PVや蓄電池などの技術・経済性分析に対応し、住宅・商業・PPAなどの金融モデルも扱える。PySAMはSAMの計算コアをPythonから使うための選択肢になる。(System Advisor Model)

pvlibは、太陽位置、日射、温度、電気モデルなどをPythonで扱うためのオープンソースライブラリで、研究・検証・独自モデル実装に向いている。pvlibのドキュメントでは、単一ダイオードモデルなど複数のPV性能モデルも扱われている。(Pvlib Python)

PVsystはPV設計・シミュレーションソフトの国際定番の一つで、詳細設計、時間別/サブ時間別シミュレーション、収益性評価などを扱う。PV*SOLは3D設計、影、蓄電池、EV、ヒートポンプ等の統合設計機能を持つ。(PVSyst)

レイヤー3：屋根・影・3D・地理空間API

ツール / API	主な用途	強み	注意点
Google Solar API	建物・屋根・日射・影データ取得	buildingInsights、dataLayers、GeoTIFFなどを提供	対応地域、商用利用条件、再販条件の確認が必須
Aurora Solar	屋根設計・販売・提案ワークフロー	APIでワークフロー連携可能	国・地域ごとのデータ前提確認が必要
HelioScope	C&I向け設計・影・レポート	商業用PV設計・営業に強い	詳細な料金・PPA試算は別レイヤー
RatedPower	Utility-scale PV設計最適化	大規模PVのレイアウト・DC/AC・GCR比較	住宅・低圧商談には過剰な場合がある
PlantPredict	Utility-scaleの発電量・設計評価	発電量予測、レイアウト、APIアクセス	金融・EPC向け色が強い

Google Solar APIは、建物単位の太陽光ポテンシャル情報を返すbuildingInsights、太陽光関連のラスターデータを返すdataLayers、DSMや航空/衛星画像、月別・年別の日射、時間別の日陰などを取得するGeoTIFF系の仕組みを提供している。屋根上PVのリモート設計や提案作成の自動化に使えるが、対応地域、利用規約、商用利用・再販条件は必ず確認すべきである。(Google for Developers)

Aurora SolarはAPI連携により、データ転記や手作業のミスを減らすワークフロー構築を支援する。HelioScopeは設計条件セットごとにシミュレーションし、レポートや影レポートを作成できる。RatedPowerやPlantPredictは、より大規模な発電所設計・発電量予測・レイアウト最適化に向く。(Aurora API)

レイヤー4：経済効果・PPA・提案・API連携

発電量が正しくても、導入判断はまだ終わらない。
需要家やPPA事業者が知りたいのは、次の問いだからだ。

この発電量は、電気代削減・売電・PPA単価・蓄電池運用・EV/V2H・補助金・稟議にどう効くのか？

このレイヤーで使われる代表例は、SAM、HOMER、RETScreen、エネがえるなどである。HOMERはマイクログリッドや分散電源の技術・経済性評価、RETScreenはクリーンエネルギー計画・実装・監視・報告、SAMはPPA等の金融モデルに対応する。(HOMER Energy)

エネがえるは、発電量設計ソフトを置き換えるものではない。むしろ、PVsyst、SolarPro、SAM、Google Solar API、NEDO METPV-20等で得た発電量・設備条件を、電気料金、補助金、蓄電池、EV/V2H、PPA、提案書、API連携へつなぐ意思決定レイヤーとして見ると役割が明確になる。エネがえるAPIは、住宅用に加えて産業用自家消費型太陽光・蓄電池、EV/V2H/充電器、電気料金参照、補助金情報などへ対象を拡張しており、100社3,000プラン以上の電気料金プランを月次更新する旨が公式リリースで説明されている。(KKC)

エネがえるのコーポレートPPA系サービスは、複数需要施設と複数発電所を組み合わせたオフサイト・フィジカルPPAの経済効果シミュレーション、固定単価や市場連動型プラン、JEPXスポット市場価格連動の試算を支援する位置づけで説明されている。(faq.enegaeru.com)

3. 主要ソフトウェア・API比較マトリクス

技術者向け：まずこの表で選ぶ

名前	地域・出自	得意領域	API/自動化	向く読者	一言評価
PVWatts	米国 / NREL	初期PV発電量推計	あり	Webサービス開発者、PoC担当	最速でPV推計を組み込む入口
SAM / PySAM	米国 / NREL	技術・金融統合モデル	PySAMあり	研究者、事業開発、金融分析	発電量と採算を深く見るNREL標準系
pvlib	OSS	PVモデル実装	Python	エンジニア、研究者	自作モデル・検証の自由度が高い
PVGIS	欧州 / JRC	広域PV性能評価	あり	初期調査、国際比較	無料・広域・実装容易
Global Solar Atlas	World Bank / Solargis	世界の太陽光ポテンシャル把握	データ利用中心	国際事業開発、政策調査	国別・地域別の初期評価に強い
PVSyst	スイス	詳細PV設計、銀行向け評価	限定的	EPC、発電事業者、金融	詳細設計の定番
PV*SOL	ドイツ	3D設計、住宅・建物PV	限定的	設計者、販売施工店	3D・影・蓄電池・EV連携が強い
Google Solar API	米国 / Google	建物・屋根・日射・影データ	あり	PdM、GIS、Web開発者	屋根上PVの自動化レイヤー
Aurora Solar	米国	屋根設計・営業プロセス	あり	住宅/商業PV事業者	営業・設計ワークフロー型
HelioScope	米国	C&I PV設計・影・レポート	限定的	C&I EPC、設計者	商業PV設計の現場向き
RatedPower	欧州系	大規模PVレイアウト最適化	あり	Utility-scale開発者	大規模発電所設計に強い
PlantPredict	米国系	Utility-scale発電量予測	APIあり	発電事業者、EPC	大規模PVの予測・設計評価
HOMER	米国系	マイクログリッド経済性	限定的	離島、マイクログリッド、蓄電池	PV単体より分散電源全体を見る
RETScreen	カナダ	クリーンエネルギー計画・M&V	限定的	自治体、公共、ESCO	計画・実装・監視の文脈に強い
エネがえるASP	日本	住宅用PV・蓄電池・オール電化の経済効果	SaaS	販売施工店、住宅営業	技術設計より提案・成約支援
エネがえるBiz	日本	産業用自家消費PV・蓄電池の経済効果	SaaS/API/BPO連携	EPC、PPA、法人提案	デマンド・料金・回収年数に接続
エネがえるEV・V2H	日本	EV/V2H/充電器を含む経済効果	SaaS/API連携	自動車、住宅、販売店	太陽光とモビリティをつなぐ
エネがえるコーポレートPPA	日本	オフサイトPPA・複数拠点・市場連動	SaaS	PPA事業者、電力小売	電源・需要家・JEPXを見積へつなぐ
エネがえるAPI	日本	経済効果・料金・補助金等の組込	REST API	PdM、SIer、AIエージェント開発	自社サービスに判断ロジックを埋め込む

この比較で重要なのは、“発電量を精密に出すツール”と“導入判断を前に進めるツール”を混同しないことである。PVsystやSolarProは設計の深さに強い。Google Solar APIは屋根・地理空間の自動取得に強い。エネがえるは料金・補助金・蓄電池・EV/V2H・PPA・提案書・API連携に強い。ここを混ぜると、ツール選定を誤る。

4. 米国：NREL系モデルと商用SaaSが分厚い

米国の特徴は、NREL系のオープンな技術基盤と、Aurora、HelioScope、SolarAnywhereなどの商用SaaS/APIが分厚く存在することだ。

米国でよく見る構成

NSRDB / SolarAnywhere / Solcast
        ↓
PVWatts / SAM / PySAM / pvlib
        ↓
Aurora / HelioScope / PlantPredict
        ↓
金融モデル / PPA / CRM / 提案書 / API連携

PVWattsは初期検討やWeb API組み込みに向く。SAMは詳細な技術・金融分析に向く。pvlibは研究・独自モデル・検証に向く。AuroraやHelioScopeは設計・営業ワークフローに入りやすい。(NREL Developer Network)

米国型の強さは、発電量推計がAPI化・SaaS化・ワークフロー化されていることにある。
つまり、発電量が単なるExcelセルではなく、CRM、提案書、契約、施工、金融モデルへ流れていく。

日本でも、この思想はそのまま使える。
たとえば、Google Solar APIやNEDO系データから屋根・発電量を取り、エネがえるAPIで電気料金・補助金・蓄電池・EV/V2H・PPAの経済効果へ接続する。すると、発電量APIは単なる推計機能ではなく、提案生成APIになる。

5. 欧州：PVGIS、PVsyst、PV*SOL、Meteonormの“堅い”生態系

欧州は、PVGISのような公共性の高いツールと、PVsyst、PV*SOL、Meteonormのような設計・気象データの定番が強い。

PVGISはWebとAPIの両方で使いやすく、広域の初期評価に強い。PVsystは国際的な詳細設計・銀行向け評価で使われることが多い。PV*SOLは3D設計、影、蓄電池、EV、ヒートポンプなど建物側の統合設計に強い。Meteonormは世界各地の放射・気象データを扱う設計前提として使われる。(Joint Research Centre)

欧州型の学びは、公共データ・専門設計・建物統合設計が分業されていることだ。
日本で同じことをするなら、次の分担が現実的である。

公共・標準データ：NEDO METPV-20
詳細設計：SolarPro / PVsyst / PV*SOL
屋根・地理空間：Google Solar API / GIS / CAD
経済効果：エネがえるASP / Biz / EV・V2H / コーポレートPPA / API

ここでエネがえるを無理に“PVsystの代替”として語る必要はない。
むしろ逆だ。設計ツールの出力を、需要家の意思決定に翻訳するレイヤーとして置いたほうが価値が出る。

6. アジア・日本：NEDO、SolarPro、電気料金、補助金、販売現場が主戦場

日本の太陽光シミュレーションで特殊なのは、発電量だけでなく、電気料金制度・電力会社別プラン・補助金・低圧/高圧・自家消費・売電・蓄電池・EV/V2Hが商談の中心に入ることだ。

NEDOのMETPV-20は日本国内向けの標準的な日射量データとして使いやすい。エネがえるのFAQでも、発電量推計にNEDO METPV-20を用いる説明が示されている。(NEDO)

日本市場でよく起きる実務課題は次の通り。

課題	発電量ツールだけで解けるか	必要な追加レイヤー
年間発電量を出す	だいたい解ける	日射・方位・傾斜・損失
自家消費率を出す	不十分	需要家の30分値負荷
電気代削減額を出す	不十分	電気料金プラン、燃調、再エネ賦課金
蓄電池効果を出す	不十分	充放電制御、往復効率、劣化
EV/V2H効果を出す	不十分	走行距離、充電時間、ガソリン代、V2H運用
PPA単価を決める	不十分	需要家負荷、発電所、JEPX、市場連動、契約条件
稟議を通す	不十分	回収年数、CO2削減、リスク、比較表

つまり日本では、発電量シミュレーションは入口でしかない。
商談・稟議・契約に必要なのは、発電量を経済効果と説明責任に変換することだ。

エネがえるAPIは、住宅用、産業用、EV/V2H、電気料金、補助金といった領域をAPIで扱う方向へ拡張されているため、外部の屋根解析・発電量推計・AIエージェント・CRMとつなぐと、かなり実務的なアーキテクチャになる。(KKC)

7. 北欧：低太陽高度・積雪・アルベド・季節差が支配変数になる

北欧や寒冷地では、単純な年間日射量だけを見ると判断を誤る。
重要なのは、冬季の低太陽高度、積雪、アルベド、屋根勾配、雪の滑落、暖房・EV充電負荷との季節差である。

PVWatts V8ではアルベドや月別日射損失、日射・温度・風速などの入力/出力が扱われる。NEDO METPV-20でも積雪深や反射成分、傾斜面日射量の考え方が示されている。寒冷地では、このような補正を軽く見ないほうがよい。(NREL Developer Network)

北欧型・雪国型の実務では、次の比較が重要になる。

雪が多い地域で本当に見るべきもの
= 年間発電量
+ 冬季発電量
+ 積雪ロス
+ 屋根勾配
+ アルベド
+ 暖房・EV負荷との重なり
+ 蓄電池/V2Hのレジリエンス価値

この観点は、日本の北海道、東北、北陸、長野、新潟などにもそのまま効く。
雪国PVでは「発電量が少ないから不利」と一言で片付けるのは雑すぎる。冬季ピーク負荷、停電対策、EV/V2H、補助金、地域レジリエンスまで入れると、意思決定の絵が変わる。

8. 東欧・中東：広域ポテンシャル、銀行評価、過酷環境が論点になる

東欧や中東では、日本の住宅PVのような細かい営業提案よりも、初期ポテンシャル、土地、系統、PPA、金融、発電所設計、気候リスクが前面に出る。

東欧では、PVGIS、Global Solar Atlas、Solargis系データ、PVsystなどを使って、広域の発電ポテンシャルと銀行向け評価を進める構成が考えやすい。中東では、高温、砂塵、ソイリング、アルベド、両面パネル、冷却、O&M、水資源、系統接続が発電量とLCOEに効く。

PVWatts V8のようなAPIでも、ソイリング、アルベド、両面モジュール、気象データなどのパラメータは扱われる。PVsystやPlantPredictのような詳細設計ツールは、こうした大規模案件の検討に向く。(NREL Developer Network)

中東案件で重要なのは、日射量が高いことではなく、日射量の高さをどれだけ損失なく収益化できるかである。
高温でモジュール効率は落ちる。砂塵で発電量は落ちる。清掃にはコストがかかる。系統制約があれば売れない。PPA契約が弱ければファイナンスがつかない。

発電量シミュレーションは、この全体構造の入口にすぎない。

9. エンジニア向け：API連携アーキテクチャ

太陽光シミュレーションをサービス化するなら、次のような4層構造にすると破綻しにくい。

[1] Site Intelligence
住所、緯度経度、建物、屋根、地形、影、用途地域

[2] Solar Resource & PV Model
日射、気象、方位、傾斜、パネル、PCS、損失、発電量

[3] Load & Operation Model
需要家30分値、業種別ロードカーブ、蓄電池、EV/V2H、充放電

[4] Economics & Decision Model
電気料金、売電、PPA、補助金、CO2、回収年数、稟議資料

API構成イメージ

疑似コード：発電量レイヤーと経済効果レイヤーを分ける

from dataclasses import dataclass

@dataclass
class Site:
    latitude: float
    longitude: float
    roof_tilt: float
    roof_azimuth: float
    roof_area_m2: float

@dataclass
class PVSystem:
    dc_kw: float
    ac_kw: float
    module_type: str
    losses_pct: float

@dataclass
class LoadProfile:
    demand_30min_kwh: list[float]
    tariff_plan_id: str

def estimate_generation(site: Site, pv: PVSystem) -> dict:
    """
    PVWatts / PVGIS / SAM / pvlib 等に接続する層。
    ここでは発電量だけを返す。
    """
    return {
        "annual_ac_kwh": 12000,
        "monthly_ac_kwh": [800, 900, 1100, 1300, 1400, 1350, 1450, 1300, 1100, 950, 750, 600],
        "model": "pv_model_example",
        "weather_source": "example"
    }

def estimate_economics(generation: dict, load: LoadProfile) -> dict:
    """
    エネがえるAPI等に接続する層。
    発電量を、料金・自家消費・蓄電池・EV/V2H・PPAの判断に変換する。
    実運用では公式API仕様に従う。
    """
    return {
        "self_consumption_kwh": 8500,
        "export_kwh": 3500,
        "annual_savings_yen": 280000,
        "payback_years": 9.8
    }

ポイントは、発電量APIと経済効果APIを同じ関数に押し込まないことだ。
発電量モデルは物理に近い。経済効果モデルは契約・料金・制度・行動に近い。責任境界を分けたほうが監査しやすい。

10. YAMLで“再現可能な試算契約”を作る

太陽光シミュレーションで最も危険なのは、計算が間違うことではない。
あとから同じ条件で再現できないことである。

そこで、試算条件をYAMLやJSONで保存する。
これは、営業・CS・BPO・API・開発チームを同じ土台に乗せるための“試算契約”になる。シミュレーション条件を再現可能な契約YAMLとして持つ発想は、提案速度と監査性を両立させるうえで有効である。

scenario:
  id: "PV-SIM-2026-001"
  site:
    country: "JP"
    latitude: 35.681236
    longitude: 139.767125
    roof_tilt_deg: 20
    roof_azimuth_deg: 180
  pv:
    dc_kw: 50
    ac_kw: 40
    module_type: "mono_si"
    degradation_rate_per_year: 0.005
    system_losses_pct: 14
  weather:
    source: "NEDO_METPV20"
    year_type: "average"
  load:
    profile_type: "30min_csv"
    tariff_plan_id: "example_plan"
  battery:
    enabled: true
    capacity_kwh: 100
    output_kw: 50
    round_trip_efficiency: 0.9
  ev_v2h:
    enabled: false
  economics:
    capex_yen: 12000000
    opex_yen_per_year: 200000
    discount_rate: 0.03
    ppa_enabled: false
  audit:
    created_at: "2026-05-20"
    model_version: "v1"
    notes: "Example only. Use official API specifications in production."

このYAMLがあると、次のことができる。

同じ条件で再計算できる
料金改定時に差分だけ再試算できる
補助金変更時に再評価できる
BPO担当者と開発者が同じ前提を見る
顧客説明時に「前提条件」が消えない
APIレスポンスを監査ログ化できる

Qiita読者向けに言えば、これは単なる設定ファイルではなく、再エネ版のInfrastructure as Codeである。
設備、気象、料金、契約、制度、試算条件をコードのように管理する。ここまでやると、シミュレーションは「属人的なExcel」から「再現可能な意思決定システム」に変わる。

11. ツール選定の実務判断フレーム

目的別に選ぶ

目的	第一候補	補助候補	コメント
とにかく早く年間発電量を出す	PVWatts / PVGIS	Global Solar Atlas	PoCや初期調査向き
Pythonで独自モデルを作る	pvlib / PySAM	PVWatts API	研究・検証・内製向き
銀行・投資家向けPV設計	PVsyst	Meteonorm / Solargis	詳細設計・ファイナンス文脈
住宅屋根の自動提案	Google Solar API	Aurora / PV*SOL	住所→屋根→提案の自動化
C&I屋根・産業用設計	HelioScope / SolarPro / PVsyst	Google Solar API	図面・影・設計条件が重要
蓄電池・マイクログリッド	SAM / HOMER	pvlib / PySAM	制御・経済性まで見る
自家消費・電気代削減	エネがえるBiz	SAM / SolarPro	需要家負荷と料金が支配的
住宅PV・蓄電池・オール電化提案	エネがえるASP	Google Solar API / NEDO	顧客説明・成約支援向き
EV/V2H込みの提案	エネがえるEV・V2H	走行データ、充電データ	太陽光単体より生活・車両条件が重要
オフサイトPPA見積	エネがえるコーポレートPPA	SAM / JEPX / 発電量モデル	複数需要家・複数電源・市場連動が論点
自社Webサービス組込	エネがえるAPI	PVWatts / Google Solar API	発電量と経済効果を分担

判断軸は「精度」ではなく「責任境界」

ツール選定でよくある失敗は、全部を「精度」で比較することだ。

もちろん精度は重要だ。
しかし実務では、より重要な問いがある。

そのツールは、どの責任を持つのか？

日射データの責任
発電量モデルの責任
屋根・影データの責任
需要家負荷の責任
電気料金計算の責任
蓄電池制御の責任
PPA単価・粗利の責任
顧客説明・稟議資料の責任
API監査ログの責任

PVsystに電気料金プラン最適化まで期待するのは筋が悪い。
逆に、エネがえるにPVsyst級の詳細影解析そのものを期待するのも筋が悪い。

それぞれのツールの責任境界を分ける。
この設計ができる会社は、再エネDXでかなり強い。

12. よくある失敗パターン

失敗1：発電量だけで投資回収を語る

年間発電量が多い案件が、必ず良い案件とは限らない。
需要家の昼間負荷が小さければ余剰が増える。売電単価が低ければ経済効果は下がる。蓄電池を入れても、充放電ロジックが合わなければ回収年数は改善しない。

見るべきは、発電量ではなく、発電量が需要家の負荷と料金にどうぶつかるかだ。

失敗2：平均年だけで判断する

平均年は便利だが、稟議や金融では「悪い年にどうなるか」も見たい。
METPV-20でも平均年、多照年、寡照年の考え方が扱われる。これは単なる学術的な分類ではなく、リスク説明の材料である。

失敗3：影・積雪・汚れを“損失率14%”に丸める

初期検討では丸めてもよい。
だが、屋根形状が複雑、近隣建物がある、積雪地域、砂塵地域、樹木が多い、PCS容量が小さい案件では、丸めた損失率が判断を壊す。

PVWattsでも損失率、ソイリング、アルベドなどのパラメータが扱われる。雑に一括損失へ押し込むと、どの損失が支配的なのか見えなくなる。(NREL Developer Network)

失敗4：APIをつないだだけでプロダクトになったと思う

API連携は入口である。
本当に必要なのは、入力、例外処理、モデルバージョン、監査ログ、再計算、顧客説明、UI、料金、権限、エラー復旧まで含めた業務設計だ。

Google Solar API、PVWatts、エネがえるAPIをつなぐだけならPoCは作れる。
しかし商用サービスにするなら、以下が必要になる。

API利用規約と商用利用範囲
再販・データ保存・表示条件
入力不足時のフォールバック
住所ジオコーディングの失敗処理
屋根推定が不確かな場合の表示
発電量モデルのバージョン管理
経済効果試算の前提表示
顧客向けレポートの説明責任
料金改定時の再試算導線

13. エネがえるを絡めた実装アイデア

ここからは、エネがえるを“発電量ツールの競合”ではなく、発電量の先にある意思決定APIとして使う設計案である。

アイデア1：Google Solar API × エネがえるAPIで「屋根→経済効果」自動化

住所入力
  ↓
Google Solar APIで屋根・日射・影・設置可能量を取得
  ↓
PVWatts / PVGIS / SAM / NEDO系モデルで発電量推計
  ↓
エネがえるAPIで料金・補助金・自家消費・蓄電池・EV/V2H効果を試算
  ↓
顧客向け提案書・営業比較表・稟議メモを生成

この構成の価値は、屋根上ポテンシャルを「きれいな地図」で終わらせないことだ。
需要家が本当に知りたいのは、屋根の面積ではなく、電気代がどう変わるか、回収年数がどうなるか、家族や社内にどう説明するかである。

アイデア2：PVsyst / SolarPro × エネがえるBizで「設計→法人提案」連携

PVsyst / SolarPro
  ↓
詳細発電量・影・損失・設備条件
  ↓
エネがえるBiz
  ↓
30分値デマンド、自家消費率、電気代削減、回収年数、蓄電池効果
  ↓
法人向け提案書・稟議資料

産業用自家消費では、発電量が正しくても、需要家の負荷と合わなければ価値は出ない。
ここでエネがえるBizのような経済効果シミュレーションが効く。発電量設計の専門性と、需要家向けの経済効果説明を分担できるからだ。

アイデア3：EV/V2H × 太陽光で「家計・防災・移動」を統合

住宅用PVの提案では、太陽光と蓄電池だけを見ると価値を小さく見積もる場合がある。
EV/V2Hが入ると、夜間充電、昼間余剰、ガソリン代代替、停電時の給電、V2H放電など、評価軸が増える。

エネがえるEV・V2Hのようなレイヤーは、ここで使うと自然だ。
発電量を「車の使い方」と接続する。これは、従来のPVシミュレーションだけでは見えにくい価値である。

アイデア4：コーポレートPPAで「発電所 × 需要家 × JEPX」を束ねる

オフサイトPPAでは、単一の発電量だけでは足りない。

発電所A/B/C
需要家X/Y/Z
JEPX価格
固定単価 / 市場連動単価
託送・非化石・環境価値
粗利
契約期間

これをExcelで手作業管理すると、すぐに破綻する。
エネがえるコーポレートPPAのようなサービスは、複数需要施設と複数発電所、固定単価・市場連動・JEPX連動の試算をクラウドで扱う文脈に合う。(faq.enegaeru.com)

アイデア5：AIエージェントに“発電量だけでなく判断”を返す

AIエージェント時代には、単に「この屋根で何kWh発電します」では弱い。
ユーザーが求めるのは、こういう回答だ。

この条件では、5kWより7kWのほうが年間発電量は増えます。
ただし昼間負荷が小さいため余剰が増え、蓄電池なしでは回収年数が悪化する可能性があります。
料金プランAでは回収10.2年、プランBでは9.1年です。
EVを週5日夜間充電する場合、V2Hありのケースも比較してください。

この回答を出すには、発電量APIだけでは不足する。
必要なのは、発電量、負荷、料金、蓄電池、EV/V2H、補助金、PPAを統合した判断APIである。

14. 実務で使えるチェックリスト

発電量シミュレーション監査チェック

日射データの出典は明記されているか
データ年、代表年、平均年/多照年/寡照年の扱いは明記されているか
方位角・傾斜角は現地条件と合っているか
DC容量とAC容量を混同していないか
PCSクリッピングを見ているか
影ロスは一括損失ではなく根拠があるか
積雪ロス・汚れ・劣化を地域条件に応じて扱っているか
温度補正・風速・セル温度の前提は妥当か
月別・時間別の発電量が需要家負荷と照合されているか
経済効果試算で電気料金プランを正しく反映しているか
蓄電池の充放電量と往復効率を混同していないか
EV/V2Hの走行・充電・放電条件が明示されているか
PPAの場合、固定単価・市場連動・JEPX・託送等を区別しているか
試算条件をYAML/JSON等で再現可能にしているか

ツール選定チェック

初期調査なのか、詳細設計なのか
住宅なのか、産業用なのか、Utility-scaleなのか
屋根形状・影解析が必要か
API連携が必要か
顧客向け提案書が必要か
電気料金計算が必要か
蓄電池・EV/V2H・PPAが必要か
監査ログと再計算が必要か
商用利用・再販・データ保存の条件を確認したか

15. FAQ

Q1. 太陽光発電量シミュレーションで一番信頼できるツールはどれですか？

用途による。詳細設計や金融機関向け評価ではPVsystやSAM、初期推計やAPI組み込みではPVWattsやPVGIS、屋根上自動評価ではGoogle Solar API、需要家向けの経済効果・料金・PPA・EV/V2H接続ではエネがえる系サービスが向く。単一の“最強ツール”を探すより、責任境界で分けたほうがよい。

Q2. PVWattsだけで商用提案はできますか？

初期提案や概算には使いやすい。ただし、詳細な影、積雪、需要家30分値、自家消費、電気料金、蓄電池、PPA、補助金まで含める商用提案では、別ツールや独自ロジックとの組み合わせが必要になる。

Q3. PVGISとGlobal Solar Atlasはどう違いますか？

PVGISはPV性能計算ツールとしてAPI利用しやすい。Global Solar Atlasは世界中の太陽光ポテンシャルを俯瞰する初期評価に向く。どちらも広域評価に便利だが、個別案件の詳細設計や提案書生成では追加モデルが必要になる。(Joint Research Centre)

Q4. Google Solar APIはPVsystの代替になりますか？

代替ではない。Google Solar APIは建物・屋根・日射・影などの地理空間データ取得に強い。一方、PVsystはPVシステムの詳細設計・発電量評価に強い。組み合わせると、住所入力から屋根評価、発電量、経済効果までの自動化に近づく。

Q5. エネがえるは発電量シミュレーションソフトですか？

発電量推計も関係するが、中心価値はそこだけではない。エネがえるは、太陽光・蓄電池・EV/V2H・PPAの経済効果、電気料金、補助金、提案書、API連携など、導入判断を前に進めるレイヤーとして見ると分かりやすい。公式リリースでも、産業用自家消費型太陽光・蓄電池、EV/V2H/充電器、電気料金参照、補助金情報などへのAPI拡張が説明されている。(KKC)

Q6. 発電量精度を上げれば成約率も上がりますか？

必ずしもそうではない。発電量精度は重要だが、成約や稟議で詰まるのは、回収年数、料金プラン、補助金、蓄電池制御、PPA条件、説明資料の分かりやすさであることが多い。発電量精度と意思決定支援は別レイヤーとして設計すべきだ。

Q7. 産業用自家消費では何が一番重要ですか？

発電量そのものより、需要家の30分値デマンドとの重なりが重要になる。昼間負荷が大きければ自家消費しやすい。逆に、発電ピークと負荷ピークがずれると、余剰・逆潮流・蓄電池・PPA条件の検討が必要になる。

Q8. API連携で最初に作るべきものは何ですか？

最初に作るべきは、派手なUIではなく、試算条件の正本データ構造である。YAMLやJSONで、住所、設備、日射データ、負荷、料金、補助金、蓄電池、EV/V2H、PPA条件、モデルバージョンを保存する。これがないと、後から再計算できない。

16. まとめ：発電量シミュレーションの競争軸は「kWh」から「判断」へ移る

太陽光発電量シミュレーションは、もう単なる年間kWh計算ではない。

競争軸は、次のように変わっている。

昔：年間発電量を出せるか
今：日射・影・損失を妥当に扱えるか
次：需要家負荷・料金・蓄電池・EV/V2H・PPAへ接続できるか
未来：AIエージェントが監査可能な判断材料として再利用できるか

PVWatts、SAM、pvlib、PVGIS、PVsyst、PV*SOL、Google Solar API、Aurora、HelioScope、SolarPro、HOMER、RETScreen。
どれも強い。だが、強さの場所が違う。

そして日本の再エネ実務では、発電量だけでなく、電気料金、補助金、自家消費、蓄電池、EV/V2H、PPA、提案書、稟議、API連携が導入判断を左右する。ここに、エネがえるASP、エネがえるBiz、エネがえるEV・V2H、エネがえるコーポレートPPA、エネがえるAPIのような経済効果・意思決定レイヤーを置く意味がある。

最も筋の良い設計は、こうだ。

PVsyst / SolarPro / SAM / PVWatts / PVGIS / Google Solar API
= 発電量・屋根・影・設計のレイヤー

エネがえるASP / Biz / EV・V2H / コーポレートPPA / API
= 料金・補助金・自家消費・蓄電池・EV・PPA・提案・意思決定のレイヤー

発電量を出すだけなら、多くのツールでできる。
だが、顧客が発注し、社内稟議が通り、PPA単価が決まり、APIで再利用され、料金改定時に再試算できるところまで設計するには、発電量を判断可能なデータ構造へ変換する必要がある。

太陽光シミュレーションの本当の勝負は、そこから始まる。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up