燃調費、再エネ賦課金、消費税は反映されていますか？ – エネがえるASP・API（電気料金プラン、太陽光・蓄電池シミュレーション）

燃調費、再エネ賦課金、消費税は反映されていますか？ – エネがえるASP・API（電気料金プラン、太陽光・蓄電池シミュレーション）

結論から言うと、エネがえるの試算には燃調費、再エネ賦課金、消費税は反映されます。

ただし、ここで思考を止めると実務では詰まります。本当に重要なのは「入っているか」ではなく、「いつの単価を、どのルールで、どのプロダクトに、どこまで自動反映しているか」です。少なくとも2026年3月15日時点で公開されているエネがえるFAQ・マニュアル・API仕様書を読む限り、2024年10月の仕様変更以降は、燃調費と再エネ賦課金の扱いを“最新月単価ベースで12か月へ反映する”方向に整理して読むのが現行理解として安全です。^{[5][6][7][10]　（※ただし任意の単価を反映できるカスタムプラン機能もリリースしているためより柔軟に前提条件の定義が可）}

この違いは、提案の信頼性に直結します。顧客が本当に見ているのは、発電量の小数点第2位より、請求書の合計額とその内訳です。営業は説明責任を求められ、開発は実装責任を問われ、CSは差異説明を背負います。

だからこの記事では、制度の基本、エネがえるの現行仕様、ASP/Biz/EV・V2HとAPIの差、顧客説明のコツ、ズレが出る典型パターンまでを一つの判断軸で整理します。

• 反映されるもの：燃調費、再エネ賦課金、消費税
• 現行の焦点：2024年10月以降の公開情報では、最新月単価の反映が主軸
• APIの注意点：basemonth の扱いを曖昧にすると差異説明で詰まりやすい
• 顧客説明の要点：「反映有無」より「反映時点」「更新タイミング」「比較条件」を先に示す

この記事は、エネがえるASP/Biz/EV・V2Hを使って提案書を作る営業・設計担当、自社Webや見積システムへエネがえるAPIを組み込むPdM・エンジニア、そして顧客の請求書と試算結果の差を説明する立場の人に向いています。

逆に、電気料金の一般論だけを知りたい人にはやや実務寄りです。その代わり、読み終えるころには「何が反映されるのか」だけでなく、「なぜその反映方法が採られているのか」「どこからを自動化し、どこからを運用で補うべきか」まで見通せるはずです。

電気料金の「ズレやすい3要素」を先に分解する

まず、電気料金の構造そのものを短く整えます。資源エネルギー庁は、一般的な電気料金を「基本料金＋電力量料金＋再エネ賦課金」で説明しています。さらに、多くの料金メニューでは、火力燃料価格の変動を自動で反映する燃料費調整の仕組みが組み込まれています。つまり、請求書は最初から“固定費だけでできている”ものではありません。^[1][2]

燃料費調整が厄介なのは、毎月動くからです。資源エネルギー庁の説明では、大手電力の規制料金では、原油・LNG・石炭の価格変動をもとに、各月の3〜5か月前の貿易統計価格を反映して毎月の電気料金へ自動調整します。しかも、規制料金には上限の考え方もあります。ここを見落とすと、「先月の請求書」と「今この瞬間の比較提案」を同じ土俵で語ってしまい、説明が崩れます。^[2]

再エネ賦課金は、燃調費とは別の時間軸で動きます。経済産業省は2025年度の賦課金単価を1kWhあたり3.98円と設定し、2025年5月検針分から2026年4月検針分まで適用すると公表しています。一般的な400kWh/月の需要家モデルでは月1,592円、年19,104円です。毎月は動かないので軽く見られがちですが、年額で見ると存在感は小さくありません。太陽光・蓄電池の経済効果を語るとき、この一行を抜くと「買電削減の価値」を過小評価しやすくなります。^[3]

そして消費税です。国税庁の案内では標準税率は10%です。電気料金や設備費、比較表、長期シミュレーションの累計額を並べるとき、設備だけ税込で光熱費だけ税抜、あるいは逆、という混在が起きると数字は簡単に歪みます。現場で起きているズレのかなりの部分は、実はロジックの誤りではなく、比較条件の不一致です。^[4][11]

ミニコラム：やさしく言い換えると

