石油/エネルギー業界のシステム開発の進め方/やり方/流れや方法/手法/工程/手順

石油・エネルギー業界のシステム開発は、現場業務を標準化してから要件を定め、段階的に開発と移行を進めるのが全体の流れです。安全と安定供給を止めないことを前提に、一つずつ順番に進めます。

業界特有のシステム、開発の段階、費用の目安、見積もりの確認点を、この順に取り上げます。

石油・エネルギー業界のシステム開発の全体像

APIやデータ連携基盤を中心に、業務基盤、設備・操業、物流・環境、トレーディングをつないだ図。
領域ごとに役割を分けて連携する構成です。

石油・エネルギー業界のシステムは、販売管理や会計だけの基幹システムとは性格が異なります。設備や操業のデータをつなぎ、現場の判断を経営に届ける業務基盤です。

扱う対象には、在庫や調達、輸送のデータが含まれます。需給のデータに加え、法令と安全、環境のデータも対象です。社会インフラに関わる企業では、停止した場合の損失がシステム部門だけにとどまりません。

そのため、開発前に「何を止めてはいけないか」を決めておく必要があります。業界特有の難しさを把握すると、守るべき条件を要件に反映できます。

開発が難しい3つの理由

開発が難しい理由は、稼働設備を止めにくいこと、危険物と設備を正確に管理する必要があること、脱炭素への対応が求められることの三つです。

  • 設備と供給網:24時間稼働し、簡単には止められない設備と供給網です。
  • 危険物と設備:原油、LNG、石油製品、薬品、タンク、配管、ボイラーを正確に管理する対象です。
  • 脱炭素と経営:安定供給と収益性を保ちながら、脱炭素の進捗も説明しなければなりません。

2025年のエネルギー白書は、安定供給、経済成長、脱炭素の同時実現を示しています(出典:資源エネルギー庁「エネルギー白書2025」)。

組み合わせるシステムの構成

構成は4つの領域に分かれ、扱うデータも役割も異なります。そのため、領域ごとに組み合わせるシステムを選びます。

  • 業務基盤:ERPなどで販売、購買、会計、在庫を扱う領域です。
  • 設備・操業:保全はEAMまたはCMMSで行い、MESやDCS・SCADAで操業データを扱います。
  • 物流・環境:WMS、輸送管理、エネルギー管理、環境データ基盤の組み合わせです。
  • トレーディング:原油やLNGの契約、船積み、為替、価格指標、ヘッジ、在庫評価の管理です。

各領域を一つの巨大なシステムにまとめるのではなく、責任範囲と連携データを決めたうえで別々に組みます。APIやデータ連携基盤で接続しておくと、変更に対応しやすい場合があります。

業界特有の機能要件

業界特有の機能要件を、設備保全から法令・安全までの4つの領域ごとに見ていきます。

  • 設備保全:センサーの時系列データから異常兆候を検知する機能です。
  • 需給管理:需要予測と発電・調達計画の調整を担います。
  • 資源取引:国際相場や為替の変動を、契約、在庫、利益に反映させます。
  • 法令・安全:点検記録、承認履歴、資格、期限を追跡できること。

設備保全では、点検、部品、作業員、停止計画を設備単位でまとめて扱います。需給調整では、蓄電池や分散電源、気象情報も判断材料になります。

法令要件には、消防法や高圧ガス保安法などが関係します。そのため、点検記録や承認履歴を追跡できる設計が求められます。

ポイント

迷ったときは、まず止めてはいけない業務と設備を決め、そのうえで各領域の責任範囲と連携データを切り分けてください。業界特有の制約は、この段階で要件に反映しておくと後の手戻りを減らせます。

石油・エネルギー業界のシステム開発の進め方

現場の状況調査から企画、要件定義と基本設計、開発とシステム連携とテスト、移行と現場定着へ進む工程図。
現場の整理を起点に、段階を追って進みます。

開発では、まず現場のリスクと業務の流れを一覧にして把握し、機能一覧はその後に整理します。企画から定着までを順に進めると、要件の抜け漏れを抑えられます。

  1. 企画を立て、現場の状況を調べる。
  2. 要件を定め、基本設計に進む。
  3. 開発と他システムとの連携を進め、テストする。
  4. 移行し、現場に定着させる。

設備や危険物を扱う現場では、安全ルールの標準化をシステム化より先に行います。この進め方はAX(アナログ・トランスフォーメーション)と呼ばれ、要件の抜け漏れを減らせます。

現場のアナログ業務の標準化

まずは担当者へのヒアリングと現場観察から始めます。業務の流れに沿って、各時点で誰が何を確認し、異常が起きたときに誰へ連絡するかを記録していきます。

  • 燃料の流れ:受け入れから港湾輸送、倉庫での保管、発電所への搬入までの各段階。
  • 安全チェック:散水、異物の目視確認、温度記録、定時連絡の手順を一覧にします。

