石油/エネルギー業界のシステム開発の発注/外注/依頼/委託方法について

石油・エネルギー業界のシステム発注は、現場調査、要件定義、段階的な開発・移行の順に進めると、安全な運用と継続的な改善につながります。

まず発注形態を選び、RFPと要件を整理します。そのうえで、開発工程や費用、委託先の選び方を見ていきます。全体像は「石油・エネルギー業界のシステム開発を発注する前に知るべき全体像」もご覧ください。

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

石油・エネルギー業界のシステム開発を発注する前に知るべき全体像

石油・エネルギー業界のシステムは、調達から環境報告まで、業務の流れをつなぐ業務基盤です。

発注側は、販売管理や勤怠管理の範囲を決めるときに、停止時の影響や現場で入力できる条件、データの保証責任も、あわせて決めておきます。

資源エネルギー庁のエネルギー白書2025は、GXやエネルギー安全保障、燃料サプライチェーンの強化を継続課題として扱っています（出典：経済産業省・資源エネルギー庁「エネルギー白書2025」）。

無停止・安全・脱炭素の三つが重要な理由

無停止・安全・脱炭素の要件を決めるには、事業停止、現場での誤り、排出量の説明に関わる影響を、先に洗い出しておく必要があります。

• 供給・製造の継続：基幹システムが止まると、出荷・在庫・配車・保全指示へ影響が連鎖し、復旧後もデータ整合性の確認に時間がかかります。
• 安全管理：誤入力や異常の見落としは、安全事故につながります。
• 排出量の説明：燃料や電力、Scope1・2・3、調達先まで含めた説明が必要です。

発注側は、無停止・安全・脱炭素の要件でも、機能要件と同じ細かさで、復旧の目標値（RTO、RPO）、監査証跡、承認権限を定義しておきます。

システム化の対象となる領域

システム化の候補は、業務基盤から環境データまで、領域ごとに分けて考えられます。

• 業務基盤：購買、会計、在庫をERPで扱います。
• 設備と需給：保全はEAMやCMMSで行い、需給の予測と調整はEMSが担います。
• 現場データ：IoTによるセンサーの収集と、原油やLNGの相場・為替のトレーディング管理です。
• 安全と環境：安全点検、品質、環境データ基盤が対象です。

全領域を最初から一つにまとめなくてもよく、まずは停止リスクが高い業務と、データ連携の起点になるマスタを見極めます。

対象を段階的な発注単位に分けておくと、予算と責任の境界を管理しやすくなります。

発注形態の選び方

発注形態は、成果物を受け取るのか、専門チームと改善を続けるのか、企画から伴走を受けるのかで選びます。判断材料になるのは、要件がどこまで決まっているかと、現場の変化の大きさです。

社内のプロジェクト管理力と、停止できない業務の範囲も確かめておきます。判断は、会社の規模よりも、これらの状況から組み立てます。

請負型・準委任型・ラボ型の使い分け

契約形態ごとに、向いている工程と変更時の扱いが異なります。そのため、要件がどこまで固まっているかに合わせて選びます。

• 請負型：成果物を完成させる契約で、要件と受入条件が固まった作業向けです。
• 準委任型：専門家の作業や時間を委託する契約です。
• ラボ型：一定期間チームを確保して継続改善し、複数拠点の小規模改修を続ける形です。

請負型はERP連携や定型画面の改修に向いていますが、途中で要望が増えると、変更契約や納期の延長が起こりがちです。

準委任型は、要件探索やデータクレンジング、既存設備との接続調査など、開始時に作業量を確定しにくい工程に適しています。

パッケージ導入とフルスクラッチ開発の使い分け

費用と保守性を左右するのは、現場固有のルールをどこまで残すかです。

• 共通業務：会計・購買・在庫・保全は、標準パッケージを中心に業務を合わせます。
• 独自業務：燃料品質判定・安全インターロック・需給計画・固有の収益管理は、拡張や個別開発を検討します。