航空券を本体価格だけで比べると、燃油サーチャージや税で「思ったより高い」が起きます。電気料金もそれと同じです。基本料金と従量料金だけで太陽光や蓄電池の経済効果を語るのは、航空券の本体価格だけで総額を判断するのに近い。しかも、電気料金の追加要素は毎月または毎年度で動きます。だから、提案書の信頼性は「全部入りで計算したか」と「いつの単価で計算したか」の二段で決まります。

エネがえるの答えは「反映される」。ただし、そこで思考を止めない

公開FAQの短い答えは明快です。燃調費、再エネ賦課金、消費税はエネがえるの診断結果に反映されます。ここは、検索で最初に答えるべき論点です。記事冒頭で結論を曖昧にしない方がよい理由もここにあります。「反映されています」が出発点であり、読者はその先にある“どう反映されるのか”を知りたいのです。^[5]

しかし、現場で本当に効くのは次の一段です。別FAQと仕様変更告知を見ると、2024年10月1日以降は、ASP、Biz、EV・V2H、APIなどで、最新月の燃調費単価と再エネ賦課金単価を12か月分の推計電力消費量へ反映する考え方へ整理されています。元稿に残っていた「入力済みの月をたどって基準月を決め、その月以前の同月単価を当てる」説明は、現行の公開情報とそのまま並べると読者を混乱させます。^[6][7]

ここでの重要な洞察は、仕様変更の核心が“数式を複雑にすること”ではなく、“説明可能性を上げること”にある点です。変更理由としてFAQが挙げているのは、「実際の電気料金とのズレ」「検算しづらい」「単価反映基準のズレ」です。つまり、エネがえるが最適化しようとしているのは、単なる内部計算の気持ちよさではなく、営業現場・顧客説明・検算の摩擦を減らすことだと読めます。^[7]

これは、シミュレーションの哲学の話でもあります。あなたは何を最適化しているのでしょうか。履歴の忠実再現でしょうか。今この瞬間の提案判断でしょうか。それとも、顧客が納得できる比較説明でしょうか。エネがえるの現行公開仕様は、少なくとも提案と説明のしやすさに重心を寄せています。その前提を理解して使うか、知らずに使うかで、提案の説得力は大きく変わります。

ASP・Biz・EV・V2Hで押さえるべき現在の見方

ASP系の理解は、少なくとも公開FAQと共通マニュアルベースではかなり整理できます。まず、料金プラン照会では、選択したプランに適用される最新（照会実行時の前月）の燃調費・賦課金単価が表示されます。ここは現場担当にとって大きいポイントです。いま画面で見えている単価と、診断結果の話をつなげやすいからです。^[9]

さらにFAQでは、電気料金プランの診断レポートに、基本料金、従量料金、燃料費調整単価、再エネ促進賦課金が含まれることが案内されています。同時に、データ更新には最大30日程度のタイムラグが生じる場合があるとも明記されています。ここは顧客への説明で非常に使いやすい論点です。違いが出たときに、「入っていません」ではなく「反映対象だが、更新タイミング差の可能性がある」と話せるからです。^[8]

そして、エネがえるBizではカスタム料金機能で任意の単価設定が可能だと仕様変更FAQが案内しています。これは、標準ロジックの外にある案件を救う逃げ道でもあります。たとえば、社内監査向けに特定月の単価を固定したい、電力会社との個別条件を反映したい、顧客の直近請求書を重視した比較をしたい、という場面では、標準ロジックを無理にねじ曲げるより、最初からカスタム単価前提で運用した方がよいことが少なくありません。^[7]

住宅営業の現場では、ここを「いま説明できること」に落とし込むと強いです。つまり、「試算には燃調費・再エネ賦課金・消費税を含んでいます。最新公開単価ベースで比較しやすい形にしています。もし特定請求月の再現が必要なら、別条件で確認します」と先に言ってしまう。たったこれだけで、あとから問われる“なぜ少し違うのか”の難易度がかなり下がります。

API実装では basemonth の扱いが事故の起点になる