紙や電話で行っているチェックを先に統一しておくと、アプリへ置き換えるときの判断が明確になります。また、ベテランの勘をそのままAIで自動化すると決めつけないことも大切です。

判断条件と例外を文章にまとめ、記録者と承認者も明記します。正常値と異常値の境界は、現場と合意しておきます。未整理のまま画面を作ると、入力されない項目が増え、データが蓄積されなくなります。

要件定義での安全・供給・収益・GXによる分類

部門別の機能一覧だけでは、どの要件を先に固めるかが見えにくいため、要件は目的ごとに分けて整理します。この分類によって、優先順位を判断しやすくなります。

  • 安全:権限分離、承認、作業前確認、監査ログ、通信断時の運用を決めておく。
  • 供給:冗長化、バックアップ、目標復旧時間、切り戻し方法の決定。
  • 収益:収益面の状況を把握する要件を整理します。
  • GX:脱炭素の取り組みを説明する要件です。

設備保全では、設備台帳と点検周期を一つの設備IDにひも付けて扱います。部品や故障コードは同じIDでそろえ、作業履歴と停止計画も同じ流れで扱います。

EMSでは、予測の更新頻度と実績データの遅延を前提に決めておきます。気象データを取得できないときの扱いも定め、手動調整へ切り替える条件をあらかじめ決めておきます。

Scopeの要件では、燃料使用量や購入電力、輸送を扱います。原材料や製品の使用、廃棄も対象に含めます。加えて、どの単位で集計し、誰が証跡を確認するかも決めます。

止めない前提での設計・テスト・移行計画

基本設計では、システム間のデータ項目と連携頻度を決めます。障害時の再送と時刻の扱い、権限、ログ保存期間も、ここで定めておきます。

  • 接続方式:クラウド利用時でも、ネットワーク断の際に最低限の操業や安全確認を続けられる、エッジ側の仕組みを検討します。
  • テスト:センサー値の欠落、通信遅延、重複データ、誤った設備IDを再現します。
  • 移行:旧システムの参照期間、並行稼働の範囲、照合責任者、切り戻し判断時刻。

クラウドとオンプレミスは、領域ごとに組み合わせて選べます。判断では、リアルタイム性や機密性、可用性を領域ごとに評価します。保守性と将来の拡張性も、同じ基準で見ます。

テストでは、停電や承認者の不在も再現しておきます。夜間や休日の切り替えだけに頼らず、フェールセーフの計画も用意します。

旧システムの刷新は多くの企業の課題です。IPAの「DX動向2025」でも、DXの課題が取り上げられています。その中には、レガシーシステムの刷新やデータ利活用が含まれます。AI活用と内製化も、課題として扱われています(出典:IPA「DX動向2025」、2025年)。

旧システムは、参照系から少しずつ連携させ、検証を重ねながら切り替えます。段階的に移行すると、業務への影響を抑えやすくなります。

ポイント

迷ったときは、現場の業務を文章で標準化してから要件定義に進んでください。移行では、切り戻しの判断時刻と条件まで決めておいてください。

石油・エネルギー業界のシステム開発費用相場

小規模、中規模、大規模の3枚のパネルに、本文記載のシステム開発費用の試算レンジを示した図。
複数拠点の統合まで対象を広げると、試算レンジも上がります。

開発費は機能数に加えて、設備や制御系との接続、24時間運用、法令対応によって決まります。データ移行、セキュリティ試験、教育も費用に影響します。

そのため、単純な業務アプリと比べて高額になりやすいです。以下に示すのは2026年時点の発注検討用の目安で、公開された一律の市場価格ではありません。

体制、期間、人月単価を前提に置いた試算として見てください。規模ごとの金額の幅と、初期費用以外の支出を分けて確認します。

規模別の費用目安

対象範囲が広がるほど、費用の目安も大きくなります。現場単位から複数拠点の統合まで、範囲ごとに比べてみてください。

  • 小規模:点検・申請をスマートフォンやWebで標準化する場合、要件定義から本番化まで500万円から1,500万円程度の試算になることがあります。
  • 中規模:複数拠点の設備保全、在庫、ERP連携まで含める場合は、2,000万円から8,000万円程度で検討します。
  • 大規模:ERP、EAM、EMS、IoT、環境データを複数拠点で統合する刷新では、8,000万円から数億円規模になることもあります。

業務・設備・データ連携の担当者を含む平均6人の体制を12か月間続け、1人月100万円で計算します。すると、本体費用は6人×12か月×100万円で7,200万円になります。この例に要件定義や移行を加え、さらにセキュリティ試験、現場教育、予備費を見込むと、総額は1億円前後まで広がる可能性があります。

