住宅事業者のためのGX ZEH実務ガイド
住宅メーカーの商品企画・営業企画・IT・購買担当者向けです。
この記事でできること：5方式の違いを同じ成果物・費用範囲で比較し、採用前の確認表を作る。
先に決める6条件：欲しい機能より、止まる仕事
住宅向けの経済効果試算を整えるとき、最初の問いは「何を開発するか」ではありません。見積との二重入力が障害なのか、計算する人員が足りないのか、機器・料金更新を続けられないのかで、選ぶ方式が変わります。GX ZEH移行に向けた整備では、認定の判定と家計試算を分離したうえで、次の6条件を確定します。
| 条件 | 決める内容 |
|---|---|
| 使う人 | 営業、設計、商品企画、顧客自身のどこまで |
| 対象案件 | 新築・既築、住宅設備のみ・EVを含む、標準・例外 |
| 件数と繁閑 | 月平均だけでなく繁忙期の最大処理量 |
| 出力 | 提案書、比較表、自社画面、顧客公開値 |
| 連携 | 見積、顧客管理、商品マスターと共有する情報 |
| 保守責任 | 料金・制度・機器・計算条件を誰が更新するか |
ASP・API・BPO・独自開発を同じ物差しで比較
| 方式 | 向く状況 | 自社に残る仕事 | 先に確かめること |
|---|---|---|---|
| ASP | 担当者が画面から入力・比較・出力する | 入力、説明、適用範囲の判断 | 対象設備、出力、権限、契約範囲 |
| EV・V2H | 住宅と車両・充電を一体で提案 | 走行と在宅・接続の聞き取り | 車両、充電、V2H条件、住宅との比較 |
| API | 自社見積やWebへ計算を組み込む | 画面、認証、データ保持、承認、障害対応 | 入出力、制限、版管理、再現性、運用費 |
| BPO | 単発・複雑案件や担当不足 | 依頼条件の合意、結果の確認、施主説明 | 必要資料、修正回数、納期、成果物 |
| 独自開発 | 固有要件と長期運用能力がある | 計算検証、データ更新、UI、保守の全体 | 更新予算、専門人材、第三者検証、撤退方法 |
APIは「計算部分を外部へ任せる」選択肢であって、全ての業務システムが完成するわけではありません。ASPも、評価機関の認定審査や補助採択の判断を代替しません。BPOは業務を外部へ依頼できますが、現地施工や施主条件の確認主体は別途決めます。この境界を契約前に確認すると、導入後の期待のずれを減らせます。
3年間の費用は、ライセンスの外側まで計上
見積金額だけで比較すると、少額に見えた独自開発の保守や、安く見えた外注の修正調整が後から増えることがあります。ここでいう費用は、特定企業の実測ではなく評価すべき項目です。各社の見積と自社工数を入れ、同じ業務範囲・同じ期間で比べてください。
| 費用群 | 確認項目 |
|---|---|
| 初期 | 要件定義、導入支援、データ移行、画面開発、試験 |
| 毎月・毎年 | 利用料、API従量、データ更新、監視、教育 |
| 変更 | 制度・料金・設備変更、改修、出力様式の追加 |
| 例外と手戻り | 資料不足、再試算、差戻し、顧客への再説明 |
| 終了・移行 | 出力の持ち出し、再契約、他方式への切替 |
工務店への展開を考える際は、新築住宅の太陽光・蓄電池提案を工務店と進めるRTの事例も参考になります。開発方式だけでなく、誰が顧客へ説明するかを確認してください。
採用前に試す5つの場面
- 標準案件：必要な入力から期待する比較表まで作れるか
- 情報不足：仮定を明示し、追加資料で安全に更新できるか
- 条件変更：料金・機器・補助の版が変わったとき再現できるか
- 例外案件：EV、特殊な負荷、未対応機器をどこへ戻すか
- 中断・終了：障害時や契約終了時に結果と前提を持ち出せるか
結果が既存Excelと違うときは「一致しないから不合格」「新しいから正しい」とはしません。料金の定義、時間刻み、損失、FITの年度、入力値を分けて突き合わせます。差の理由が説明できず、顧客の判断が変わる場合は、提案へ転用する前に解消します。
公開用の簡易シミュレーターでは、東京ガスがASPで事前に複数条件を試算し、その結果を使う方法が紹介されています。この事例から、顧客画面を持つために必ずリアルタイムAPI接続が必要だとはいえません。更新頻度と条件数に応じ、事前計算も比較してください。東京ガスの方式を確認する
このテーマを、導入企業の現場から
提案基盤を、営業の現場でどう使う？
住宅の説明資料を変えた例と、メーカーが販売店の試算をそろえた例を比べられます。
エネがえるASP 活用事例アフターホーム導入後の受注4か月で10件以上手書きの説明から、見やすく根拠を示せる提案へ。取材時の回答では成約率50%。同社の営業体制・商談条件における実績。アフターホームの事例を読む 
エネがえるASP 活用事例オムロン ソーシアルソリューションズ現場での取り組み試算のばらつきを抑え、販売店支援を標準化取材時の取り組みを、担当者の声で紹介しています。オムロン ソーシアルソリューションズの事例を読む 数値・取り組みは各社の取材時点の事例です。作業範囲と条件はリンク先の本文で確認できます。
小さく始めて切り替えられる導入順序
少人数の試算で入力と出力が固まっていない段階では、ASPまたはBPOで代表案件の条件を整理する方法があります。営業が継続して入力するならASPで運用し、二重入力や公開画面が制約になった段階でAPIを比較します。固有の計算や独自の業務要件が十分にある場合は、独自開発・併用を含めて検討します。これは推奨する検討順で、全社へ適用できる固定ルートではありません。
導入方式の疑問
件数が多ければAPIが最適ですか？
件数だけでは決まりません。二重入力、画面統合、保守体制、利用料と開発費の合計、例外処理まで含めて判断します。
独自開発なら外部サービスより精度が高いですか？
開発主体だけで精度は決まりません。入力、データ、計算方法、検証、更新運用と対象範囲を比較する必要があります。
BPOで試してからASPへ移行できますか？
具体的な成果物の形式、利用範囲、移行条件を先に確認します。業務の前提をそろえてから継続利用方法を検討することは可能です。
根拠・確認範囲
確認日：2026年9月23日。制度は公表された一次資料、事例は公開インタビューを参照しています。工程、例、チェック項目は本記事の実務提案です。個別案件の適合・採択・効果を保証するものではありません。
コメント