共通業務を標準に寄せれば、初期費用と保守負担を抑えられます。一方で、特殊ルールをすぐにカスタマイズすると、費用が膨らみます。

個別開発に進む前に、まず標準機能と設定で足りるかを見て、次にアドオンや外部連携を検討し、最後にスクラッチを考えます。

RFPと要件整理の進め方

RFPは、何を、なぜ、どの条件で提案してほしいのかを、開発会社へ伝える文書です。機能一覧に加えて、現場業務、制約、優先順位を書き、将来計画や提案範囲もまとめます。

IPAの開発分析資料では、規模や工数に加えて、ユーザー要求の明確さや担当者の関与状況も扱われています（出典：独立行政法人情報処理推進機構「ソフトウェア開発分析データ集」）。

RFPに最低限入れる項目

提案範囲と前提を揃えるため、RFPには次の内容を書き込みます。

• 業務と体制：背景・目的、対象の拠点・業務、現行システム、利用者を記します。
• データと連携：データ量と外部連携、移行対象を示します。
• 運用条件：稼働時間、セキュリティ、法令や監査の要件です。
• 計画条件：予算、希望時期、提案範囲を明記します。

提案側が現場の実態をつかめるよう、現場の帳票・点検記録、承認ルート、異常時の連絡手順も添付します。

設備・危険物マスタは、項目名や管理責任者を明記し、コード体系と更新頻度も書き添えます。

さらに、設備・危険物マスタの過去データの品質も示しておきます。整備を開発会社任せにすると、どの値を正とするかを巡って手戻りが生じます。

高度なシステムの前にAXを整える理由

危険物や燃料を扱う現場では、導入前にアナログ業務を標準化するAXが必要です。現場の担当者が持つ経験を、チェック項目と例外処理に置き換えておきます。

• 作業基準：散水のタイミングや異物の目視確認を定めます。
• 定時連絡：船・港湾・倉庫・運送・発電所間の連絡を整理します。
• 確認と記録：誰がいつ何を確認し、異常時に誰へ連絡し、記録をどこに残すかを決めます。

ルールが決まっていないままでは、IoTセンサーを増やしても、異常を判定する基準が揃いません。そのため、確認手順を先に決めてから、入力画面や通知を設計します。

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

発注は、企画から運用定着までを工程ごとに区切って進めます。

仕様が不明な設備やレガシーシステムは、調査を終えてから本開発の範囲を決めます。

1. 企画を立てる。
2. 現状を調査する。
3. 要件を定義する。
4. 設計・開発を行う。
5. テストを行う。
6. 移行する。
7. 運用を定着させる。

すべてを一括請負にせず、最初の調査と要件定義だけを別契約にする方法もあります。

調査結果を見てから、本開発の金額と範囲を確定します。

要件定義で合意する項目

要件定義では、機能に加えて、稼働や障害対応、監査に関する非機能要件も合意しておきます。

IPAの資料でも、運用時間や業務継続性を具体的な指標として整理しています（出典：独立行政法人情報処理推進機構「データ連携の仕組みに関するガイドラインの手引き 付録1」）。

• 性能と稼働：処理量・応答時間・稼働時間・バックアップを決めます。
• 障害時の対応：計画停止・サービス切替時間・許容停止時間・切り戻し判断者・代替運用時間を定めます。
• 管理と監査：ログ保存期間、権限、監査証跡を合意します。

許容停止時間などは、見積もりに使えるよう数値で決めておきます。「止めない」という表現のままでは、見積もりの根拠になりません。

24時間稼働のプラントを止めずに移行する方法

移行では、現行と新システムを一定期間並行して稼働させ、データ連携と業務結果を比べます。

準備は実データで訓練します。

• 復旧準備：フルバックアップ・差分同期・復旧手順・連絡網・判断基準を確認します。
• 影響範囲：制御系は業務系の更新と分けて扱い、設備への影響を限定します。
• 切り替え範囲：影響の小さい拠点や業務から先に切り替え、検証した手順を他へ広げます。

テストと定着で現場が確認する項目

確認事項は、テスト、現場操作、稼働後の運用の三つに分けて整理します。