人数と期間、単価に分けると、見積金額のどこに差が出ているかを確かめられます。対象範囲も併せて見ておくと、比較の材料がそろいます。

開発費以外のコスト

総費用を把握するには、初期費用、機器・基盤費、運用後の支出を分けて確認します。

  • 初期費用:企画・要件定義から、設計、実装、試験、移行、教育、プロジェクト管理までが含まれます。
  • 機器・基盤費:センサー、ゲートウェイ、ネットワーク、クラウド利用料、バックアップ、監視、脆弱性診断、現場端末でかかる費用です。
  • 運用後の費用:問い合わせと障害対応、OSやミドルウェアの更新、法令・帳票の変更、機器交換、予測モデルの再学習を伴います。

保守費を開発費の一定割合だけで判断すると、実際の運用条件を見落とすおそれがあります。金額を左右するのは、24時間監視の有無、復旧目標の時間、現場の代替手順です。

クラウドは初期のサーバー購入を抑えやすい一方、月額はデータ量や通信量で変わります。監視やバックアップの利用量も、費用に影響します。また、オンプレミスでは設備更新と保守要員が必要になります。

5年程度のTCO(総所有コスト)で比べ、障害時の損失も含めて稟議に示します。

GX投資のROIの算出方法

GXの稟議では、効果を3つの観点に分けて記載します。

  • 費用と工数:電気代、燃料費、測定・集計・報告にかかる工数です。
  • 早期対応:漏えいや異常の早期発見、設備停止の回避を効果として含めます。
  • 排出量集計:燃料、購入電力、輸送、原材料の量に排出係数を掛けて求めます。

環境省はScope1を自社の直接排出、Scope2を購入電力などの間接排出、Scope3をその他のサプライチェーン排出と整理しています(出典:環境省「サプライチェーン排出量の考え方」)。

たとえば、年間で27トンの樹脂購入と廃棄を削減できる場合を考えます。製造時には、1kgあたり1.483kg-CO2を社内の値として採用します。焼却時は、1トンあたり2,765kg-CO2を社内の基準として用います。

製造と廃棄を合わせた削減効果は、年間約114.7トンと試算できます。この数値は、原単位と活動量の妥当性を確かめてから使います。削減量と金額換算、投資回収年数を一枚にまとめると、業務効率化だけでは通りにくい投資も説明しやすくなります。データの証跡も添えておくと、説明の根拠がそろいます。

ポイント

迷ったときは、費用を規模や体制、期間、単価に分けて比べ、初期費用だけでなく運用後の支出も含めてください。5年程度のTCOで比べ、障害時の損失も含めて稟議に示してください。

石油・エネルギー業界のシステム見積もりを取る際のポイント

見積もりでは、合計金額の安さより、同じ前提条件で比べられるかを先に確かめます。設備接続やデータ移行、停止を伴う切替が抜けると、追加費用になりやすいです。セキュリティや現場教育も、抜けがないか見ます。

RFPや要件資料の記載内容

RFPや要件資料には、対象範囲と運用条件を記載します。設備や業務の種類に応じて、数量と頻度も示します。

  • 共通情報:拠点、設備、利用者、業務、現行システム、連携先、データ量、更新頻度を記載します。
  • 設備保全:設備台数、センサー数、点検周期、部品点数を示します。
  • EMS:予測の対象と間隔、制御の対象、気象・市場データの取得方法を書きます。
  • 危険物管理:点検、承認、資格、期限、帳票、監査ログに関する要件を明記すること。

稼働時間や復旧目標も、資料に含めます。要件の確定度は、「確定」「候補」「今後検証」の区分で分けておきます。

現場の追加要望は、すべてを初回開発に含めるのではなく、法令・安全や稼働に必須の機能と、効果検証後に加える機能に分けます。要件を凍結する日と変更管理の方法を決めておくと、過剰なカスタマイズを防げます。

開発会社の選定基準

候補となる会社は、実績、技術、運用体制から確認します。特に、同業界や危険物、社会インフラ案件の経験は、比較の材料になります。

  • 業界経験:同業界や類似案件の実績を、社名や導入製品だけでなく、対象拠点数や停止を伴う移行の有無まで確認します。
  • 技術・運用:24時間運用、EAM・ERP・IoT・データ連携の経験の有無。
  • 担当範囲:保守の範囲と、現場ヒアリングやデータ移行をどこが担うか。

提案書の機能だけでなく、障害時の体制も確かめておきます。そのうえで、どこまでを発注側と開発会社のどちらが受け持つかを明確にします。

設備、危険物、顧客・仕入先の各マスタを、誰が確認するかを決めておきます。旧システムからのデータ抽出を担う人と、受入テストの合否を判断する人も、契約書や計画書に記載します。

