ガス供給管理システム開発の発注/外注/依頼/委託方法について

ガス供給管理システムの発注は、現場の業務整理からRFP（提案依頼書）の作成、匿名化データでのPoCを経て、契約形態を選び、委託先を選定する順に進めます。この順で進めると、各社の提案を同じ条件で比べられます。

発注形態は4種類から選び、費用は規模と契約形態で見通しが変わります。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

ガス供給管理システムの発注・外注の選択肢

発注形態は4種類に整理できます。形態によって必要な体制や契約方式、費用感が変わるため、発注準備の初期に方向性を決めておきます。

発注形態の選択肢

業務要件や既存基盤に合わせて、4つの形態から選びます。

• 既製パッケージ：標準機能と導入ノウハウを生かせます。
• クラウド・SaaS：拠点やIoTデータの増加、ポータル公開、分析に合った形態です。
• スクラッチ開発：独自の料金体系や配送、導管、顧客サービスを強みとして作り込めます。
• ハイブリッド：業務パッケージ、クラウドのIoT基盤、個別APIを組み合わせた構成です。

パッケージは、料金改定や保安業務に適合する製品なら導入を短期化できます。また、SaaSでは、通信断や権限、データの所在、従量課金の条件を事前に確認しておきます。

スクラッチ開発では、法改正への対応と保守を自社が長期的に担います。一方で、ハイブリッド構成は実務上、発注先を比較しやすい選択肢です。

外注のメリットと発注前の注意点

外注先との役割分担を決めるには、期待できる効果と、発注側が担う確認事項を分けて考えます。

• 専門性を補える：IoT通信、保安制御、料金計算エンジンの設計などの知見を借りられます。
• 体制を早く立ち上げられる：採用や育成から始めるより短い期間で、開発の態勢を整えられます。
• 責任分界を明確にする：料金と保安、配送の責任範囲を発注時に決めておきます。

丸投げに近い発注では責任分界が曖昧になり、障害時に対応が遅れるおそれがあります。加えて、安価な画面開発会社だけに任せないことも大切です。

検針・料金計算、通信・IoT基盤、配送最適化を別々の会社が担うケースも珍しくありません。そのため、発注側が全体構成図を作成し、各社の責任範囲を共有します。

責任の所在が定まらないと、障害発生時に委託先間の調整が必要になり、復旧が長引きます。全体構成図の作成は、外注を成功させる前提です。

発注・外注の進め方

発注側が準備から委託先を決めるまでに固める内容を、順を追って見ていきます。

1. 現場ヒアリングで業務を整理する。
2. 業務ケースを盛り込んだRFPを作る。
3. 匿名化データを使ってPoCを実施する。
4. 工程に合わせて契約形態を選ぶ。
5. 同じ条件で委託先を選定する。

現場ヒアリングとRFPの整理

各社の提案条件をそろえるには、現場の業務とシステム要件をRFPに反映しておく必要があります。

• 業務フロー：検針員、保安担当者、配送員、コールセンター担当者に聞きます。
• 業務の例外：開栓から請求、警報受信から出動、容器残量から配送までの流れで例外を洗い出します。
• 規模と対象：対象ガス種と需要家数、拠点数、メーター台数を記載します。
• システム要件：通信方式と既存連携、データ移行範囲、SLAを書き込みます。
• 保安要件：委託範囲と遠隔制御、警報の状態遷移を示します。

計測時刻と受信時刻の扱いも、代表的な例外ケースとあわせてRFPに入れておきます。そうすれば、各社から同じ条件で提案を受けられます。

匿名化データでのPoCと契約形態の選択

要件を整理した後は、実データか匿名化データを使ってPoCを行います。検証する対象と、契約形態ごとの違いも確認します。

• PoC：通信遅延と異常値、請求の再計算、警報の重複抑止を検証します。
• 請負契約：要件が固まった範囲を、成果物と納期で管理します。
• 準委任契約：要件探索や高度な設計を含め、体制と時間で進めます。
• SaaS契約：パッケージやクラウドサービスを利用します。

要件定義やPoCは準委任、確定機能の開発は請負とするように、工程ごとに契約形態を分ける方法も有効です。

委託先選定から契約締結までの流れ