• テスト：通常操作に加え、通信断、センサー異常、重複データ、権限外操作を確認します。夜間の引き継ぎや、災害時の代替運用も対象です。
• 現場操作：実際の点検や出荷の順番で操作し、入力項目の量や異常時の判断を確かめます。
• 稼働後の運用：問い合わせ窓口・障害の優先度・月次の改善会議・マスタ更新の責任者を決めます。

導入の完了は、現場が安全に使い続けられる状態と定義し、リリース日とは分けて考えます。

費用相場と契約形態の考え方

開発費用には一律の正解がなく、拠点数や設備接続、データ移行によって変わります。

24時間運用や監査・セキュリティ、保全やEMSのアルゴリズムでも変わります。

市場の平均価格だけで判断しないよう、工程別の工数を軸に見積もりを取ります。そのうえで、ライセンスやクラウド、移行の費用を分けて示してもらいます。教育や保守、予備費も含めて、費用項目ごとに確認します。

規模別の予算の仮置き

予算は規模別に仮置きすることがあります。ここに示す金額は、発注価格ではなく、調査段階で社内稟議に幅を持たせるための目安です。

• 企画・現状調査：調査だけなら、数百万円規模です。
• PoC・小規模アプリ：単一業務のPoCや現場アプリは、数百万円から1,000万円前後です。
• 部門システム：複数システムの連携を含めると、1,000万円から5,000万円程度です。
• 複数拠点の刷新：ERP・EAM・データ基盤を刷新する場合は、5,000万円から数億円以上です。

再見積もりでは、画面数に加えて、連携本数や設備点数を基準にします。移行件数や運用時間も、あわせて見ます。

見積りの内訳とランニングコスト

初期費用と運用費用は、分けて比べます。また、IPAは実績データや開発規模、工数を使うCoBRA法の見積り評価モデルを紹介しています（出典：独立行政法人情報処理推進機構「CoBRA法に基づく見積り支援ツール」）。

• 初期費用：企画・要件定義、設計、開発・設定、連携の工程です。テスト、移行、教育、プロジェクト管理までが対象です。
• 運用費用：クラウド、監視、ライセンス、保守が対象です。セキュリティ対応、障害対応、バックアップ、追加改修も含みます。

実績データと変動要因を分けて考える方法も有効です。初期費用が安くても、24時間監視やデータ保持、拠点追加が別料金になる場合があります。そのため、3年から5年のTCOで比べます。

委託先の選定と見積比較で確認すべきポイント

委託先は、知名度や単価だけでなく、同様の制約がある現場で要件を決め、事故なく移行し、運用を支えた経験で評価します。

石油・エネルギー業界での直接の経験がなくても、製造、物流、医療など、安全性・可用性・トレーサビリティが厳しい業界の実績は参考になります。

提案会社の実績と体制の確認

類似業務の経験に加えて、移行から稼働後までの体制を確かめます。

実績は、社名や件数だけで判断せず、中身を聞きます。

• 業務経験：類似業務・担当予定者、要件定義を担う人材、設備・IoT連携とデータ移行の経験を確認します。
• 支援体制：障害連絡、再委託先、保守拠点を見ます。
• 実績の範囲：対象範囲・期間、停止時間・移行方法、稼働後の支援内容を聞きます。
• 担当継続：提案責任者の関与と、担当交代時の引き継ぎ方法を確認します。

見積書を同じ条件で比べる方法

各社には、同じRFPと前提条件、成果物一覧を渡します。見積もりを工程別、役割別、拠点別に揃えると、比べやすくなります。

• 安い提案：要件定義、移行、教育、受入支援の有無を確かめます。監視や障害対応、セキュリティ診断は含まれているかを見ます。
• 高い提案：過剰なカスタマイズや不要なライセンス、曖昧な予備費がないかを確かめます。

差額の理由を質問し、機能、体制、リスクの差に分けて説明できる会社を選びます。

契約前に決める責任分界

責任分界では、発注者と受託者の担当を明確にします。なかでも、データと仕様変更の扱いは揃えておく必要があります。