API実装者は、FAQだけでなく現行のオンライン仕様書を優先して読むべきです。公開されているV4 API仕様書では、epchargecalc と epdiagnosis について、月毎の燃料調整費・再エネ賦課金は basemonth の設定によらず、最新（API実行時前月）のデータをすべての月へ適用して料金計算すると記されています。一方で、basemonth を指定しない場合は再エネ賦課金のみを適用すると読める記述もあり、少なくとも公開仕様上は「省略しても同じ」ではありません。^[10]

この一文は、実装責任の境界線です。営業画面では basemonth を見せていない、でも内部では省略している。検証環境では固定していた、でも本番は未指定。こうした小さな差が、リリース後に「顧客の請求書と何となく合わない」という形で噴き出します。APIは自由度が高い。だからこそ、自由度をどこで閉じるかを決めないと、差異説明が属人化します。

現行仕様書では、レスポンスの内訳に adjust（燃料調整費）や levy（再エネ賦課金）が含まれることも確認できます。これは単なる技術情報ではありません。UIで月別内訳を見せる、CSVやログへ残す、サポート時にスクリーンショットで説明する、といった“説明責任の器”を作れるという意味です。試算ロジックそのものより、その見せ方の方が問い合わせ削減に効くこともあります。^[10]

さらに、エネがえるAPIのオンライン仕様書は公開ページから参照可能で、サービス資料も別ページで案内されています。実装着手前に、仕様書・サービス資料・社内UIモックを並べて「何を自動反映し、何を注記で補うか」を決めておくと、あとで仕様議論が減ります。APIはコードだけで完結しません。契約・営業・CS・運用まで含めて初めて、実務で“正しい”になります。^[12][13]

ミニコラム：たとえば現場ではこう起きる

APIの結果そのものは合っているのに、営業画面に「燃調費込み」「税込」「参照単価はAPI実行時前月」と出していなかったため、顧客が請求書と突き合わせた瞬間に不信が生まれる。これは計算ロジックのバグではありません。説明のUIが欠けているだけです。けれど、顧客にはその違いは見えません。だから、実装では数式より先に“見せる責任”を設計する必要があります。

基準月ロジックの本質は、精度ではなく説明可能性の設計である

元稿にあった旧説明は、ある意味では自然でした。入力された電気使用量の月を基準月としてたどり、その月以前の同月単価を当てる。これは過去の月別条件を尊重する考え方です。履歴の再現には筋が通っています。ところが営業現場では別の問題が起きます。顧客が見ているのは、たいてい直近1枚の請求書であり、その請求書に書かれた単価や合計が「正しさ」の基準になりやすいからです。^[5][6][7]

だから、2024年10月の仕様変更は、単なる細かな改修ではなく、思考の軸を変える改修です。過去月ごとの細かな再現より、現時点の比較説明を優先する。物理学の言葉を借りれば、これは系の「境界条件」をそろえる発想に近い。発電量推計や負荷推計をどれだけ精密にしても、外側からかかる単価条件が読者に見えず、しかも説明しにくければ、現場の検算性は下がります。最新月単価へそろえるのは、履歴の粒度を少し犠牲にしながら、比較説明の摩擦を減らす設計です。^[2][7]

ここで読者に返したい問いがあります。あなたが必要としているのは「過去請求書の忠実再現」でしょうか。それとも「今後の導入判断に使える比較」でしょうか。両者は似ていますが、同じではありません。前者は会計・監査・突合の世界で重要になり、後者は営業・提案・意思決定の世界で重要になります。問題は、片方の物差しを、もう片方の用途に持ち込んでしまうことです。

実務では、たいてい二つを混同します。履歴再現レベルの一致を求める人が、提案比較レベルのツールに「完全一致」を期待する。あるいは逆に、比較判断で十分な場面なのに、実装側が履歴再現へ過剰に最適化してUIを複雑化させる。どちらもコストが高い。だから、記事や提案書では「この数値は何のための数値か」を先に言い切る方が、最終的には親切です。

ミニコラム：ここだけ先に押さえるとこうなる

「基準月」という言葉を見たら、まず“どの月の単価を参照するためのラベルか”と考えてください。次に、そのラベルが現行公開仕様ではどう簡略化・更新されたかを見る。この順番で読むと、古いFAQ・新しいFAQ・仕様書が同時に目に入っても、頭の中で整理しやすくなります。

よくある誤解1：反映されるなら請求書と必ず一致する

