OpenShiftのシステム開発の発注/外注/依頼/委託方法について

OpenShiftのシステム開発を発注・外注するなら、OpenShift基盤の構築と業務アプリの開発・移行・運用を分けて整理し、要件と責任範囲をRFPへ落とし込むことが成功の近道です。

OpenShiftはKubernetesを中心に、コンテナの実行、認証、ネットワーク、ストレージ、CI/CD、監視、セキュリティまでをまとめて扱うエンタープライズ向けのアプリケーション基盤です。そのため、単にクラスタを構築するだけの発注と、既存業務システムをOpenShift上へ移行・刷新する発注では、必要な会社、契約、費用、納品物が大きく異なります。この記事では、発注形態の選び方、RFPと要件整理、契約形態、費用相場、委託先の比較方法までを、2026年時点の情報を踏まえて解説します。

▼全体ガイドの記事
・OpenShiftのシステム開発の完全ガイド

OpenShiftのシステムを発注・外注するときの全体像

OpenShiftのシステム開発を外注する際は、製品の導入、基盤の設計・構築、業務アプリの開発、既存データの移行、稼働後の運用を一つの案件として捉えつつ、見積もりと責任分界は分けて確認します。発注者が最初に決めるべきことは、何を外部へ任せ、何を社内で持つかです。

基盤側には、Control Plane、Worker Node、コンテナレジストリ、ネットワーク、永続ストレージ、認証、監視、バックアップ、アップグレード設計が含まれます。一方、業務アプリ側には、画面やAPI、バッチ、データベース連携、既存システムとのインターフェース、データ移行、利用部門の受入テストが含まれます。基盤に強い会社へアプリの業務要件まで任せるのか、業務アプリに強い会社と基盤専門会社を組み合わせるのかで、RFPの書き方とプロジェクト管理は変わります。

外注範囲は、企画・要件定義、OpenShift基盤、業務アプリと移行、運用保守の四つの層に分けると整理しやすくなります。企画・要件定義を社内で行う場合も、非機能要件や現行環境の調査だけを専門会社へ依頼できます。逆に、24時間365日の監視、障害時の一次切り分け、脆弱性対応、バージョンアップまで依頼するなら、開発会社ではなく運用体制を持つSI会社やマネージドサービス事業者との契約が必要です。担当範囲を「一式」と書かず、層ごとの成果物と窓口を示すことが重要です。

OpenShiftのシステムはどの発注形態が適していますか？

OpenShiftのシステムで推奨しやすい発注形態は、企画・要件定義を発注者とパートナーで共同し、基盤構築とアプリ開発を工程ごとに契約し、運用保守を別契約または継続契約にする形です。最初からすべてを一社へ丸投げする方法もありますが、比較可能な単位がなくなり、費用や責任分界が見えにくくなります。自社の技術者数、現行資産、納期、運用負荷を基準に選びます。

社内にクラウド、Kubernetes、ネットワーク、業務アプリの担当者がほとんどいない場合は、要件整理から構築、移行、運用引き継ぎまでを一社へ委託する方法が向きます。窓口を一本化でき、障害時の責任追及が複雑になりにくい点が利点です。ただし、一括委託では、設計書、Kubernetesマニフェスト、CI/CD定義、監視設定、テスト仕様書、運用手順書、ソースコードの納品範囲を契約書へ明記し、特定会社への依存が過度にならないようにします。

既存の業務アプリを熟知した会社がある場合は、アプリの改修・データ移行をその会社へ依頼し、OpenShiftの設計・構築・運用を基盤専門会社へ依頼する分担が有効です。技術選択の自由度と比較の透明性が高まる一方、両社の責任分界が曖昧だと、通信設定、認証、ログ、障害切り分けの隙間が生じます。発注者が統合PMOを担うか、どちらか一社を全体統括に指定し、インターフェース一覧と課題管理ルールを共通化します。

ROSA、Azure Red Hat OpenShift、OpenShift Dedicatedなどのマネージドサービスを選ぶ場合は、Control Planeの管理負担を抑えやすくなりますが、クラウド事業者の料金、OpenShiftサービス料金、ネットワーク、ストレージ、監視、バックアップを合算して判断します。マネージドであっても、アプリの脆弱性修正、コンテナイメージ、データベース、業務要件への対応は利用者または委託先の責任として残ります。責任分界表を見積依頼書に添付し、誰が何を監視し、何時間以内に連絡し、どの条件で復旧するかを確認します。

