ガス供給管理システム開発の進め方/やり方/流れや方法/手法/工程/手順

ガス供給管理システムの開発は、対象範囲の確定、現行業務の棚卸し、要件定義とRFP作成、PoC、段階導入、運用設計の順に進めると、手戻りを抑えられます。特に最初に決める対象ガス種と業務範囲は、要件定義のやり直しを防ぐうえで欠かせません。

▼全体ガイドの記事
・ガス供給管理システム開発の完全ガイド

ガス供給管理システムの概要

現場デバイスからIoTデータ受信基盤と業務データベースを経て、管理画面や需要家ポータルにつながる4層の構成図。
現場側のデータが業務機能を通じて利用者向け画面へ届く構造です。

ガス供給管理システムの中心は、顧客管理や料金計算から保安、現場作業、請求までをつなぐ基幹系です。

そこに、メーターやセンサーからIoTデータを集める連携基盤も組み合わせます。

開発前には、まず自社が対象とするガス種と業務範囲を明確にします。

都市ガス・LPガス・コミュニティガスの業務範囲の違い

ガス種ごとに供給形態と管理対象が異なるため、その違いを踏まえて対象範囲を決める必要があります。

  • 都市ガス:導管による面的な供給が中心
  • LPガス:容器、充填所、配送車両による個別供給が中心
  • コミュニティガス:両者の中間的な供給形態で、個別処理が生じやすい

都市ガスでは、検針や保安点検の頻度、保安規程の運用が事業者ごとに標準化されています。一方、LPガスでは残量予測と配送計画が業務の中心になります。

コミュニティガスは供給範囲が限られ、既存パッケージで対応しにくい例外処理が起きやすい形態です。そこで、対象ガス種と業務範囲を紙一枚にまとめておくと、発注者と開発会社の認識の食い違いを減らせます。

基幹系と現場IoT系に分けた主要機能

主な機能は、基幹系と現場IoT系に分けて整理できます。どちらから着手するかで、開発の進め方が大きく変わります。

  • 顧客・料金:需要家、契約、建物、メーター、供給地点の管理から、料金調定、請求、入金まで
  • 検針・保安:現地検針と自動検針、ガス漏れや圧力異常の監視
  • 設備・配送:遠隔開閉栓や設備制御、供給管や本支管、内管、ガス機器、容器の工事・設備管理、LPガス配送
  • 利用者・外部連携:需要家ポータルや通知、経理、地図、CRM、決済、自治体との連携

自動検針には、スマートメーター、NCU、LPWAとの連携があります。全機能を同時に作るより、顧客・料金・請求の基幹系と、検針・保安・配送の現場IoT系に分けて着手の順番を決めるほうが進めやすくなります。

典型的な構成は、現場デバイスと通信ゲートウェイやLPWAに、IoTデータ受信基盤を組み合わせたものです。その上に業務APIと顧客・料金・保安のデータベースが載ります。

管理画面と現場タブレットに加えて、需要家ポータルや外部連携層も、この構成に含まれます。

通信障害のあとに届くデータもあるため、計測時刻を基準に再集計できる時系列モデルを、初期に決めておきます。そうすると、速報値と確定値の扱いで起きる手戻りを抑えられます。

LPガスの現場では、遠隔検針や集中監視に加えて、容器残量から配送計画までをつなぐ配送管理が独自の要素になります。

KDDIのガスプラットフォームサービスは、セルラーLPWA(LTE-M)による遠隔自動検針に対応します。

同サービスでは、認定保安機関による24時間365日の保安監視と、需要家向けポータル「gasola」も組み合わせています(出典:KDDI「KDDI ガスプラットフォームサービス」、2026年参照)。

同サービスは日次単位でデータを取得します。加えて、SMS・プラスメッセージ・LINEによる通知配信やポイント加算も提供しています。

都市ガス中心の統合パッケージとLPガス向けの通信・配送基盤では、重視すべき機能が異なります。そのため、自社の業務比重を初期に整理しておきます。