これは最も多い誤解です。反映されることと、特定の請求書と必ず一致することは、同じではありません。請求書は特定の検針期間の結果で、しかも燃料費調整は多くの料金メニューで毎月動きます。対してシミュレーションは、推計された12か月消費量や与えられた使用量に対し、ある時点の料金条件を載せて比較する道具です。目的が違えば、一致の仕方も変わります。^[2][7][10]

顧客は「先月の請求額」を強い基準として見ます。これは人間の自然な反応です。そのため、数百円から数千円の差でも、不思議なほど大きな違和感として受け取られます。ここで営業が「でも計算上は合っています」と返してしまうと、話は前に進きません。必要なのは、請求書再現ツールではなく、比較判断ツールとしての役割を先に説明することです。

より正確には、こう言い換えるとよいでしょう。「この結果は、太陽光・蓄電池導入前後を同じ条件で比較しやすくするための試算です。直近請求書の完全再現が目的なら、検針月や個別条件を固定した別確認が必要です」。この一文があるだけで、議論は“ズレの糾弾”から“目的に合った比較”へ移ります。

よくある誤解2：基準月という言葉があるなら、いまも旧ロジックのままだ

これも混乱の源です。公開FAQには、旧説明の名残と新しい変更告知が同居しています。だから、「基準月」という言葉だけで旧ロジックを前提にすると誤読しやすい。少なくとも公開FAQでは、別記事で「最新月の単価が自動的に適用される」こと、仕様変更告知で「最新月の燃調費単価と再エネ賦課金単価を12か月分へ反映する」ことが案内されています。^[6][7]

ここで大切なのは、文章の古さではなく、運用上の優先順位です。検索結果で古い記事が先に見つかることはあります。けれど、実装や顧客説明で使うべきなのは、現行の公開仕様に近い記述です。チーム内でナレッジを共有するときも、「旧記事のキャプチャ」ではなく、「現行FAQと仕様書のURL」を残す方が事故が減ります。

もし社内Wikiや営業トークに、元稿のような旧説明が残っているなら、そこは更新対象です。古い説明は、現場では“誤った情報”としてより、“説明をややこしくするノイズ”として効いてしまいます。しかもノイズは、間違いより厄介です。断定的に誤っていないように見えるため、修正優先度が下がるからです。

よくある誤解3：消費税が入っていれば比較条件は自動でそろう

消費税が反映されることは重要です。けれど、それだけで比較条件が自動的にそろうわけではありません。設備費、工事費、補助金控除前後、売電単価、光熱費累計、そして社内の稟議資料。ここに税込・税抜が混在すると、数字は簡単に歪みます。FAQでは長期シミュレーションの実質光熱費累計金額が消費税込みと案内されていますが、提案全体の整合性までは自動では担保されません。^[11]

しかも、FAQには、消費税改定時には改定を反映するが、電力会社によって反映タイミングが異なる場合があるため一定期間を経て反映するとあります。つまり、税が入っているという事実と、すべての比較表が同じタイミングでそろうという事実は別物です。ここでも重要なのは、条件を明示することです。^[11]

法人提案では、ここを軽く扱うと社内稟議で止まります。設備側は税抜、光熱費側は税込、補助金の記載は税込・税抜不明、という資料は、数字が合っていても通りにくい。なぜなら、決裁者が見ているのは“計算の正しさ”だけでなく、“比較の整い方”だからです。比較表は、数字の見た目より条件の一貫性が大事です。

差異が出やすい4つのパターンを、現場シーンで見る

住宅営業の現場

土曜の商談で、お客様が電気料金明細を机に置いて「先月はこの金額だったのに、なぜ試算は少し違うんですか」と聞く。ここで必要なのは、発電量の微差ではありません。まず、料金プラン名、検針月、そして試算が“現在の単価条件での比較用”なのか“過去請求書の再現用”なのかをそろえることです。ここを飛ばしてしまうと、営業は説明に疲れ、お客様は数字に不信感を持ちます。

住宅営業では、説明の順番が重要です。最初に「3要素は反映済みです」と言う。次に「ただし燃調費は毎月、賦課金は年度で動くので、請求書と比較するときは時点差が出ます」と言う。最後に「必要なら請求月基準で別確認します」と添える。この3手順だけで、会話の空気はかなり変わります。

法人・産業用の現場

