ガス料金計算システム開発の進め方/やり方/流れや方法/手法/工程/手順

ガス料金計算システムの開発は、要件定義・企画、設計・開発、テスト・リリースの3段階で進みます。費用と期間は、ガス種別、料金ルール、連携範囲によって、50万円〜1億円超、1〜36か月程度まで変わります。

▼全体ガイドの記事
・ガス料金計算システム開発の完全ガイド

ガス料金計算システムの全体像

検針データから請求・入金・顧客向け明細までを4層で示す図。
計算の前後にある取込と請求業務もひと続きです。

ガス料金計算システムは、検針データや契約条件を取り込み、料金メニューと原料費調整をもとに、需要家ごとの請求額を算出します。請求・入金・顧客向け明細までつなぐ必要があるため、「使用量×単価」だけの計算アプリでは要件が漏れやすくなります。

都市ガスとLPガスで異なる料金計算の枠組み

都市ガスとLPガスは、料金の決まり方と表示方法が異なります。そのため、設計では次の違いを分けて整理します。

  • 都市ガス:基本料金と従量料金を使用量に応じて算定
  • LPガス:基本・従量・設備の三部料金として表示

東京ガスの公式説明では、使用量0〜20立方メートルの基本料金は759円で、20〜80立方メートルは1,056円です。

従量料金は、単位料金に使用量を掛けて算定します(出典: 東京ガス「ガス料金の計算方法」、2026年確認)。特に、1円未満の端数処理や税計算の位置づけは、仕様書に明記しておく項目です。

LPガスは、事業者ごとに料金設定の自由度が高い仕組みです。

資源エネルギー庁は2025年4月2日、新しいルールを施行しました(出典: 経済産業省「LPガス料金の表示・計上方法に関する新しいルールを施行しました」、2025年)。

新ルールは、基本料金・従量料金・設備料金の三部料金表示を求めています。さらに、新規契約では設備費用を従量料金に計上することも禁止されます。そのため、三部料金を分離して管理し、請求書や明細に個別表示できる設計が必要です。

ガス料金計算システムが担う主要機能

主要機能は、料金計算だけでなく検針から請求・監査までの流れで整理すると、漏れを防げます。

  • 顧客・契約管理:顧客、供給地点、契約、メーターの情報
  • 料金マスタ管理:料金、割引、最低料金、段階単価の設定
  • 検針データ処理:取込、差分計算、異常値・未検針への対応
  • 請求・入金管理:請求、入金、滞納、帳票の扱い
  • 外部連携・監査:決済や設備との接続、承認、計算根拠の保存

遡及訂正や原料費調整に対応できるよう、料金メニューの変更履歴も扱います。

検針値は取り込んだうえで前回値との差分を計算し、異常値、未検針、通信遅延を検出します。

税や端数処理、締め日の扱いを含めて、請求・入金・滞納の計算と帳票出力も一連の流れとして設計します。

概算料金という速報値と、検針後に確定する請求額は区別して扱います。あわせて、再計算の履歴と差額調整も記録します。

支払いや明細の面では、口座振替やクレジットカード、コンビニと連携します。

電子請求、Web明細、顧客ポータルとも接続します。このほか、スマートメーターや配送・保安・開閉栓のシステムとは、APIやファイルで連携します。

承認ワークフローと、監査用の計算根拠の保存も必要です。

料金ルールをプログラムに固定しない設計にすると、後の改修の負担を抑えられます。

ポイント

都市ガスとLPガスのどちらを扱うか、請求や入金まで含めるかで、設計する範囲が変わります。範囲を先に決めておくと、見積もりを比べやすくなります。

ガス料金計算システム開発の進め方

要件定義・企画、設計・開発、テスト・リリースの3段階を矢印でつないだ図。
前段階で整理した条件が、次の検証へ引き継がれます。

開発は、料金表をいきなりプログラムに落とし込まず、まず業務範囲を洗い出すところから始めます。そのうえで、要件定義、設計・開発、テスト・リリースの三段階に分け、各段階で認識をすり合わせます。

要件定義・企画フェーズ