委託先の候補には、同じ代表ケースでデモをしてもらい、契約条件も確かめます。

• 成果と検収：成果物と検収条件、SLAを取り決めます。
• 障害対応：障害時の対応範囲を確認します。
• 権利とデータ：ソースコードとデータが誰に帰属するかを明らかにします。
• 契約終了時：データをどう書き出せるか（エクスポート方法）を確かめます。
• 制度変更時：料金改定などの窓口と費用負担を決めます。

ソフトバンクが2025年7月に公開した土佐ガスの事例では、配送業務など特定の領域から段階的に外注しています（出典：ソフトバンク「土佐ガス株式会社 導入事例」、2025年7月）。

段階的に進めると、契約リスクを抑えながら効果を検証できます。見積もりの提示を受けるときは、候補会社の業務理解も確かめます。

都市ガスの保安規程やLPガスの配送・容器管理など、対象ガス種の特性に沿った質問が出るかは、実務への理解を測る材料になります。また、業界特有の例外処理について尋ねず、概算金額だけを示す会社は、契約後に追加費用や仕様変更が生じやすい傾向があります。

費用相場とコストの内訳

ガス供給管理システムに特化した公開価格表は少ないため、ここに示す金額は記事執筆用の概算推定です。検針・請求から、IoT・配送・保安までを含む業務システムの一般的な工数をもとにしています。

• 小規模：可視化・検針MVPは500万〜1,500万円で、期間の目安は4〜8か月です。
• 中規模：業務連携型は1,500万〜5,000万円で、期間の目安は8〜18か月です。
• 大規模：基幹・供給管理型は5,000万円〜1億円超で、期間の目安は18〜36か月です。

契約形態による費用の違い

契約形態によって、費用の見通しや変動要因は異なります。総額だけでなく、追加費用と継続課金も比べる必要があります。

• 請負：総額は見通しやすいものの、追加の要望には別途費用が生じやすい契約です。
• 準委任：要件がまだ不確かな探索やPoCに合い、稼働時間によって費用が変わります。
• SaaS：初期費用は抑えやすいものの、戸数やメーター台数に応じた月額費用が続きます。

SaaSは、長期的な総保有コストで比べます。準委任契約では、進め方によってコストが変動します。

外注後に発生するランニングコスト

外注後は、保守費や通信費などが継続して発生します。そこで、費目ごとに見落としやすい確認点を押さえておきます。

• 運用保守費：初期開発費の年15〜25%が一つの目安です。
• 別枠の費用：通信費、デバイス交換費、クラウド利用料がかかります。
• 従量課金：利用台数や検針数によって、月額費用が変わることがあります。
• 契約時の確認：台数の増減や制度変更で生じる費用を、契約前に確かめます。
• 費用管理：契約時に、誰が何にいくら払い続けるかを一覧にします。

NCU台数と検針数に応じた月額従量課金を採用するケースもあり、その一例がKDDIのガスプラットフォームサービスです（出典：KDDI「KDDI ガスプラットフォームサービス」、2026年1月改定）。

契約前に台数の増減シナリオを当てはめておくと、想定外の費用増を抑えられます。

LPガスの三部料金制は2025年4月2日に施行されました（出典：経済産業省「LPガス料金の表示・計上方法に関する新しいルールを施行しました」、2025年）。そのため、制度変更のたびに追加の改修費が発生する契約になっていないかも、発注前に確かめておきます。

保守費は開発会社、回線とデバイスの費用は通信キャリア、利用料はクラウド事業者から、それぞれ別に請求されることが多くあります。

社内の予算管理でも、費用の発生源ごとに分けて把握しておくと、数年後の見直しで判断しやすくなります。

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

見積もりは金額だけでなく、各社を同じ条件で評価します。加えて、責任分界とベンダーロックイン回避も確かめます。

複数社の同じ条件での比較

金額差の理由を見分けるには、各社に共通して示す業務ケースと見積条件をそろえる必要があります。

• 代表ケース：欠測データの再計算と警報の重複抑止、料金改定の反映を含めます。
• 対応範囲：標準機能で対応できる範囲と、追加開発が必要な範囲を分けてもらいます。
• 費用内訳：業務整理・要件定義、実装、連携・移行の工程ごとに分けます。
• 工程内訳：テスト・教育・切替、運用監視・セキュリティも示してもらいます。