法人案件では、現場担当者と決裁者の視点がずれます。現場担当は削減額を見ますが、経理や役員は単価の根拠と比較条件を見ます。だから、法人提案では「電気料金プラン名」「単価反映の参照時点」「税込・税抜」「カスタム単価の有無」を一枚に置く方が強い。数字を増やすより、比較条件を明文化した方が通りやすいことが多いのです。

とくに高圧・特高や複数拠点案件では、単価条件を揃えずに削減率だけを比較すると、あとから説明コストが跳ねます。エネがえるBizのカスタム料金機能は、まさにそうした“標準化しにくい現場”のために価値があります。標準ロジックで走る案件と、最初から個別単価で固める案件を分ける。これだけで運用がずっと楽になります。^[7]

API実装の現場

API案件では、問い合わせはたいていリリース後に増えます。理由は簡単で、社内レビューでは「値が返ってくるか」を見ていても、実利用では「説明できるか」が問われるからです。basemonth の扱い、レスポンスの adjust / levy を画面へ見せるか、ログへ残すか、CSVへ出すか。この設計が曖昧だと、サポートのたびにエンジニアへ確認が飛びます。

逆に、UIに「燃調費込み」「再エネ賦課金込み」「税込」「参照単価はAPI実行時前月」と明示し、必要なら月別内訳を開けるようにしておけば、問い合わせはかなり減らせます。コードの正しさだけでなく、説明の見える化まで含めて設計する。ここがAPI案件の分水嶺です。^[10]

特殊単価案件の現場

個別契約、独自単価、会計監査用の突合、特定請求月の再現。こうした案件を標準ロジックだけで押し通そうとすると、むしろ不信を招きます。適切なのは、「標準ロジックで比較判断する案件」と「単価固定で再現性を優先する案件」を分けることです。標準ロジックは万能ではありません。万能に見せようとする運用が危険です。

これは弱さではなく、むしろ健全な設計です。標準モデルに適した案件は高速に回し、例外案件は最初からカスタム料金や個別確認へ流す。その線引きを記事や営業トークに書いておく方が、結果的に顧客満足も高くなります。

ASPとAPIをどう使い分けるか

この表から分かる通り、ASP系は「現場で迷わず説明する」ための強さがあり、APIは「自社仕様に織り込む自由」が大きい。自由は強みですが、その分だけ実装責任も増えます。とくにAPIは、何を自動化し、何をUI・ログ・注記で補うかを決めないと、あとで差異説明が属人的になります。^[7][9][10]

顧客説明で詰まらないための5ステップ

1. 料金プラン名と検針月を確認する。 何と何を比べているのかを最初に固定します。
2. 3要素が反映対象であることを先に伝える。 「入っていないのでは」という疑いを初手で解きます。
3. 単価の参照時点を言う。 「最新月」「API実行時前月」「請求月固定」など、時間軸を言葉にします。
4. 差異があるなら、更新タイムラグ・カスタム単価・比較条件を疑う。 いきなりバグと決めつけません。
5. 必要なら比較用途と再現用途を分ける。 比較判断用の試算と、請求書再現用の確認を同じ土俵で戦わせません。

この5ステップの良いところは、営業でもCSでもエンジニアでも使えることです。言い方は違っても、確認すべき論点は同じです。だから、社内テンプレートにしてしまう価値があります。

悪い説明と良い説明は、ほぼ一文で分かれる

悪い説明：「システム上そうなっています」

良い説明：「この結果は、公開されている最新単価を12か月の推計消費量へ反映した比較用試算です。直近請求書の再現が必要なら、検針月や個別条件を固定して別確認します」

前者は責任主体が消えています。後者は、①結果の目的、②参照時点、③比較対象、④代替手段、の四つが入っています。顧客は数字だけでなく、説明の姿勢も見ています。だから、この一文は単なる接客スクリプトではありません。仕様を顧客価値へ翻訳する、最小で最強のインターフェースです。

システムで見ると、電気料金シミュレーションは4層構造

シミュレーションを一枚で捉えるなら、電気料金試算は少なくとも4層に分けて見ると整理しやすくなります。第1層は入力される使用量や推計消費量。第2層は料金プランの基本料金・従量料金のマスタ。第3層は燃調費や再エネ賦課金のような可変単価。第4層は消費税です。多くの現場で揉めるのは、第1層ではなく第3層と第4層です。

