DERとは？DR・VPPの仕組みと運用・事業者ガイド

導入の経済性と、運用の価値をつなぐ

DERの普及を考えるとき、設備を設置した量と、必要な時間に使える調整力を分ける必要がある。太陽光発電は天候、蓄電池は充電残量、EVは接続時間、給湯機は必要な湯量、空調は快適性に制約される。設備が増えても、その制約と契約条件を把握できなければ、約束できる供給力・調整力は増えない。

本稿の分析は、導入前の比較と導入後の運用を同じ条件でつなぐことを、普及の重要な実務課題と位置づける。経済効果試算は設備の購入判断だけに使うものではない。参加者の募集、適切な設備容量の選定、DR契約の比較、参加後の説明にも使える。ただし、試算だけで通信、制御、市場参加資格や顧客同意の問題まで解決できるわけではない。

最初に答えるべき質問は「この設備は市場でいくら稼ぐか」だけではない。「DRに参加しなくても、この家庭や施設に導入する理由はあるか」「参加すると何を差し出し、いくら純便益が増えるか」「期待どおりでない場合に、どの運用へ戻れるか」の3つを並べて判断する。

5つの言葉を役割で区別する

DER（Distributed Energy Resources、分散型エネルギーリソース）は設備・資源の総称である。発電する太陽光、蓄える蓄電池だけでなく、使う時間を変えられるEV充電、給湯、空調などの需要側資源も含めて考える。家庭のDERは、この考え方を住宅の設備と生活へ適用したものだ。

DR（デマンドレスポンス）は、価格や要請などに応じて電力需要を変える取り組みである。需要を減らす場面だけでなく、再エネ余剰時に需要を増やしたり、別の時間へ移したりする場面もある。VPP（仮想発電所）は複数の資源をまとめて運用する仕組みであり、設備の名称ではない。

DERMS（Distributed Energy Resource Management System）は分散した設備の状態把握、制約管理、運用計画や制御連携を担うシステムの総称である。製品によって、配電系統との連携を重視するもの、需要家設備の制御を重視するもの、市場運用を組み合わせるものがある。「DERMS対応」という一語だけでは、実現できる業務を判断できない。

アグリゲーターは資源を集約してサービスを提供する事業者である。ソフトウェアを購入することと、誰かに運用・取引を委託することは別の契約になる。見積もりでは、設備所有者、制御の受託者、取引を行う者、結果を精算する者を区別して記載する。

参考：FERCのDER集約解説、エナリスのDERMSを核とするVPPサービス説明。FERCの制度は米国向けであり、日本の参加条件を定めるものではない。

日本市場の課題を、設備・契約・データから解く

設備ごとの採算が、同じものさしで比較されていない

太陽光の提案は年間発電量、蓄電池の提案は容量、給湯機の提案は効率、EVの提案は走行費というように、別々の指標から始まりやすい。しかし顧客が判断したいのは、同じ生活や生産を維持したときの総支出と、停電や価格変動への備えである。まず比較期間、需要、電力・ガス契約、設備更新の時期をそろえる。

既設給湯器が故障して交換が必要な案件と、まだ使える設備を前倒しで交換する案件では、比較対象が違う。前者は通常交換との差額、後者は前倒しによる追加負担と残存価値も見る。蓄電池やV2Hについても、既に導入する太陽光やEVの効果を、追加設備の効果として重複計上しない。

年間の電力量だけでは、同時に使える余力が見えない

年間の発電量と消費量が一致しても、昼の余剰と夜の不足は残り得る。月額料金が似た2軒でも、在宅時間や給湯の時刻が違えば蓄電池の使い方は変わる。初期相談では月別使用量からの推計が役立つが、設備容量やDRの約束量を決める段階では、実測と推計の区別を保ち、時間帯別の条件を精査する。

30分値が得られても、それがそのまま機器別の消費ではない。家全体・施設全体の受電点、蓄電池のAC側、車両の電池側など、測定境界を明記する。買電の減少が、蓄電池の放電によるのか、生産や在宅状況の変化によるのかを分けなければ、効果の説明は不安定になる。