RFPと要件整理には何を書けばよいですか？

RFPは「OpenShiftで構築してください」という製品指定だけで終わらせず、業務上の目的と評価可能な条件を示します。候補会社が同じ前提で提案できるように、現行環境、対象業務、利用者数、データ量、希望時期、予算区分、セキュリティ要件、運用体制、納品物、提案書の形式をそろえて渡します。要件が未確定な部分は未確定と書き、調査・PoCで決める項目として見積に含めるかを指定します。

業務要件では、対象部門、利用者の役割、主要な業務フロー、画面・API・バッチの一覧、外部システムとの連携、データの登録・更新・参照権限を整理します。既存アプリをコンテナ化する場合は、ソースコードの有無、対応言語とミドルウェア、OS依存、ローカルファイル、セッション管理、固定IP、夜間バッチ、データベースの種類と容量を確認します。現行資料が不足している場合は、RFPに「現状調査を第一工程とする」と書き、調査後に本開発の範囲を確定する二段階発注にします。

OpenShift案件の品質と費用を左右するのは、CPUやメモリよりも非機能要件です。可用性、目標復旧時間RTO、目標復旧時点RPO、ピーク時の同時接続数、レスポンスタイム、ログ保持期間、バックアップ世代数、障害通知の時間、リリース頻度、メンテナンス可能時間を数値で示します。たとえば「止まらない」ではなく、「平日日中の業務を月間何分まで停止可能か」「障害発生から何時間以内に暫定復旧するか」と書くと、候補会社の設計と見積を比較できます。

認証方式、MFA、RBAC、NetworkPolicy、秘密情報の保管先、イメージの脆弱性検査、監査ログ、暗号化、バックアップ、復旧訓練、脆弱性パッチの期限をRFPへ含めます。個人データを扱う場合、個人情報保護委員会のガイドラインは、委託先の安全管理措置を事前に確認し、契約へ必要な内容を盛り込み、取扱状況を把握することを示しています。再委託の事前報告や承認、監査の方法も最初から決めます。出典は、個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認です。

公共分野や規制業種では、OpenShiftの製品名だけで適合性を判断しません。利用するクラウドサービス、リージョン、データの保管場所、委託先の管理策をサービス単位で確認します。デジタル庁は2026年3月にもISMAPクラウドサービスリスト等を更新しているため、調達時点のリストと対象サービスを確認し、ISMAPに載っていることと自社システム全体が適合することを混同しないようにします。出典は、デジタル庁「ISMAPクラウドサービスリスト等を更新しました」、2026年です。

契約形態とOpenShiftのシステム費用相場をどう考えますか？

OpenShiftの費用は、ライセンスまたはサービス料金だけでなく、クラスタ、クラウド、ネットワーク、ストレージ、アプリ改修、データ移行、テスト、教育、監視、保守を合算して判断します。契約は、成果物と完成条件を明確にできる工程は請負、要件変更が多い調査・アジャイル開発・運用支援は準委任、または両者を組み合わせる方法が現実的です。名称ではなく、何に対して対価を払い、誰が完成責任を負うかを確認します。

請負契約は、要件、成果物、受入条件、納期、検収方法を合意できるクラスタ構築や定型的な移行作業に向きます。仕様変更の手続き、追加費用の算定、遅延時の扱い、第三者製品の不具合時の責任も定義します。準委任契約は、現状調査、要件定義、技術検証、アジャイルな機能開発、継続運用に向きますが、作業時間を投入したことと業務成果が出ることは同じではありません。成果の評価方法、月次報告、稼働上限、交代要員、途中解約の条件を明確にします。

OpenShift固有の初期費用に公式の一律相場はありません。リサーチノートに基づく案件別の概算では、学習・PoCや軽微なコンテナ化は300万〜800万円、本番基盤と業務アプリ1〜3本を含む中小規模案件は1,000万〜3,000万円、既存基幹のモダナイズ、多クラスタ、多拠点移行は3,000万〜1億円超が目安です。これは公式定価ではなく、クラスタ設計、セキュリティ、CI/CD、アプリ改修、移行、テスト、運用設計を含めた作業範囲から組み立てた概算です。出典は、NotebookLMリサーチノート「OpenShiftのシステム」、2026年です。