この見方をすると、レバレッジポイントも見えます。発電量推計の微修正より先に、可変単価の参照時点を画面と資料へ明記する。税込・税抜を統一する。カスタム料金が必要な案件を早めに仕分ける。これらはすべて、少ない変更で大きく摩擦を減らせる打ち手です。システム思考で言えば、根本解は個々の問い合わせ対応ではなく、問い合わせを生みにくい構造へ変えることにあります。

人の心理もここに絡みます。顧客は最新請求書を起点に考えやすく、担当者はその違いを指摘されることを避けたくなり、結果として単価説明を後回しにしがちです。しかし、後回しにされた一行が、提案書全体の信頼を壊します。だから、燃調費・賦課金・税の扱いは、単なる周辺論点ではありません。信頼設計の中核です。

ミニコラム：初心者向けに一段かみ砕くと

太陽光や蓄電池のシミュレーションというと、つい「発電量がどれだけ当たるか」に目が向きます。もちろん大事です。でも、顧客の請求書との差でよく問題になるのは、むしろ電気料金側の単価条件です。発電量は合っていても、単価の時点がずれれば合計額は変わる。ここを押さえるだけで、試算の見え方はかなり変わります。

専門家向け補論：意思決定に必要な精度と、履歴再現に必要な精度は別物

専門家向けにもう一段だけ踏み込みます。ここで扱う「精度」には、少なくとも三種類あります。ひとつは物理量としての推計精度。もうひとつは請求書再現の精度。そして最後が、意思決定に使える説明精度です。現場で最も軽視されやすいのは三つ目ですが、提案が止まる直接原因になりやすいのも三つ目です。

たとえば、発電量モデルを0.5%改善しても、単価反映時点の説明が曖昧なら顧客の不信は消えません。逆に、履歴再現としては数百円の差が残っていても、比較条件と次の確認手順が明記されていれば、提案は前に進むことがあります。これは「どちらが正しいか」の話ではなく、「どの仕事に対して、どの精度が効くか」の話です。

エネがえるをAPIで深く組み込む企業なら、ここを二層設計にしてもよいでしょう。ひとつは営業向けの比較モード。もうひとつは監査・突合向けの再現モードです。前者は最新月単価ベースで説明しやすさを優先する。後者は請求月固定や独自単価固定で検証しやすさを優先する。用途を分ければ、無理に一つのロジックへ全責任を背負わせなくて済みます。

この設計思想は、太陽光・蓄電池・EV/V2Hだけでなく、補助金、DR、VPP、PPAの説明にも広がります。社会実装で勝つのは、すべてを一つのモデルへ押し込むプレイヤーではありません。比較・説明・監査の用途に応じて、適切な粒度を切り分けられるプレイヤーです。

運用ルールとして残すなら、この8項目

• 提案書に「料金プラン名」を明記する
• 「単価確認日」または「参照時点」を記載する
• 燃調費・再エネ賦課金・消費税の反映有無を一文で書く
• 税込・税抜の扱いを資料全体で統一する
• APIでは basemonth の扱いを社内仕様として固定する
• adjust / levy の内訳を必要に応じて見える化する
• 特殊単価案件は標準ロジックと分ける
• 差異説明テンプレを営業・CS・開発で共通化する

この8項目は、派手ではありません。ですが、どれもサポート負荷と不信コストを下げる項目です。問い合わせを1件ずつさばくより、問い合わせが生まれにくい構造へ寄せた方が、長い目では圧倒的に安い。だから運用ルールは、現場を縛るためではなく、現場を守るためにあります。

FAQ

Q1. 燃調費・再エネ賦課金・消費税は本当に全部入っていますか？

公開FAQの答えは「はい」です。ただし、同じ「反映される」でも、ASP/Biz/EV・V2HとAPIでは読み方が少し違います。検索者が本当に知りたいのは「ある・ない」だけでなく、「どう入るのか」「請求書と差が出たら何を確認すべきか」です。実務では、料金プラン名、単価確認日、比較目的も一緒に出すと誤解が減ります。^[5][11]

Q2. 2024年10月以降、何が変わったのですか？