制度上の入口と、顧客が契約できるサービスは別である

制度があること、対応機器があること、事業者が受託すること、対象エリアで通信・計測・審査を満たすことは別の確認事項である。「低圧が参加できる」という説明を、すべての家庭用蓄電池が直ちに収益を得られるという営業説明へ広げてはいけない。

設備を選ぶ前に、候補事業者へ対象エリア、電圧区分、型番、接続方式、受電点か機器点か、受託開始時期、契約期間を照会する。回答が一般論なら、見積もりの収益欄を確定値にしない。制度の改定があっても機器の保証や小売契約が自動で変更されるわけではない。

参加を続けられる条件を、最初の提案で見えるようにする

家庭では湯切れ、室温、出発時の充電残量が優先される。工場では品質、歩留まり、操業計画、安全が優先される。制御を解除する権利、通知の方法、参加を見送る条件を初期提案に含めると、導入後に初めて負担が判明する事態を減らせる。

解決課題は「制御できる機器を増やす」ことだけではない。顧客が納得できる契約、測定できる実績、利益が残る業務、問題時に戻れる運用を合わせて設計する。これが、本稿で経済効果試算をDER普及の基盤として扱う理由である。普及を説明する唯一の原因だという実証結果を示すものではない。

政策・審議会資料を事業判断へ翻訳する

2026年9月22日に確認した制度資料

EPRXの公表ページには、2026年6月18日掲載・同年7月1日実施の取引規程、取引ガイド第10版、2026年7月31日更新の起動費等の事後精算関連資料が掲載されている。掲載日と適用日を分け、見積もりや運用手順がどの版に基づくかを残す。EPRX・取引規程等

OCCTOの小委員会ページには、2026年6月2日更新として今後の要件変更等の資料への案内がある。リンク先の第60回資料3は、機器個別計測、2026年度以降の課題、制度検討作業部会での議論を整理している。特高の機器点についても次世代スマートメーターや関連システムの準備に応じた時期の扱いが示されており、制度開始と個別案件の利用開始を分けて読む必要がある。OCCTO小委員会／第60回資料3

同資料は、第110回制度検討作業部会（2026年1月23日）の議論も参照している。調達量や上限価格の見直しが事業の収入前提に影響し得ることを読むための入口になる。ただし、この参照だけで9月時点の全改定を確認したことにはならない。経産省・第110回資料4

「決定」「実施」「見通し」を分ける読み方

審議会資料に将来の方向性が書かれていても、現在の取引規程や公募要領へ直ちに反映されるとは限らない。各論点を、①問題提起、②方向性の整理、③規程・要領への反映、④適用開始、⑤個別案件での利用可能、という5段階で管理する。この分類は本稿の実務上の整理であり、行政の正式な区分ではない。

事業計画では、実施済みの条件を基本ケースにし、将来の制度変更は別シナリオに分ける。開始時期が遅れた場合の通信費、待機費用、借入利息、運用の代替案を計算する。「参加できるようになる予定」を前提に設備を先行取得するなら、誰がその待機リスクを負うかも契約で確認する。

政策情報を追うときの6つの質問

1. どの機関の、何回の会合・何番の資料か。議事録と配布資料で位置づけは一致しているか。
2. 対象は家庭、需要家併設、系統用のどれか。電圧区分や設備の条件は何か。
3. 公表日・適用日・経過措置はいつか。旧契約と新契約で扱いが違うか。
4. 通信・計測・認証・システム改修は誰が用意し、誰が費用を負担するか。
5. 売上、費用、保証、違約、データ保存のどこが変わるか。
6. 改定前提が変わったときに、誰が顧客と運用担当へ知らせるか。

補助金とDR契約を一つの採算表で混同しない

補助金は設備費の負担を変える。DR契約は運用の収支と義務を変える。採算表では、補助なし、採択を条件とする補助あり、DR参加ありの差を別々に表示する。設備が登録リストにあることと、個別申請が採択されることも別である。