要件漏れを防ぐには、料金計算の例外ケースまで含めて業務範囲を整理しておく必要があります。ガス種別、業務区分、料金資料、例外ケースの4つの側面で見ると、抜けに気づきやすくなります。

  • ガス種別:LPガス・都市ガス、家庭用・業務用
  • 業務区分:販売・導管、検針・保安・配送
  • 料金資料:現行の料金表、契約約款、締め処理
  • 例外ケース:未検針、訂正、改定、メーター交換

区分と例外の整理が終わったら、「計算入力→適用ルール→計算結果→請求書→入金」の流れでサンプルを作ります。

サンプルには、正常系だけでなく未検針、通信遅延、検針値訂正も含めます。さらに、契約途中変更、料金改定、税率変更の例外や、返金・再請求、メーター交換まで確かめます。

計測時刻と受信時刻は別項目として保持する方針を、この段階で決めます。そのうえで、検針データが遅れて届いても正しい時点のルールで再集計できるようにします。この設計がないと、料金改定や訂正のたびに手作業での補正が必要になります。

設計・開発フェーズ

設計では、機能ごとに要件を分けて決めます。

  • ルール管理:料金ルールの設定と変更を扱う
  • 計算処理:バッチ計算と再計算の扱い
  • データ取込:API、SFTP、CSV、IoTゲートウェイを使い分ける
  • 遠隔操作:遠隔開閉栓の安全対策

料金ルールはプログラムに直接埋め込まず、ルールエンジンか設定可能なテーブルで管理します。そうしておくと、料金改定があっても、プログラム本体を直す範囲を抑えられます。

バッチ計算と再計算は、べき等(同じ入力なら何度実行しても同じ結果になる状態)にします。こうすると、検針値の訂正や料金改定が起きても、安全に再計算できます。

データ取込では、欠損・重複・遅延も扱う必要があります。

遠隔開閉栓まで扱う場合は、強固な認証、最小権限、二者承認を要件に含めます。

加えて、遠隔開閉栓では、対象メーターの再確認、操作ログ、通信断時の現地対応も必要です。

標準化や共同化の例として、都市ガス3社が共同開発したスマートメーターのセンターシステム「SMANEO」があります。2022年12月に稼働を開始し、業務を標準化して共同で使うことで開発・維持管理コストを低減した点が評価されました。

日本ガス協会の2024年度技術賞も受賞しています(出典: NTTデータ「都市ガス3社が挑む、DXによる業務効率化とレジリエンス強化」、2026年)。

単独開発だけでなく、標準化・共同化という選択肢も設計段階で検討します。

テスト・リリースフェーズ

テストでは、例外ケースを含めて新旧システムの差異を確かめ、そのうえで段階的に切り替えます。

  1. 例外ケースと過去データを使って再計算する
  2. 新旧システムの請求額を突き合わせる
  3. 一部契約から移行し、差異を監視して範囲を広げる

検証では、正常な計算だけでなく、未検針、通信遅延、検針値訂正も見ます。契約途中変更、料金改定、税率変更などの例外ケースも網羅的に確認します。

概算料金と、検針後に確定する請求額の差異が想定どおりかも確かめます。

本番切り替えでは全需要家を一度に移行せず、一部エリアや一部契約から切り替えます。あわせて、切り戻しの条件と問い合わせ窓口も計画しておきます。

ポイント

業務範囲の洗い出しから始め、要件定義から検証まで例外ケースを同じ基準で扱えるかどうかが、後の手戻りを左右します。

費用相場とコストの内訳

5つの導入タイプごとに初期費用と導入期間の推定レンジを並べた尺度図。
導入範囲が広いタイプほど、費用と期間の幅も大きくなります。

費用を左右するのは、対象顧客数と料金メニュー数、データ移行量です。既存連携やテスト要件でも費用は変わります。

専用システムは個別見積りが多いため、ここに示す金額は、編集部が類似システムの規模感から作成した推定レンジです。公定相場ではない点に注意してください。

導入タイプ別の初期費用と期間