公開FAQの仕様変更告知では、最新月の燃調費単価と再エネ賦課金単価を12か月分の推計電力消費量へ反映する方針が示されています。旧い記事の理解のまま「入力月をたどる基準月ロジック」で説明すると、現行の公開案内とずれやすいので注意が必要です。^[7]

Q3. APIでは basemonth を省略しても問題ありませんか？

少なくとも公開されているV4 API仕様書では、省略時の扱いが別ルールです。basemonth を軽く扱うと、検証環境と本番環境で差が出る起点になります。FAQで概要を理解しつつ、最終判断は現行仕様書で確認してください。^[10][12]

Q4. 顧客の請求書と少し違うのはバグですか？

すぐにバグと決めつけない方が安全です。燃料費調整は多くの料金メニューで毎月変動し、再エネ賦課金は年度で動きます。さらに、FAQではデータ更新に最大30日程度のタイムラグが生じる場合があると案内されています。まずは検針月、単価確認日、カスタム単価の有無、税込・税抜を確認してください。^{[2][3][8][11]}

Q5. 消費税はどこまで反映されていますか？

FAQでは、長期シミュレーションの実質光熱費累計金額は消費税込みと案内されています。API側FAQでは、料金プランやFIT単価に消費税が含まれると整理されています。ただし、提案書全体で税込・税抜が混在していれば比較は崩れるので、資料側の整え方は別途必要です。^[5][11]

Q6. ASP/Biz側で最新単価を確認する方法はありますか？

あります。共通マニュアルの料金プラン照会では、選択したプランに適用される最新（照会実行時前月）の燃調費・賦課金単価を表示すると案内されています。現場で説明に迷ったら、まずこの画面の前提を確認すると整理しやすくなります。^[9]

Q7. 特殊な料金条件や個別単価がある案件はどうすればよいですか？

標準ロジックへ無理に載せるより、カスタム料金や個別確認へ切り分けた方がよい場合があります。仕様変更FAQでは、Bizユーザーがカスタム料金機能で任意の単価設定を行えることが示されています。比較判断用の標準案件と、再現性優先の例外案件を分ける運用が有効です。^[7]

Q8. まず何を見ればよいですか？

営業・CSなら現行FAQと料金プラン照会。PdM・エンジニアならAPI仕様書。導入検討者ならAPIサービス資料です。この記事を読んだあとに合理的な次の一手は、「自分が知りたいのは比較判断か、履歴再現か」を決め、その用途に合う公開資料から確認を始めることです。^[9][12][13]

まとめ：勝負を分けるのは「反映の有無」ではなく「反映時点」と「説明方法」

この記事の要点を一言でまとめると、エネがえるでは燃調費・再エネ賦課金・消費税は反映されます。しかし、提案の信頼性を左右するのは、その事実そのものより、「いつの単価を使ったか」「比較用か再現用か」「どこまでを自動化し、どこからを注記やカスタム条件で補うか」です。^{[5][7][10][11]}

だから、次のアクションは明快です。営業なら、資料に参照時点と税込・税抜を残す。CSなら、差異説明テンプレを共通化する。API導入側なら、basemonth と内訳表示の扱いを仕様化する。太陽光・蓄電池の経済効果は、計算式だけで勝つのではありません。説明責任まで設計して、初めて勝てます。

• エネがえるAPI 仕様書を確認する
• エネがえるAPI（REST API）サービス資料を見る
• 現行仕様に合わせた試算ロジック設計やAPI実装を相談する

請求書との差異説明や自社サイトへの実装で詰まっているなら、「燃調費・再エネ賦課金・消費税の反映ルールを、どの月の単価で、どのUIで見せたいか」まで書いて相談すると、やり取りは速くなります。相談の質は、そのまま解決の速さになります。

出典・参考URL

1. [1] 資源エネルギー庁「料金の仕組みと料金メニュー例のご紹介」
   https://www.enecho.meti.go.jp/category/electricity_and_gas/electric/electricity_liberalization/supply/
2. [2] 資源エネルギー庁「燃料費調整制度について」
   https://www.enecho.meti.go.jp/category/electricity_and_gas/electric/fee/fuel_cost_adjustment_001/
3. [3] 経済産業省「再生可能エネルギーのFIT制度・FIP制度における2025年度以降の買取価格等と2025年度の賦課金単価を設定します」
   https://www.meti.go.jp/press/2024/03/20250321006/20250321006.html