申請前には、契約・発注・着工の許される順序、併用条件、必要書類、処分制限、遠隔制御や報告の義務を確認する。営業担当が受付期間だけを見て案内すると、先行発注や契約条件の違いで利用できなくなることがある。SIIの事業・公募情報から対象事業の要領へ進み、受付状況と条件を照合する。

ベンダー比較は、役割と確認事項をそろえて行う

ソフトウェア、アグリゲーション受託、機器、導入前の試算は異なる調達対象である。以下は公開説明から役割を比較するための入口であり、ランキング、独立性能試験、全製品の網羅表ではない。海外サービスの掲載は、日本国内での受託や同一仕様の提供を意味しない。確認日は2026年9月22日。

エナリス：国内のVPP基盤・運用支援を検討する

公式にはDERMSを核とするSaaSのVPPプラットフォームを説明し、分散型電源の遠隔制御や取引代行などを案内している。比較時には、自社がリソースアグリゲーターとして担う範囲と、委託する範囲を分ける。照会項目は対応型番、通信方式、対象市場、障害時の代替運用、SLOと契約上の責任の違いである。公式サービス

デジタルグリッド：低圧系統用蓄電池の運用受託を検討する

2026年9月8日の公式発表は、低圧系統用蓄電所の受電開始と、今後100カ所を束ねる計画を示す。全100カ所の商用運転完了と読み替えない。比較では、対象PCS・EMS、接続試験、運用開始条件、受電開始から市場収入発生までの手順、拠点を追加する際の費用を確認する。公式発表

EnergyHub：多様な家庭設備を束ねる仕組みを学ぶ

Edge DERMSとして、サーモスタット、蓄電池、EV、商工業向けのプログラムを案内している。日本向けに参考になる比較軸は、設備接続だけでなく、顧客募集、参加継続、異なる機器の一括運用をどう設計するかである。国内対応、顧客同意、型番別の機能差、機器メーカーのクラウド停止時の扱いは別途確認が必要だ。公式説明

Kraken：家庭設備と顧客サービスを一体で考える

Residential Flexibilityでは家庭の設備群を接続・最適化する考え方を提示している。比較時には、電力小売の顧客基盤との接続、対象機器、参加者への価値の分配、料金変更時の動作を照会する。グローバルな機能紹介を、そのまま日本の各小売プランや各型番で使えると解釈しない。公式説明

Next Kraftwerke：取引・計画・調整力を分けて比べる

公式には電力取引、運転計画、調整力をサービスとして案内している。柔軟性を取引に変える設計を学べる一方、欧州の市場単位、参加条件、契約形態を日本へそのまま移植することはできない。収入の見込みを比べる場合は、対象期間、リスク負担、固定報酬か成果連動か、設備劣化の扱いをそろえる。公式説明

Sympower：産業需要と蓄電池の運用分担を比較する

BESS、産業DR、BRP向けの柔軟性サービスを説明している。参考になるのは、設備接続、最適化、運転指令、市場取引という業務を一体で評価する視点だ。工場への導入では、運転停止の権限、生産制約を更新する頻度、復帰時の負荷、設備保全担当との責任分界を確認する。公式説明

Statkraft：再エネの販売計画と柔軟性の価値をつなぐ

公式VPP説明では、分散した発電をまとめ、取引基盤Statkraft Unityを通じて計画する役割を示している。日本の検討では、発電量予測、販売契約、蓄電池、需要側の制約をどう結ぶかが比較対象になる。公表容量や市場規模の大小だけで、自社設備の手取りが大きいと判断しない。公式説明

Tesla：機器と参加プログラムの条件を同時に読む

Powerwallを含むVPPの案内は、機器購入とプログラム参加を分けて確認する必要性を示す。比較対象はバックアップの確保、参加を見送る操作、報酬、対象地域、電力契約との関係である。海外の参加条件や支払額を、日本向け製品の確定収益として表示しない。公式参加案内