クラウドのサービス料金は別に試算します。AWS公式ではROSAのサービス料金として、Worker Nodeの4vCPUあたり1時間0.171米ドル、Hosted Control Planeのクラスタ料金1時間0.25米ドルが案内されています。たとえば730時間を月間稼働時間として、3つの4vCPU相当Workerを置いた場合、ROSAサービス料だけで0.171×730×3＋0.25×730となり、約557米ドルです。1ドル150円を仮置きすると約8.4万円ですが、EC2、EBS、ロードバランサー、通信、監視、バックアップなどのAWS料金は別です。出典は、Amazon Web Services「Red Hat OpenShift Service on AWS Pricing」、2026年確認です。

Red Hatの価格ページでも、クラウドサービスごとに料金体系が異なり、セルフマネージド製品は契約条件や構成による個別見積となります。したがって、見積書ではRed Hat契約、クラウド利用料、構築・開発費、移行費、運用保守費を別行にし、為替や利用量の変動リスクを示してもらいます。年間保守・運用は、業務システム全般の目安として初期開発費の15〜20％程度に、クラウドとサブスクリプションを加える考え方がありますが、24時間運用やSLAを含むかで変わるため、固定比率だけで予算化しません。

2025年11月に一般提供されたOpenShift 4.20では、AIワークロード、仮想化、外部OIDC、External Secrets Operator、ユーザーネームスペース、BGPなどが強化されています。OpenShift VirtualizationによってVMとコンテナを同じ基盤で管理する構想も取りやすくなっていますが、新機能を採用するほど設計、検証、運用教育の範囲は広がります。発注時は「4.20を使う」とだけ決めず、採用する機能、サポート対象バージョン、アップグレード方針、検証環境、後から追加する機能を提案書に記載してもらいます。出典は、Red Hat「Red Hat OpenShift 4.20: Accelerating Virtualization and AI Innovation」、2025年11月です。

委託先の選定と見積比較では何を確認しますか？

委託先は、OpenShiftの認定資格や製品名の取り扱いだけでなく、本番稼働後まで責任を持てるかで比較します。候補は、製品・サブスクリプションを提供する会社、ハイブリッドクラウドに強い会社、基盤を構築するSI会社、業務アプリを開発する会社、運用を専門にする会社に分けて確認します。最初から会社名だけで絞り込まず、必要な役割を定義してから、実績と体制を照合します。

実績を聞くときは、「OpenShiftの案件がありますか」だけで終わらせません。利用したバージョン、オンプレミスかクラウドか、ノード数と可用性、対象アプリの種類、データ移行の有無、稼働後の運用範囲、障害対応の時間帯を確認します。可能であれば、匿名化した構成図、移行計画、運用設計書のサンプルを見せてもらい、提案担当者と実装・運用担当者が同じ前提を話しているかを確認します。

見積比較では、総額の安さよりも、作業の抜けと前提条件を確認します。現状調査、要件定義、基本設計、クラスタ構築、ネットワーク・認証、CI/CD、アプリ改修、データ移行、テスト、教育、リリース、監視、バックアップ、運用引き継ぎを同じWBSで並べ、各工程の人日、単価、期間、担当会社を比較します。Red Hat契約費とクラウド費を含むのか、税や為替をどう扱うのか、追加要件の単価はいくらかも確認します。

特に注意するのは、安い見積に非機能要件の検証や移行リハーサルが含まれていないケースです。提案書に「監視込み」とあっても、メトリクスだけなのか、ログ・トレース・アラート・夜間通知・障害一次対応まで含むのかは会社ごとに違います。比較表には、含む、含まない、別途見積、発注者準備の四つの区分を設けると、後から追加費用になりやすい項目を発見できます。

受入条件は、画面が動くことだけでは不十分です。負荷試験の同時接続数、フェイルオーバー、バックアップからの復旧、脆弱性検査、ログの保存、権限の分離、リリースの切り戻し、データ移行後の件数・金額突合を合格条件として設定します。発注者側のマスタデータ提供、業務部門の受入テスト、ネットワーク申請、クラウド契約、Red Hat契約の取得など、発注者が担う作業も納期と依存関係に含めます。