見積書を「一式」でまとめず工程別に出してもらうと、金額差の理由が見えてきます。

責任分界とベンダーロックイン回避の確認

障害対応や委託先の変更に備えて、契約で明文化したい情報と責任を整理します。

• 責任範囲：料金ルールや実績欠損、外部サービス停止、請求誤りを、誰が担うか定めます。
• 移行データ：移行後のデータ不一致やセキュリティ事故の責任を明記します。
• データとAPI：所有者、API仕様、エクスポートの方法を押さえます。
• 引き継ぎ資料：API仕様やデータ辞書、テストケース、運用手順を自社にも残します。

資料を自社に残せる契約であれば、将来の乗り換えや、複数ベンダーへの分散発注を進めやすくなります。

パッケージやクラウドでは、契約終了時に検針・保安・料金のデータを標準形式で出せるかを確かめます。

需要家データや過去の料金改定履歴が製品の中に閉じていると、乗り換えのハードルが高まります。そのため、エクスポートの仕様と、それに費用がかかるかどうかも、事前に確かめておきます。

注意すべきリスクと対策

遠隔閉栓や開閉栓を実装する場合は、誤操作や復旧の遅れへの対策が欠かせません。仕様には、安全策を組み込みます。

• 対象確認：操作する対象を確かめる手順を設けます。
• 二者承認：実行の前に、二者で承認する仕組みです。
• 結果照合：操作の実行結果と、意図した状態を照らし合わせます。
• 手動復旧：現場で手動に戻せるフェイルセーフを含めます。

アプリのボタン一つで無制限に操作できる設計は避けます。委託先が制御システムのリスク分析を踏まえて提案するかどうかも確かめます。

IPAの2026年4月版「制御システムのセキュリティリスク分析ガイド」は、資産ベースと事業被害ベースの分析を示しています（出典：IPA「制御システムのセキュリティリスク分析ガイド 第2版」、2026年）。そのため、ガス供給の停止や誤制御を事業被害シナリオとして検討する際の参考になります。

よくある質問（FAQ）

発注・外注では、契約形態や責任分界について質問が多く寄せられます。判断に迷いやすい3つの疑問に、順に答えます。

請負契約と準委任契約はどちらを選べばよいですか？

要件が明確な工程は請負、要件探索やPoCなど不確実性の高い工程は準委任が向いています。

要件定義やPoCは準委任、確定機能の開発は請負のように、工程ごとに使い分けられます。加えて、完成条件や検収基準、変更管理のルールも契約前に確かめます。

1社に全業務を委託すべきですか、複数社に分けるべきですか？

選択は業務範囲と自社の管理体制によります。1社への一括委託は窓口を一本化できる一方で、ベンダーロックインのリスクが高まります。

基幹（顧客・料金）、通信・IoT、配送最適化を複数社に分けるときは、API仕様やデータ連携の責任分界を、発注側が整理します。

自社にプロジェクト管理の余力が少ないときは、一気通貫で支援できる会社に相談する方法もあります。

RFPを作成する前に何を準備すればよいですか？

RFPの準備では、対象ガス種と需要家数、拠点数、既存システム一覧を押さえます。通信方式、保安業務の委託範囲、遠隔制御の要否も、あわせて用意しておきます。

欠測データの再計算や警報の重複、料金改定の反映など、代表的な業務ケースも用意します。現場ヒアリングの後に作成すると、例外処理を含められるため、見積もりの精度が高まります。

まとめ

発注前には、既製パッケージやクラウド・SaaS、スクラッチ、ハイブリッドの4形態から選び、現場ヒアリングをもとにRFPを整えます。そのうえで契約形態を工程ごとに使い分け、責任分界とデータ移行も確かめます。

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

責任分界とデータの帰属、契約終了時のエクスポート方法まで含めて複数社を比べ、保安と安定供給を維持できる委託先を選びます。

発注・外注のゴールは、供給を止めずにシステムを刷新し続けられる関係を築くことです。そのためには、現場ヒアリングとRFP整理に時間をかけ、責任分界を明確にした契約を結ぶことが、長期的な運用コストとトラブルを抑える近道になります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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