4. [4] 国税庁「軽減税率制度の概要」
   https://www.nta.go.jp/taxes/shiraberu/zeimokubetsu/shohi/keigenzeiritsu/01.htm
5. [5] エネがえるFAQ「燃調費、再エネ賦課金、消費税は反映されていますか？」
   https://faq.enegaeru.com/ja/articles/5209809-%E7%87%83%E8%AA%BF%E8%B2%BB-%E5%86%8D%E3%82%A8%E3%83%8D%E8%B3%A6%E8%AA%B2%E9%87%91-%E6%B6%88%E8%B2%BB%E7%A8%8E%E3%81%AF%E5%8F%8D%E6%98%A0%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%81%8B
6. [6] エネがえるFAQ「電気使用量の入力と基準月（燃料調整費単価および再エネ賦課金反映の仕方）について」
   https://faq.enegaeru.com/ja/articles/6327623-%E9%9B%BB%E6%B0%97%E4%BD%BF%E7%94%A8%E9%87%8F%E3%81%AE%E5%85%A5%E5%8A%9B%E3%81%A8%E5%9F%BA%E6%BA%96%E6%9C%88-%E7%87%83%E6%96%99%E8%AA%BF%E6%95%B4%E8%B2%BB%E5%8D%98%E4%BE%A1%E3%81%8A%E3%82%88%E3%81%B3%E5%86%8D%E3%82%A8%E3%83%8D%E8%B3%A6%E8%AA%B2%E9%87%91%E5%8F%8D%E6%98%A0%E3%81%AE%E4%BB%95%E6%96%B9-%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
7. [7] エネがえるFAQ「2024年10月から：エネがえる仕様変更（計算仕様が変更になりました）」
   https://faq.enegaeru.com/ja/articles/9618566-2024%E5%B9%B410%E6%9C%88%E3%81%8B%E3%82%89-%E3%82%A8%E3%83%8D%E3%81%8C%E3%81%88%E3%82%8B%E4%BB%95%E6%A7%98%E5%A4%89%E6%9B%B4-%E8%A8%88%E7%AE%97%E4%BB%95%E6%A7%98%E3%81%8C%E5%A4%89%E6%9B%B4%E3%81%AB%E3%81%AA%E3%82%8A%E3%81%BE%E3%81%97%E3%81%9F
8. [8] エネがえるFAQ「エネがえるの試算結果には、燃料費調整単価や再エネ促進賦課金は含まれていますか？」
   https://faq.enegaeru.com/ja/articles/2405019-%E3%82%A8%E3%83%8D%E3%81%8C%E3%81%88%E3%82%8B%E3%81%AE%E8%A9%A6%E7%AE%97%E7%B5%90%E6%9E%9C%E3%81%AB%E3%81%AF-%E7%87%83%E6%96%99%E8%B2%BB%E8%AA%BF%E6%95%B4%E5%8D%98%E4%BE%A1%E3%82%84%E5%86%8D%E3%82%A8%E3%83%8D%E4%BF%83%E9%80%B2%E8%B3%A6%E8%AA%B2%E9%87%91%E3%81%AF%E5%90%AB%E3%81%BE%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%81%8B
9. [9] エネがえる共通マニュアル「ASP料金プラン照会」
   https://www-sys.enegaeru.com/sysweb11/manual/reference/asp-epplan.html
10. [10] エネがえる V4 一般用 API「api-general」
    https://www-v4.enegaeru.com/apidoc/api-general.html
11. [11] エネがえるFAQ「シミュレーション結果に消費税は反映されていますか？」
    https://faq.enegaeru.com/ja/articles/5084669-%E3%82%B7%E3%83%9F%E3%83%A5%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E7%B5%90%E6%9E%9C%E3%81%AB%E6%B6%88%E8%B2%BB%E7%A8%8E%E3%81%AF%E5%8F%8D%E6%98%A0%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%BE%E3%81%99%E3%81%8B
12. [12] エネがえるAPI 仕様書案内ページ
    https://www.enegaeru.com/documents/api-document
13. [13] エネがえるAPI（REST API）サービス資料
    https://www.enegaeru.com/documents/solar-power-api