ポイント

対象のガス種と業務範囲を先に決めておくと、基幹系と現場IoT系のどちらから着手するかを判断しやすくなります。ガス種によって業務の重さが違うため、ここを曖昧にしたまま機能を並べないことが大切です。

ガス供給管理システム開発の進め方

対象範囲と現行業務の棚卸し、例外状態を含む要件定義とRFP、PoCと段階導入を3枚のパネルで示す図。
前段で拾った業務や例外を、次の検証と導入範囲へつなげます。

保安と安定供給に関わるシステムなので、本番相当の機能を一度に作り切らず、小さく検証してから対象を広げます。

  1. 対象範囲を確定する
  2. 現行業務とデータを棚卸しする
  3. 要件定義とRFP作成を行う
  4. PoCを行う
  5. 段階導入する
  6. 運用設計を行う

対象範囲の確定と現行業務の棚卸し

最初に、ガス種と需要家数を整理し、拠点数とメーター台数も数えておきます。そのうえで、現場、保安、配送のどこまでを対象にするかを決めます。

開栓から請求まで、警報受信から出動まで、容器残量から配送までの業務フローを図に描き起こします。あわせて、Excelや紙、古い端末に残る例外処理も洗い出します。

拾い切れなかった例外は、PoCやテストの段階で見つかり、追加改修につながりやすくなります。だからこそ、現場担当者へのヒアリングに十分な時間を確保しておきます。

要件定義とRFP作成での例外状態の明文化

要件定義では、機能に加えて、データの扱いと例外時の対応も定めます。文書に明文化するのは、データ、警報、運用の三つの領域です。

  • データ:計測時刻と受信時刻、速報値と確定値、欠測・遅延データの補正方法
  • 警報:初回、継続、復旧、再発の状態遷移
  • 運用:権限、監査ログ、障害時の手動運用、データ移行、SLA

通信断のあとに届くデータは、日常的に発生します。そのため、「いつのデータとして扱うか」を先に決めておかないと、料金計算や保安判定のロジックが二重にも三重にも複雑になります。

RFPに例外ケースの代表例を記載し、各社に同じ条件で提案を依頼します。そうすると、提案内容を比べやすくなります。

PoCと段階導入によるリスクの抑制

実データまたは匿名化データでPoCを行い、次の項目を検証します。

  • 通信遅延
  • 異常値
  • 請求再計算
  • 警報の重複抑止
  • 地図・配送ルート

現場担当者がタブレットで実際に使えるかは、機能デモではなく操作テストで確かめます。

拠点を限定したパイロット運用を経て全社展開すると、想定外の例外処理を全社規模で抱え込む前に修正できます。

導入機能は、次の順に段階的に広げます。

  1. 検針・可視化・料金・基本通知
  2. 保安・工事・配送
  3. 遠隔開閉栓やAI予測

ソフトバンクが2025年7月に公開した土佐ガスの事例では、LPガス配送最適化サービス「Routify」を導入しており、同社は2024年4月から利用しています(出典:ソフトバンク「土佐ガス株式会社 導入事例」、2025年)。

同事例では、ベテラン配送員でも配送計画の作成時間が30分から5〜10分程度に短縮されたと報告されています。小さく始めて効果を確かめる進め方は、この事例にも見られます。

ポイント

要件定義の前に例外処理を洗い出し、現場担当者のヒアリングに時間を割けるかで、PoC後の追加改修が変わります。段階導入の範囲は、小さな検証の結果を見て決めるとよいです。

費用相場とコストの内訳

ガス供給管理システムに特化した公開価格表は少なく、公開情報の多くは個別見積です。

ここでの数字は、検針から保安までを含む業務システムの一般的な工数をもとにした、記事用の概算推定です。実際の見積金額ではありません。

規模別の初期費用と開発期間