データ整備を開発会社に任せきりにすると、品質問題の原因が見えにくくなります。その影響は、後から費用と納期の両方に及びます。

見積もりのリスクの抑え方

見積もりのリスクは、代表拠点でPoCや小規模導入を行い、事前に確かめておくと抑えやすくなります。最初から全拠点や全設備を対象にせず、範囲を絞って始める方法です。

  • 予知保全:故障履歴とセンサー値がそろう設備で検証する。
  • AX:紙のチェックリストをデジタル化し、入力時間や異常報告の速さ、未実施件数を測定する。
  • 契約条件:追加開発の単価、移行の前提、第三者サービス費用、検収、障害の優先度、保守の応答時間。

予知保全は、検知精度だけでなく、検知後に点検や部品手配が変わったかも評価します。

遅延の原因は、発注者の要件変更とデータ不備に分けて管理します。開発会社の遅延や外部サービスの変更も、原因ごとに管理します。

リスクの一覧は月次で更新し、重大なリスクは経営会議へ早めに報告します。

ポイント

迷ったときは、同じ前提条件で複数社の見積もりを比べられるかを確かめ、設備接続や移行、教育が含まれているかを見てください。

石油・エネルギー業界のシステム開発でよくある質問

企画段階でよくある質問に、順に答えます。答えは、設備数や拠点数、既存システム、停止許容時間に応じて、現状調査と要件定義で具体化します。

石油・エネルギー業界のシステムはクラウドとオンプレミスのどちらがよいですか?

業務と設備の特性に応じて役割を分け、クラウドとオンプレミスを組み合わせる考え方があります。たとえば、経営・分析・環境データはクラウドに、制御系や通信断時に必要な機能は現場側に置く方法があります。

クラウドに集めたデータは、AI活用にも使えます。IEAは2025年の「Energy and AI」で、AI活用の例を挙げています。その中には、予知保全や遠隔操作、漏えい検知が含まれ、規制対応も例として挙げられています(出典:IEA「Energy and AI」、2025年)。

これらの活用には、データ品質と安全な運用設計が前提です。

予知保全やAIを最初から導入すべきですか?

まずは、必要なデータがそろう代表設備で小さく検証します。最初から全設備へ導入する必要はなく、検知後に現場の作業が変わるかも、あわせて確かめます。

検証には、設備IDとセンサーの時刻が必要です。さらに、故障履歴と点検結果もそろえておきます。故障データが少ない場合は、点検記録と異常報告を標準化して、データを蓄積します。

システム開発費用を抑えるにはどうすればよいですか?

対象範囲を小さく絞り、標準機能を優先します。データと要件を整えてから発注すると、費用の抑制にもつながります。

代表拠点で効果を測り、不要なカスタマイズは避けます。安全や法令、復旧、監査に関わる機能は削らない一方で、帳票や通知など後から追加できる機能は段階的に分けます。

24時間稼働のプラントを止めずに移行できますか?

停止の有無は、領域ごとに分けて考えます。停止ゼロと断定せず、止められる領域と止められない領域を見極めて、段階移行、並行稼働、切り戻しを組み合わせます。

データを複数回移行して差分を照合し、本番切替前に障害訓練をします。切替の判断者と判断時刻、連絡網を決めておきます。紙や電話による代替手順も、あわせて用意します。

まとめ

石油・エネルギー業界では、安全ルールとデータを整えたうえで、止められない業務を守りながら段階的に開発を進めます。

全体像を把握したうえで、予知保全やEMS、トレーディング管理を必要な順番に組み合わせます。危険物管理やGXデータ基盤も、同じ考え方で進めます。

成功する開発の要点

成功のポイントは、アナログ業務を標準化してからデジタル化すること、安全・供給・収益・GXの要件を分けること、代表拠点で小さく検証することです。

費用はTCOで比べます。移行や教育、機器の費用に加えて、通信、保守、障害対応も含めて見ます。見積もりでは、設備・危険物マスタをどこまで誰が受け持つか、受入テスト、切り戻し条件を必ず確認します。

参考にした公開情報

参照した公開情報は、資源エネルギー庁「令和6年度エネルギーに関する年次報告(エネルギー白書2025)」、同庁「電力システム改革の推進」です。

IPA「DX動向2025」、IEA「Energy and AI」、環境省「脱炭素社会の実現に向けた温室効果ガス排出量の算定」を参照しています。

費用は、企業規模や拠点数、設備接続によって変わります。既存システムやセキュリティ要件、移行方式も、金額を左右します。投資判断では、現状調査と要件定義を行ったうえで、同じ前提の複数社の見積もりを比べてください。

会社紹介

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

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

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

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

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

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