初期費用と期間は、導入規模や連携範囲によって次のように分かれます。

  • 小規模パッケージ:50万〜300万円、1〜3か月
  • クラウド・SaaS導入:300万〜1,000万円、2〜6か月
  • 単一事業のスクラッチ:500万〜1,500万円、4〜9か月
  • 中規模業務システム:1,500万〜5,000万円、8〜18か月
  • 大規模・基幹刷新:5,000万円〜1億円超、18〜36か月

小規模パッケージは、標準料金計算、顧客・検針・請求、初期マスタ設定を含む範囲です。簡易的なデータ移行も、この範囲に含まれます。

クラウドやSaaS導入では、既存の会計・決済・検針システムとの連携を含みます。一方、単一事業・単一拠点のスクラッチ開発は、標準機能からの個別開発が中心です。

中規模では、複数拠点や複数料金メニューを扱います。さらに、保安・配送のシステムや決済、顧客ポータルとも連携します。

大規模では、多数の需要家やスマートメーターを扱い、遠隔遮断やリアルタイム監視も加わります。

冗長化や段階移行、IoT連携まで伴うと、基幹刷新の規模になります。

ランニングコストと見積もり項目

ランニングコストは、月額費用の変動要因と見積もり項目に分けて把握します。

  • 月額費用:通信設備、保守・運用、需要家数に応じて変動
  • 開発関連:要件定義、計算、連携、移行、テスト
  • 運用関連:保守、法改正対応、過去データ再計算
  • 段階導入:機能を分けて順に導入

LPガス向けのクラウド型プラットフォームには、月額料金の公開例もあります。

KDDIは2026年1月1日、LPガス向けIoTプラットフォームの法人向け料金を一部改定しました。その理由は、通信設備や保守・運用費の高騰です(出典: KDDI「法人向けIoTサービスの料金改定のお知らせ」、2025年公表)。

LPガス向けIoTプラットフォームの法人向け料金は、検針・接点の組み合わせに応じた従量型の月額です。

見積りでは、要件定義・業務整理、料金計算エンジン、顧客・契約・請求を分けて提示してもらいます。このほか、検針やIoT連携、外部決済は別項目にします。データ移行、テスト・並行稼働も別に示してもらいます。

保守や法改正対応に加えて、本番前の過去データ再計算と請求額の突き合わせも、見積もりから削らないようにします。

費用を抑える場合は、料金計算・請求・Web明細から始めます。配送を最適化する機能や高度な分析、遠隔制御は、第2段階として計画するのが現実的です。

ポイント

費用は導入規模と連携範囲で変わるため、示した推定レンジは目安として見て、個別の見積りで確かめます。月額費用や保守費も、初期費用とあわせて比べます。

見積もりを取る際のポイント

見積もりを正確に比べるには、機能一覧だけでなく、前提条件をそろえておく必要があります。要件と仕様書を整え、各社が同じ前提で提案できるようにします。

要件明確化と仕様書の準備

仕様書には、対象条件と料金を具体的に書きます。データや連携、計算ケースも、あわせて記載します。

  • 対象条件:ガス種別と家庭用・業務用の区分
  • 規模:料金メニュー、需要家、移行の対象
  • 連携方式:会計・決済・検針システムとの接続
  • 計算ケース:正常系と例外系の代表サンプル

仕様書があいまいだと、見積もりの前提が会社ごとに変わってしまいます。そのため、LPガスか都市ガスか、家庭用か業務用かを明記し、料金メニュー数や需要家数、データ移行の有無も書き入れます。

サンプル請求を共通の材料にそろえておくと、開発会社ごとの理解のずれを早い段階で見つけられます。

三部料金制などの制度対応が必要かどうかも、仕様書に含めます。加えて、原料費調整や料金改定にどう追随するかも書いておきます。

口頭の説明だけでは、見積りに含まれる作業範囲が会社ごとに大きく違ってしまいます。

複数社比較と発注先の選び方

発注先を選ぶときは、機能表だけでなく、料金計算と移行を実際に検証して比べます。

  • 業界経験:ガス業務での経験年数
  • 変更対応:料金ルールを自社で設定できるか
  • 追跡性:計算根拠をたどれるか
  • 移行体制:連携や並行稼働まで含めた担当範囲