初期費用と期間は、機能範囲と拠点数によって変わります。そこで、規模を三段階に分けて概算推定を並べます。

  • 小規模:500万〜1,500万円、4〜8か月が目安
  • 中規模:1,500万〜5,000万円、8〜18か月程度
  • 大規模:5,000万円〜1億円超、18〜36か月になることがあります

小規模は、1施設または少数契約を対象に、使用量や料金の表示と検針を行うMVPを想定します。簡易な管理画面やCSV連携を実装する場合の目安です。

中規模は、複数拠点の契約・料金・請求と異常通知を含む業務連携型で、タブレットやIoT・API連携にもつながります。大規模は、多数拠点の保安・工事・配送を含み、さらにリアルタイム監視や遠隔開閉栓、複数基幹の連携も加わります。

費用を左右する変動要因とランニングコスト

費用は、開発工程、業務と連携の範囲、運用条件の三つに分けて考えられます。高額になりやすい要因も、あわせて見ておきます。

  • 開発工程:業務整理、要件定義、画面・API・データモデル、テスト、教育、切替
  • 業務・連携:料金計算、IoT通信・メーター接続、保安・警報・制御、既存連携、データ移行
  • 運用:運用監視、セキュリティ、通信費、デバイス交換、クラウド利用料

遠隔制御と複雑な料金メニューは、費用を押し上げやすい要因です。加えて、旧システムのデータ品質、複数の通信規格、拠点ごとの例外対応も高額化につながります。

保守・改善費は、初期開発費の年15〜25%を仮に置いておきます。また、通信費、デバイス交換費、クラウド利用料は別枠で見積もります。

パッケージやSaaSでは、初期設定、データ移行、連携開発に100万〜1,000万円程度かかるケースがあります。月額利用、通信、保守の合計が月10万〜100万円程度になる場合もあります。

実額は、契約戸数、メーター台数、保安業務の委託範囲によって大きく変わります。

料金改定や制度変更のたびに開発会社へ都度依頼する契約では、長期的な総保有コストが膨らみやすくなります。料金マスターを業務担当者が安全に変更できる設計かどうかも、初期費用と同じように比べるべき点です。

ポイント

費用は規模、機能範囲、連携の数で大きく変わるため、まず規模を決めてから相場を比べるとよいです。保守費や通信費を別枠で見ないと、長期の総額を見誤りやすくなります。

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

遠隔開閉栓を中央に置き、対象確認、二者承認、実行結果の照合、現場の手動復旧で囲む安全対策図。
操作の前後を確認し、現場で戻せる手段も備える構造です。

見積もりの精度は、開発会社の計算方法だけでなく、発注者がどこまで前提をそろえられるかで決まります。

まず、対象ガス種と業務範囲、データ量を同じ資料にまとめます。連携先、性能要件、受入条件も書き添え、複数社へ同じ条件で依頼します。

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

見積依頼書の条件をそろえておくと、各社が想定する工数の差を抑えられます。対象ガス種と規模を明記し、通信と業務範囲も書き添えます。

  • 対象:需要家数、メーター台数、料金メニュー数、保安業務の委託範囲
  • 機能・連携:通信方式、遠隔制御、検針・請求・会計システムとの連携
  • 例外条件:速報値・確定値、警報状態、欠測・遅延データの補正方針

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

機能一覧の比較に加えて、候補会社に代表的な場面でのデモを依頼します。

  • 代表ケース:欠測データの再計算、警報の重複抑止、料金改定の反映を確認
  • 操作性:業務担当者が実際に安全に操作できるかどうか
  • 選定基準:標準機能への適合度と、独自業務をどこまで競争力にしたいか
  • 構成:「業務パッケージ+クラウドIoT基盤+個別API」のハイブリッドも比べやすい選択肢

注意すべきリスクと対策