また、仕様凍結後の追加要望、Red Hatやクラウド側の仕様変更、既存アプリの想定外の制約、第三者製品の障害、データ品質の問題をリスク台帳へ記載します。PoCで確認する項目には、成功条件、失敗時の代替案、本番契約へ進む判断者を置きます。小さく検証してから本開発へ進むと、全社展開後に構成をやり直すリスクを抑えられます。

OpenShiftのシステム発注に関するよくある質問

OpenShiftの発注では、製品の選択、業務アプリの移行、費用、契約、運用の責任分界について疑問が生じます。ここでは、相談前に特に確認しておきたい質問へ直接回答します。

最初に、OpenShiftを使う目的、対象業務、現行アプリ、データ分類、希望時期、運用体制を一枚に整理します。製品導入を目的にせず、リリース速度、可用性、ハイブリッド環境、VM移行、セキュリティ統制など、解決したい経営・業務課題を明確にしてから現状調査または小規模PoCを発注します。

まず、PoC、開発環境、本番環境、運用の目的を分け、不要な高可用性や多クラスタ構成を初期導入へ入れないことです。既存アプリをすべてマイクロサービス化するのではなく、境界が明確な機能から段階的に移行し、マネージドサービス、標準Operator、既存CI/CDを活用します。ただし、監視、バックアップ、セキュリティ、復旧試験を削ると稼働後の損失が増えるため、削減対象は機能と工程の優先順位で判断します。

要件と比較条件をそろえたうえで、まず2〜3社へ依頼すると、提案品質と比較作業のバランスを取りやすくなります。基盤、アプリ、運用を分けて発注する場合は、全体統括を担う会社を含めて候補を選び、同じWBS、同じ非機能要件、同じ納品物の条件で見積を取得します。価格だけでなく、実装担当者の経験、障害対応、移行リハーサル、契約後の追加費用条件を確認して決定します。

構成図、要件定義書、基本・詳細設計書、ネットワークと権限設計、Kubernetesマニフェスト、Operatorと設定値、CI/CD定義、テスト計画・結果、移行手順、バックアップ・復旧手順、監視設定、運用手順書、教育資料、ソースコードを基本候補にします。すべてが必要とは限りませんが、将来の保守会社変更や障害調査に必要な成果物を契約書へ列挙し、著作権、利用許諾、リポジトリの管理者、秘密情報の削除方法まで合意します。

まとめ

発注前には、基盤とアプリの範囲、非機能要件、契約方式、費用の内訳、納品物、運用の責任分界を確認します。候補会社から同じ条件の提案を受け、安さではなく、将来の保守と変更に必要な情報が残るかを評価します。

現行アプリやデータの制約が分からない場合は、いきなり本番開発を一括発注せず、現状調査または小規模PoCで不確実性を減らします。成功条件と次工程の判断基準を決めておけば、OpenShiftを採用しない場合も含めて、納得できる投資判断ができます。

OpenShiftのシステムを発注・外注するときは、OpenShift基盤、業務アプリ、データ移行、運用保守を分解し、自社と委託先の責任範囲を最初に決めます。発注形態は、一社への一括委託、基盤会社とアプリ会社の分担、マネージドサービスの活用から、自社の人材と運用体制に合うものを選びます。

RFPには業務要件だけでなく、可用性、RTO・RPO、性能、認証、ログ、バックアップ、移行、監視、アップグレード、再委託、納品物を含めます。費用は、PoC・軽微なコンテナ化で300万〜800万円、本番基盤と業務アプリを含む中小規模で1,000万〜3,000万円、既存基幹のモダナイズや多拠点移行で3,000万〜1億円超という案件別レンジを出発点にし、公式のサービス料金、クラウド費、開発費、運用費を分けて比較します。

候補会社は2〜3社程度に同じ前提で提案を依頼し、総額ではなくWBS、担当者、実績、非機能試験、移行リハーサル、障害対応、納品物、追加費用条件を確認します。OpenShift 4.20などの最新機能を採用する場合も、技術トレンドだけで決めず、サポート期間、運用人材、セキュリティ、3〜5年のTCOを含めて発注判断を行うことが大切です。

▼全体ガイドの記事
・OpenShiftのシステム開発の完全ガイド

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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