既存システムと疎結合で連携できるか、移行や並行稼働を誰が担うかも評価します。

大手SIと業界特化パッケージも、同じ条件で比べます。

サンプル請求の再現テストも、各社に実施してもらいます。

見積りは、要件定義から保守までを工程別に提示してもらいます。そうすると、各社の作業範囲を比べられます。

極端に安い見積りでは、データ移行、テスト、保守対応の範囲が限られている場合があります。

注意すべきリスクと対策

契約前に、責任の分担を確認します。

  • 法改正:料金改定や法改正への対応費用
  • 誤請求:返金・再請求フローの担当者
  • 障害対応:障害時の再計算責任
  • データ保全:エクスポートと契約終了時の返却

保守契約の範囲に、法改正への対応が含まれているかも確かめます。

計算誤りがあったときに、返金や再請求を誰が担うかも決めておきます。

障害が起きたとき、再計算を誰が担うかが決まっていないと、稼働後の責任の所在があいまいになります。

料金ルールや計算履歴をエクスポートできるか、契約終了時にデータを返却してもらえるかを確かめます。契約終了時の移行支援の有無も確認します。

導入費だけでなく、総保有コストで判断します。

ポイント

見積もりを比べる前に、仕様書で前提をそろえ、契約前に責任の分担も決めておきます。前提がそろわない見積もりは、金額だけでは比べられません。

よくある質問(FAQ)

開発を検討する際によく出る質問に答えます。個別の期間や費用は、事業規模と要件によって変わるため、目安として参考にしてください。

ガス料金計算システムの開発期間はどのくらいですか?

小規模なパッケージ導入・設定は1〜3か月程度で、クラウドやSaaS導入と既存連携は2〜6か月程度です。

一方、単一事業のスクラッチ開発は4〜9か月、中規模開発は8〜18か月程度かかることがあります。要件定義に十分な時間をかけるほど、後工程の手戻りを減らせます。

都市ガスとLPガスを両方扱う場合、システムは分けるべきですか?

必ずしも物理的に別システムにする必要はありません。同じシステムの中で、料金ロジックと料金マスタをガス種別ごとに分けて管理する選択もあります。

ただし、都市ガスの段階料金制とLPガスの三部料金制には制度上の違いがあります。同じルールエンジンでガス種別に適用ルールを切り替えると、制度改正にも対応しやすくなります。

開発を始める前に何を準備すればよいですか?

現行の料金表、契約約款、締め処理、返金・再請求のルールを一覧にします。

例外的なメーター交換の対応方法も整理します。

検針から請求確定までの業務フローは、図にして残します。正常系だけでなく未検針、通信遅延、検針値訂正も整理すると、要件定義の話し合いが具体的に進みます。

まとめ

開発では、料金表をプログラムへ移すことに加えて、ガス種別と制度の違いを整理しておく必要があります。また、計測時刻と受信時刻のずれや、速報値と確定値の区別も設計に含めます。要件定義・企画、設計・開発、テスト・リリースを丁寧に進めれば、誤請求やトラブルを防ぎやすくなります。

開発前に確認すべきチェックリスト

発注前に、料金と業務の前提をそろえます。制度や連携、移行の前提も含めます。

  • 料金と業務:料金表と業務フローの一覧
  • 計算ケース:正常系と例外系のサンプル
  • 制度対応:三部料金制などの要否
  • 連携範囲:既存システムとの接続先
  • データ移行:対象期間

料金・業務・制度・連携・移行の条件があいまいなまま発注すると、見積もりの前提が会社ごとに異なり、比較が難しくなります。

次のステップの進め方

要件が整理できたら、見積もり、再現テスト、発注の順に進めます。

  1. 費用相場を参考に複数社から見積もりを取る
  2. サンプル請求の再現テストで計算の正確性を確認する
  3. 段階的な移行計画とテスト体制を確認して発注する

段階的な移行計画とテスト体制を整えておくと、稼働後も任せられるシステムにつながります。

▼全体ガイドの記事
・ガス料金計算システム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。