エネがえるAPI：導入前の比較と顧客説明を組み込む

需要・発電・設備利用・料金などの計算を、Webや営業システムから利用する層である。DERMSや市場取引の受託と同じ役割ではない。候補設備を比較し、その条件を運用側へ引き継ぐ構成を設計できる。費用や回収期間の集計、画面、顧客同意、CRM、実機制御などは、提供範囲と組み込み側の担当を分けて確認する。公式APIポータル／公開仕様

比較依頼に添える共通質問票

候補各社には同じ設備条件と同じ需要データを渡す。最初に、受託可否・除外条件・担当範囲の3点を回答してもらい、その後で価格と性能を比較する。未回答を「対応可能」と補完しない。

1. 契約主体、設備所有者、制御主体、取引主体、精算主体は誰か。
2. 対応エリア、電圧区分、型番、ファームウェア、既設機器の条件は何か。
3. 計測点、データ粒度、遅延、欠測の扱いは何か。
4. 生活・操業の優先条件と、参加を見送る操作は何か。
5. 対応する市場・メニューと、必要な事前審査は何か。
6. 入札・指令・実績・精算の証拠を利用者が取得できるか。
7. 初期費、固定費、従量費、成果報酬、通信費をどう分けるか。
8. 未達・通信断・制御失敗の費用と責任は誰が負うか。
9. 蓄電池の劣化、保証、充放電回数・量の上限はどう扱うか。
10. 料金改定、制度変更、契約終了時に条件とデータを引き継げるか。
11. テスト環境、接続試験、切戻し、運用訓練は見積もりに含むか。
12. 自社と同条件の導入例は、実証・商用・計画のどれか。

経済効果試算のボトルネックを分解する

入力をそろえる負担

月別料金だけ、使用量だけ、PDF請求書だけという案件を同じ詳細度で扱うと、どこかで推測が混ざる。まずデータを「実測」「請求書から転記」「顧客申告」「標準値で補完」に分ける。比較画面には結論を変え得る補完条件を表示し、詳細提案へ進む際に置き換える。

入力項目を減らすことは、内部の仮定まで消すことではない。簡易診断の結果から詳細見積もりへ進む際に、何が追加で必要になるかを示す。月額料金から使用量へ換算するなら、料金プラン、基本料金、調整単価による違いが残るため、実際の使用量が得られた時点で再計算する。

料金と設備条件の更新負担

同じ設備・使用量でも、料金単価、燃料費調整、再エネ賦課金、契約容量、売電条件が違えば効果は変わる。提案書に年間削減額だけを残すのではなく、計算日、料金条件、設備仕様、比較対象をひと組で保存する。年度や料金が変わった際に、その案件だけを再評価できる状態が望ましい。

比較の分母が揺れる問題

太陽光＋蓄電池案を現状と比較すると、太陽光の効果と蓄電池の効果が合算される。蓄電池の追加判断では太陽光のみとの比較が必要だ。EV＋V2Hでは、EVの走行費削減とV2Hの住宅への給電効果を分ける。エコキュートでは、ガス給湯器の通常交換と比較するか、既設機の継続使用と比較するかを先に決める。

収益だけが先に示される問題

DRの報酬から、追加の充電費、売電機会の減少、変換損失、劣化に対する費用、手数料、通信費、現場対応費を差し引く。同じ費用をすでに料金シミュレーションで含めている場合は、別欄でもう一度引かない。DRに伴う追加運転を含めた料金比較を行う方式と、DR追加費用を別積みする方式のどちらかに統一する。

営業から運用への引継ぎが切れる問題

販売時に「停電用に残す」と説明した残量が、運用担当の設定へ伝わらなければ、試算と運用は一致しない。提案時の最低残量、EVの出発時刻、給湯の必要量、工場の運転禁止時間帯を、契約と設定確認の両方へ引き継ぐ。試算APIの出力だけで完結せず、人が承認した制約条件を記録する設計が必要である。