制度変更、遠隔制御、制御システムの安全性は、見積の段階で確かめておきます。必要な対応は、仕様書に含めます。

  • 料金制度:三部料金制に沿った料金表示、請求、再計算の設計
  • 遠隔操作:誤操作を防ぐ承認と照合の仕組み
  • セキュリティ:事業被害のシナリオに沿った分析

経済産業省は2025年4月2日にLPガスの三部料金制ルールを施行し、同ルールでは料金を基本料金、従量料金、設備料金に分けて通知します。

ガス消費と関係のない機器費用は、LPガス料金に計上できません(出典:経済産業省「LPガス料金の表示・計上方法に関する新しいルールを施行しました」、2025年)。

料金マスターと請求明細が制度変更に対応できるか、契約更新や過去データの再計算まで含めて確かめます。

遠隔閉栓や開閉栓を実装する場合は、対象確認と二者承認を置き、実行結果の照合や現場の手動復旧まで含むフェイルセーフを要件に入れます。

アプリのボタン一つで無制限に操作できる設計は避けるべきで、仕様書にもその旨を明記します。

IPAの2026年4月版ガイドは、資産ベースと事業被害ベースの両面から分析する方法を示しており、ガス供給の停止や誤制御を検討する際の参考になります(出典:IPA「制御システムのセキュリティリスク分析ガイド 第2版」、2026年)。

ポイント

各社の金額に差が出たとき、対象範囲や連携先、例外条件を同じ資料にそろえておくと、その差が前提の違いによるものかを見分けやすくなります。

よくある質問(FAQ)

進め方はガス種や業務範囲によって変わるため、検討の初期によく出る疑問に、期間や体制も含めて答えます。

ガス供給管理システムの開発は何から始めればよいですか?

まず対象ガス種と業務範囲を確定し、現行業務のフローと例外処理を棚卸しします。そのうえで、検針、料金、保安、工事、配送のどこまでを含めるかを決めます。

代表的な業務ケースを、期待する結果と合わせて作ります。それを要件定義とRFPに反映すると、開発会社との認識のずれを防ぎやすくなります。

開発期間はどれくらいかかりますか?

開発期間の目安は、小規模の表示・検針MVPで4〜8か月、中規模の業務連携型で8〜18か月です。大規模の基幹・供給管理型では18〜36か月になります。

段階導入にすれば、最初のMVPを短期間で出せます。保安や配送の最適化は、効果を確かめながら後から追加できます。

社内にIT担当者が少なくても開発を進められますか?

進められます。ただし、業務ルールや例外処理を最もよく知っているのは、現場の検針員や保安担当者です。

要件定義とPoCの段階では、現場担当者が一定時間ヒアリングや操作検証に参加できる体制を組みます。

開発会社へすべてを任せきりにすると、保安判定や料金計算の細かな例外が抜け落ちるリスクが高まります。

まとめ

開発は、対象ガス種と業務範囲を定め、現行業務とデータを棚卸ししてから進めます。その後、要件定義、RFP作成、PoC、段階導入、運用設計の順に進めるのが基本です。

計測時刻と受信時刻、速報値と確定値、警報の状態遷移を初期に決めておくと、後工程の手戻りを抑えられます。警報処理や料金計算の例外を早めに確認すると、稼働直前の仕様変更も減らせます。

概算推定では、小規模な表示・検針MVPが500万〜1,500万円、中規模の業務連携型が1,500万〜5,000万円です。大規模な基幹・供給管理型は、5,000万円〜1億円超が推定レンジです。

見積もりでは、対象範囲と通信方式を明確にし、保安業務の委託範囲や遠隔制御の有無も示します。複数社へ同じ条件で依頼します。

現場担当者を交えて業務を棚卸しし、小さなPoCを重ねることが大切です。導入は検針・料金・基本通知から始め、保安・配送へ段階的に広げます。段階導入は、供給を止めずにシステムを刷新するための、最も確実な近道です。

▼全体ガイドの記事
・ガス供給管理システム開発の完全ガイド

会社紹介

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

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

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

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

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

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