• 発注者：業務目的、優先順位、マスタの正しさを担います。受入基準、現場代表者の配置、意思決定も受け持ちます。
• 受託者：合意仕様に基づく設計・開発、品質管理、進捗報告、障害対応を担います。

移行データの正しさを誰も確かめないままだと、不具合や仕様変更の責任を巡って争いになりがちです。そこで、契約書と別紙で、要件凍結の時期、変更手順、検収条件を揃えておきます。

知的財産と再委託の扱い、損害賠償や保守の範囲も、契約前に定めておきます。

よくある質問

石油・エネルギー業界のシステム発注について、相談の多い質問に答えます。RFP作成やベンダー面談の前に確認してください。

石油・エネルギー業界のシステム開発費用はいくらですか？

小規模なPoCは数百万円から、部門システムは1,000万円から5,000万円程度が目安です。複数拠点の基幹刷新は、5,000万円から数億円以上になることがあります。

見積もりには、連携やデータ移行、設備接続に加えて、停止対策や保守も含めます。

判断材料になるのは、初期費用だけでなく、3年から5年のTCOと障害時の事業影響です。

クラウドとオンプレミスはどちらを選ぶべきですか？

クラウドとオンプレミスは、どちらが正解というより、要件に合わせて選ぶものです。

• 比較軸：機密性、通信遅延、設備接続を比べます。災害対策、拠点展開、運用人材、TCOも比べます。
• 配置の目安：全社のデータ分析やバックアップはクラウド、制御系や通信制約のある設備側はオンプレミスやエッジも候補です。
• 組み合わせ：クラウドとオンプレミスを組み合わせるハイブリッド構成も選べます。
• 共通の保護策：認証、暗号化、監視、脆弱性対応、復旧訓練を要件にします。

ただし、クラウドかオンプレミスかだけで安全性が決まるわけではありません。

RFPを作れない場合でも外注できますか？

外注はできますが、最初から本開発を発注するのではなく、現状調査と要件定義を準委任型で依頼する方法が安全です。その成果物をもとに、複数社から本開発の提案を受けます。

調査では、現場ヒアリングや業務フロー、データ一覧を整理し、非機能要求と移行方針もまとめます。

RFP作成支援の範囲と成果物、期間、次工程へ進む条件を、契約に記載します。

まとめ

発注前に、無停止運用や安全管理、GXの制約を整理しておきます。そのうえで、AXを通じて、現場ルールとマスタの責任を整えます。

要件定義と調査、本開発を分けたうえで、移行と保守も区切ります。請負型と準委任型は、その区切りに応じて使い分けます。

見積もりは初期費用だけでなく、移行・教育・監視、保守・障害対応を含むTCOで比べます。

発注前に確認するポイント

発注前に確認する項目を、RFPと見積書の両方に反映させます。揃えておくと、価格には表れないリスクも比べられます。

• 業務条件：対象業務と優先順位、停止許容時間を確認します。
• データ：設備・危険物マスタの責任者を決めます。
• 移行と契約：切り戻し手順と責任分界を確認します。
• 費用：3年から5年分のTCOを確かめます。

最初に依頼する際の進め方

石油・エネルギー業界の発注では、現場調査の成果を、提案の比較まで一貫して使います。

1. 現行業務とデータを一覧にし、現場ヒアリングと非機能要求を整理します。
2. 調査の成果をもとに、複数社へ同じRFPと前提条件を示して提案を依頼します。
3. 実績・体制・価格・移行計画を比べます。

手順どおりに進めると、提案の差を同じ物差しで比べられます。

現場や既存システムによって、最適な構成は変わります。そのため、各社への相談では、責任分界まで含めて話を詰めます。

参考にした公的情報は、資源エネルギー庁「エネルギー白書2025」、IPA「ソフトウェア開発分析データ集」、IPA「データ連携の仕組みに関するガイドラインの手引き 付録1」、IPA「CoBRA法に基づく見積り支援ツール」です。

▼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を創業。