APIの現行仕様から、実装できる範囲を読む

確認した版と更新履歴

2026年9月22日、公開仕様の画面で「エネがえる共通 公開用 API 1.0.0 / OAS 3.0」を確認した。表示された更新履歴の最上段は2026年8月25日である。以下はその画面で確認した範囲であり、APIの実呼び出しや契約上の提供条件の確認を行った結果ではない。現行公開仕様

2026年3月2日には設備導入シミュレーションと太陽光発電量計算、8月5日にはガス推計・電気換算・給湯試算・ガス料金計算、8月19日にはガス事業者・プラン取得などの追加が記載されている。8月25日の改訂では、給湯・調理の電化と、残るガス需要の扱いが明確にされている。

太陽光・蓄電池の導入前後を比べる

usepowercalcで需要推計、pvpowercalcで発電量計算、equipsimulationで設備利用、epchargecalcで電気料金を計算するという構成が考えられる。実測需要がある場合の入力方法や対象期間は各スキーマへ照合する。設備候補の組み合わせ、売電収入、導入費、維持費、回収期間などの集計は組み込み側の評価設計と分ける。

equipsimulationの公開説明には、PCS・蓄電池条件、充放電時間帯、目標ピーク値などが記載されている。出力例には買電、自家消費、余剰、蓄電池残量などがある。これを実機への制御指令や、任意のDRイベントに対する市場適合判定が自動で得られる仕様だと解釈しない。

エコキュートを含む電化と、残るガスを評価する

applianceprofileは、ガスから電気へ換算した月別電力量を機器の動作パターンに基づく30分時系列へ展開する説明となっている。タンク容量、月別の定格出力、給湯消費パターンなどを考慮する。出力を設備導入シミュレーションへつなぎ、太陽光・蓄電池と組み合わせた比較を設計できる。

2026年8月25日改訂では、暖房はこの電化シミュレーションの対象外であり、暖房分のガスは残ガスへ計上する。monthly_gasを入力した場合のremaining_gas_monthlyはm³の形式で返し、gaschargecalcへ渡せる説明がある。給湯を電化しただけでガス料金がすべてゼロになる画面を作らないことが重要である。

また、cookerとhotwaterは整数の0または1であり、真偽値を渡す実装とは区別する。仕様にあるサンプル値は機器性能や標準的な家庭の実績を示すものではない。型番固有の実機制御、外部DRイベントとの連携、湯切れ回避の保証は、別途条件を照合する。

市場連動料金は、将来価格の予測ではない

epchargecalcでは、市場連動プランについて前月までの最新12か月のエリアプライスの同月を使う説明があり、day_purchaseは48要素が必要とされている。この計算を翌日の市場価格予測や、将来のDR収益予測として表示しない。

請求書との比較では、料金プランだけでなく、対象年月、曜日・祝日、調整単価、再エネ賦課金、容量拠出金などの扱いをそろえる。公開説明には、再エネ賦課金についてrenewableUnitsで月別指定する方法もある。現行単価での比較と、過去の請求額を再現する検証を別のテストにする。

補助金APIは候補の抽出から使う

公開仕様には補助金一覧GET /sys/subsidyと詳細GET /sys/subsidy/{id}がある。地域・設備分類・対象区分などから候補を探し、原典の確認へつなぐ入口として設計する。検索結果にあることを、予算残額、併用可否、採択、申請代行の保証と混同しない。

DER向けAPIの6つの具体的ユースケース

以下は公開機能を起点とした連携設計案である。すべてが既製品として提供されること、特定DERMSとの標準接続、制御性能や収益を保証するものではない。

1. 販売施工店：太陽光・蓄電池・給湯を同じ前提で比べる

顧客の月別電気・ガス使用量、太陽光の条件、候補設備を入力し、現状、通常交換、電化、太陽光併設、蓄電池追加を比較する。画面は「年間の光熱費」「初期費用の差」「残るガス」「停電時に使える設備」を分ける。簡易診断の条件をCRMに保存し、現地調査後に差し替えて再計算する。

最初の検証は、既存の提案案件で手作業の比較と条件をそろえて行う。計算時間だけでなく、再入力、条件確認、修正提案の往復まで計測する。導入件数の増加は別の評価指標とし、作業時間が減ったから成約率が上がると断定しない。

2. 電力小売：料金提案と柔軟性サービスをつなぐ

会員の同意を得た需要データから、設備あり・なし、充電時間帯、料金プランの候補を比較する。料金APIで計算する部分と、自社の充電スケジュール作成・機器制御を分ける。料金メリットだけでなく、価格変動への感応度と参加を見送る条件を表示する。

顧客に示す基本便益と、小売側の調達費削減を同じ金額として二重に数えない。参加者への還元、プログラム運営費、設備接続費を差し引き、顧客と事業者それぞれに継続可能な条件があるか確認する。

3. アグリゲーター：参加候補を採算と制約で選別する

設備リストの公称容量だけで募集対象を決めず、利用時間、最低残量、通信、契約、追加費用を含む案件台帳を作る。試算APIは設備の基本経済効果や料金条件の整理に使い、DR実効容量や市場向け入札量の評価は運用側で行う。候補の順位は収益だけでなくデータの確かさと参加継続性も含める。

募集後の辞退理由、接続失敗、設定変更、参加回避の頻度を保存すると、販売段階の仮定がどこで崩れたか分かる。予測を当てるだけでなく、どの案件を対象外にしたかも記録することが、過大な容量見積もりを防ぐ。

4. 工場・施設：蓄電池と操業条件を一緒に評価する

30分需要、太陽光、休日・季節別の操業、契約条件から候補容量を比較する。デマンド抑制のために確保する残量と、DRへ提供する余力を同じ時間帯で競合させない。基本料金への影響は契約に即して評価し、年間平均の削減だけで説明しない。

PoCでは「生産に影響しない」ことを抽象的な前提にせず、温度・圧力・稼働率・停止禁止時間などの条件へ置き換える。現場担当が参加を拒否できる状態を保ち、拒否されたイベントを実績評価から都合よく除外しない。

5. EV・V2H：出発を守る容量から経済性を評価する

車両の電池容量を住宅へ使える量とみなさず、帰宅時残量、次の走行に必要な量、充放電能力、接続時間を条件にする。EVの走行費比較、普通充電に対するV2Hの追加効果、V2G参加による追加純便益を別々に表示する。

料金情報の参照・計算と、車両・充電器の実制御は別の役割である。パナソニックの公開事例は、料金計算・単価参照を充電サービスへ利用した例であり、V2G収益や全車種の双方向制御を証明する事例ではない。2025年6月9日公表の事例

6. 自治体・金融：補助と資金調達の前に、比較条件をそろえる

地域・設備から補助候補を抽出し、設備費、自己負担、借入条件、維持費を別々に記録する。補助なしでも成立する案、補助採択が前提となる案、運用収益が一定以上必要な案を分ける。予算が終わった場合に提案を差し替える判断も可能になる。

地域全体の便益と個別家庭の便益は別に評価する。電力系統への貢献、非常時の拠点確保、導入負担の公平性などを政策KPIにする場合も、事業者から家庭へ支払う報酬を社会全体の便益として再度加算しない。金銭移転と追加的な資源節約を区別する。

試算から運用へ渡すデータの設計

顧客情報を大量に連携すればよいわけではない。まず案件ID、設備条件、同意の範囲、比較に必要なデータ、生活・操業制約を分ける。運用に不要な個人情報を計算ログへ含めず、連携先ごとに必要な項目を定義する。

入力には、データの出所、対象期間、タイムゾーン、時間粒度、単位、欠測率、補完方法を付ける。出力には、入力版、計算日時、使用した料金条件、シナリオ、計算結果と除外条件を対応させる。APIが標準で返す項目と、組み込み側が保存する管理項目を区別する。

導入前の試算値、契約時の約束、運用計画、実績、精算の5つは別の記録として保持する。試算値を実績で上書きすると、どの仮定が外れたかを検証できない。実績を蓄積した後は、生活・操業の変化、天候、料金改定、設備故障などを分解して再評価する。

エラー時に直前の結果を新しい結果として表示しない。入力の不備、通信の失敗、認証の期限切れ、計算できない条件を分け、再試行の回数と利用者への表示を決める。APIキー等の認証情報は組み込み側のサーバーで管理する構成を基本とし、ブラウザーへ露出させない。

検証計画：数字が合うことと、役に立つことを両方確かめる

第1段階：同じ条件で再現できるか

実測と推計を分けた少数の代表案件で、入力期間、料金、機器設定をそろえる。計算結果を既存の検証済み手順と照合し、差が出たら先に条件差を調べる。許容差は結果を見てから決めず、用途と精度要求に応じて事前に合意する。

第2段階：提案の判断が変わるか

導入しない案を含めて比較し、どの条件で推奨案が変わるかを見る。料金、設備費、売電、利用時間、充放電の損失、維持費などを一つずつ変える。極端に有利な条件だけを選んだ算例を、その地域や顧客全般へ広げない。

第3段階：実運用の制約へ引き継げるか

家庭なら最低残量と給湯・室温・出発、施設なら生産と安全、系統用なら接続条件と運用制約を確認する。制御の受託者に引き継ぐ項目、変更を承認する者、参加を中止する条件を明記する。導入前の経済評価が成立しても、運用試験が不合格ならDR収益を確定扱いしない。

第4段階：費用と説明責任が継続できるか

月間の試算件数だけでなく、データ整備、問い合わせ、例外処理、改定対応の時間を測る。成果は、試算完了率、再入力率、提案までの日数、仮定の開示率、導入後の差異説明率などで追う。成約・利益・参加継続率は、顧客層や販売方法の変化も影響するため、単純な前後比較だけでAPIの因果効果と断定しない。

経済効果の説明で起きやすい8つの誤り

1. 蓄電池の公称容量を毎日すべて使える量とする。実効容量、残量確保、効率、出力、時間を分ける。
2. 太陽光の自家消費と売電を同じ電力量へ同時に計上する。電力量の行き先を一致させる。
3. 蓄電池へ充電した量と住宅へ届いた量を同じにする。測定境界と損失をそろえる。
4. 蓄電池のピーク抑制とDR放電を同じ時間の同じ余力へ重ねる。運用計画上の競合を確認する。
5. エコキュートの消費を減らした時間だけ評価し、後の沸き増しを落とす。復帰を含む期間で評価する。
6. EVの走行費削減をV2Hの追加便益にも加える。車両導入と給電設備の差額を分ける。
7. 補助金を確定収入として扱い、申請条件や予算終了を無視する。条件付きと確定を分ける。
8. DR報酬を顧客便益と社会便益の両方へ足す。移転と追加的な資源節約を分ける。

最初の技術相談に必要な情報

仕様書をすべて読み終える前でも、相談の論点は整理できる。利用者が家庭・営業・運用担当のどれか、何を比べたいか、手元にあるデータ、対象設備、必要な出力、月間件数、既存システムを一枚にまとめる。

「DERをやりたい」から一段具体化して、「太陽光のみと蓄電池追加を同条件で比較し、その制約を運用受託者へ引き継ぎたい」「給湯電化後の残ガスを含めて比較したい」「EV充電の料金を自社アプリに表示したい」と書くと、API・完成済みの試算画面・試算代行のどれが合うかを判断しやすい。

完成済みの画面で提案するなら、家庭向けはASP、施設向けはBiz、車両と住宅の組み合わせはEV・V2Hが検討の入口となる。自社サービスへ計算を組み込むならAPI、入力整備や試算作業を外部へ依頼するならBPOという選び方ができる。機器制御や市場運用は、担当する事業者・システムと責任を分けて構成する。製品・サービス一覧／APIの用途・仕様・相談