OpenShiftのシステム開発の完全ガイド

OpenShiftのシステム開発は、実行基盤の整備、業務アプリの設計と移行、継続運用の標準化を組み合わせて進めます。こうした組み合わせにより、複数の環境を安全に運用するのに役立ちます。

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

OpenShiftのシステムの全体像

基盤と業務アプリを分けて捉える構成です。

OpenShiftは、コンテナ化した業務アプリの実行基盤と、開発・運用の標準プロセスを組み合わせたシステムです。認証やネットワークのほか、監視やバックアップ、リリース管理までを含めて設計します。

業務アプリと実行基盤の役割分担

OpenShiftの導入は、業務システムを完成させるための一部の作業にすぎません。そのため、発注側と開発会社は、基盤と業務アプリの役割を分けて設計する必要があります。

実行基盤：アプリの配置・稼働・増減、障害復旧、安全な更新の環境
業務アプリ：販売管理、顧客管理、予約、製造、分析などの業務ロジック
アプリ開発：画面、API、データベース、既存システムとの連携
運用管理：Webコンソール・oc CLI、Project・Namespace、RBAC、ResourceQuota、NetworkPolicy、SCC

基盤は、API・スケジューラーを担うControl Planeと、Podを動かすWorker Nodeからなります。構成には、レジストリや永続ストレージ、外部認証などのほか、Gitリポジトリ、CI/CDも含まれます。

KubernetesやDockerとの違いと統合機能

Kubernetesは、コンテナのデプロイ、スケール、自己修復などを自動化するオーケストレーターです。一方、Dockerはコンテナイメージの作成や実行に使われる代表的な技術で、両者は役割が異なります。

OpenShiftは、Kubernetesを土台に、検証済みの組み合わせで機能を提供します。

統合機能：認証・権限、レジストリ、ルーティング、Operator、開発者向け画面、パイプライン、監視、セキュリティ設定
導入負担：OSSを自社で自由に組むより選定・統合負担を抑えやすい一方、サブスクリプション費用と製品ルールがある

比べるときは、自由度だけでなく、アップグレード、脆弱性対応、障害時の切り分け、担当者育成も含めた3〜5年の総保有コストで見ます（出典: OpenShift公式機能情報、2026年）。

OpenShiftの種類と導入方式の選び方

導入方式は、マネージドサービスとセルフマネージドに大別できます。前者は一部の運用を任せやすく、後者は配置場所やネットワーク、更新計画を細かく設計できます。

方式は、業務データの所在地、可用性、既存インフラ、運用人材、予算といった条件を材料に選びます。

運用負担を抑えたい場合のマネージドOpenShift

マネージドOpenShiftでは、制御系や基盤アップデートの一部をサービス側が担います。そのため、専門の管理者が少ない組織でも、アプリやパイプラインに集中しやすい方式です。

クラウド料金：サービス料のほか、Worker用VM、ストレージ、ロードバランサー、通信、監視、バックアップ
障害対応：ノード調査をサービス側と利用側のどちらが担うか
更新と復旧：証明書・外部認証の更新担当、アップグレードの選択権と通知期間、リージョン障害時の復旧範囲

どこまでをサービス側が担い、どこから先を利用側が担うかは、見積もりと契約の前に確かめておきます。

制御性と運用力を重視する場合のセルフマネージド

セルフマネージドでは、まず配置先を選び、基盤を自社の標準に合わせて設計します。

配置先：オンプレミス、仮想化基盤、ベアメタル、パブリッククラウド
設計項目：ネットワーク、ストレージ、証明書、監視、バックアップ、更新
適する条件：データ保管場所の制約、既存設備や運用監視の活用
必要な体制：クラスタ管理、RHCOS等の更新、Operator互換性、脆弱性対応、障害訓練

平日の担当者だけでは本番を支えにくいときは、運用支援を組み合わせるか、マネージド方式も比べてみます。

4.20の認証・秘密情報・AI・仮想化

OpenShift 4.20系は2025年11月に公開されました（出典: OpenShift 4.20公式リリースノート、2026年）。

認証・秘密情報：外部OIDC認証、External Secrets Operator、ゼロトラスト型ワークロードID
対象領域：AIワークロード、仮想化関連機能

2026年に新規導入するなら、採用するバージョンのサポート期間、Operatorの対応状況、アップグレード検証環境を先に決めておきます。最新機能の有効化は、運用計画の一部として扱います。

既存のVMをすぐには全面改修できない企業では、OpenShift VirtualizationでVMとコンテナを同じ運用モデルに寄せる選択肢があります。ただし、VMを移すことと、アプリのクラウドネイティブ化は別の話で、依存関係、バックアップ、性能、ライセンス、切り戻し条件を個別に評価します。

ポイント

専門の管理者が少ないならマネージド、配置先や更新計画を細かく決めたいならセルフマネージドを候補にします。どちらでも、担当範囲は契約前に整理しておく必要があります。

OpenShiftのシステム開発の進め方

PoCで移行リスクを確かめてから実装へ進みます。

基盤を先に作ると、認証、データ移行、監視、性能要件が後から分かり、手戻りになりやすいです。そのため、業務部門とIT部門は共通の計画で進めます。

現状を調査して要件を定義する
PoCで技術リスクを確かめる
基盤とアプリを設計・実装する
テスト後に段階移行し、運用を引き継ぐ

現状調査と要件定義での非機能要件

基盤の設計に必要な情報は、現状調査と要件定義でそろえます。

現状調査：アプリ構成、利用者数、ピーク同時接続、データ量、外部連携、バッチ時間、障害履歴、リリース頻度
要件定義：可用性、性能、RTO・RPO、ログ保持期間、監査証跡、データ所在地、認証方式、運用時間を数値化

要件は、たとえば「1系統の障害時も業務を継続し、目標復旧時間は4時間以内」のように書きます。こう書けば、クラスタ構成やバックアップ方式を決めやすくなります。

業務部門には、ピークの業務日、締め処理、許容停止時間、マスタの責任者を確認してもらいます。マスタや既存データの品質が低い場合は、重複、欠損、コード体系を早めに整備しておきます。

要件定義を軽く済ませると、クラスタの完成後にアプリ改修や追加ストレージが発生し、初期見積もりから費用が膨らむ原因になります。

PoCによる技術リスクの確認と設計・実装

要件が確定したら、代表的なアプリを1本選び、PoCでコンテナ化の難所を確かめます。PoCの目的は、成功例を作ることではなく、移行できない機能と追加改修を洗い出すことです。

設定とログ：環境変数への分離と標準出力への出力
状態と接続：セッションやファイルの外部化、DB接続の再試行
拡張性：水平スケールへの対応

本設計では、開発・ステージング・本番を分け、Namespaceの命名とイメージの保管先を決めます。そのうえで、RouteやIngress、永続ボリューム、Secretの外部管理、RBAC、NetworkPolicyを設計します。

また、バックアップ、監視・アラート、障害時の連絡ルートを定義します。アプリは細かく分けすぎず、外部API、認証、バッチ、監査ログのように境界が明確な機能から切り出します。

CI/CD・テスト・段階移行・運用引き継ぎのつながり

実装では、Gitへの変更を起点に、本番へ反映する流れを作ります。

自動化：単体テスト、脆弱性検査、イメージ署名、承認、デプロイ
設定管理：GitOpsで環境別設定を管理し、変更履歴を追跡

リリース前には、性能や障害時の動きを試験するほか、権限、バックアップ復元、ローリング更新、切り戻しも確かめます。結果は、設計書と結び付けます。

既存システムは、いきなり全社で切り替えるのではなく、影響範囲の小さい業務や参照系から移行します。移行にあたっては、データ突合、移行リハーサル、業務部門の受入テスト、切り戻し条件、旧環境の停止時期を文書にまとめます。

運用開始後は、クラスタ、アプリ、DB、ネットワーク、外部サービスのどこに原因があるかを切り分けられるよう、メトリクス・ログ・トレースの確認手順を共通化します。

ポイント

基盤を先に作らず、要件定義とPoCで非機能要件や移行リスクを固めてから設計・実装に進みます。認証やデータ移行、性能要件が設計の前に決まっているかが、判断の目安です。

OpenShiftのシステム開発の費用相場

対象範囲が広がるほど、費用レンジも大きくなります。

OpenShiftの費用は、製品・サービス、クラウドまたは設備、クラスタ構築、アプリ改修、データ移行、運用保守に分けて考えます。

価格は、ノード数、可用性、利用時間、契約期間、アプリ数、既存資産の状態によって変わり、一律ではありません。

ここで示す金額は、2026年時点の公開料金と一般的な業務システム開発の工程をもとにした概算です。

▶ 詳細はこちら：OpenShiftのシステム開発の見積相場や費用/コスト/値段について

初期費用の幅：300万円から1億円超まで

初期費用は対象の範囲によって幅があり、期間も規模によって変わります。

学習・PoC等：軽微なアプリ1〜2本のコンテナ化は300万〜800万円程度
中小規模の本番：認証、ネットワーク、監視、バックアップ、アプリ1〜3本、データ連携で1,000万〜3,000万円程度
基幹移行等：多クラスタ、複数拠点、段階移行、DR、24時間運用で3,000万〜1億円超の場合がある
期間：PoCは1〜3か月、本番小規模は3〜6か月、基幹の段階移行は6〜18か月

これらの金額は公式の定価ではなく、要件定義、設計、構築、アプリ改修の工程を含む概算です。さらに、テスト、移行、教育、運用引き継ぎも含みます。新規の業務アプリをスクラッチ開発する場合は、画面、API、DB、業務テストの費用が別途加わります。

クラウドの月額：サービス料金とインフラ料金の分け方

ROSAの公開料金をもとに、サービス料金の例を試算します（出典: ROSA公式料金ページ、2026年）。

Worker Node：4 vCPUあたり0.171米ドル/時
Hosted Control Plane：クラスタ料金は0.25米ドル/時
Worker 3台：730時間/月・1ドル=150円で約8.4万円/月
計算式：0.171×3×730×150＋0.25×730×150
Worker 6台：サービス料金は約14.0万円/月

これらは総額ではありません。Worker、インフラ用・制御系ノード、EBSなどのストレージ、ロードバランサー、監視、バックアップ、データ転送、サポート契約も、費用に加わります。

マルチAZの本番最低構成は、3 Worker、3インフラノード、3制御系ノードです。そのため、小規模な検証構成と本番の高可用性構成は、同じ月額で比べないようにします。

年間保守費と運用範囲

一般的な業務システムの年間保守・運用費は、初期開発費の15〜20%程度が目安です。OpenShiftでは、クラスタ運用を含むか、アプリ保守だけかで金額が変わります。

保守範囲：24時間365日の監視、障害一次対応、脆弱性パッチ、証明書更新、復元訓練、更新検証、アプリ改修
実費：製品契約、クラウド、ストレージ、ログ保管、バックアップ
料金条件：初期費用と月額費用、従量費と固定費を分け、ログ保持を90日から1年へ延ばす影響を確認
構成条件：バックアップの別リージョン複製、3環境の常時稼働

条件ごとに費用がどう変わるかは、見積書で確かめます。

ポイント

初期費用は対象範囲の広さで300万円から1億円超まで変わります。月額や年間保守は、サービス料金、実費、保守範囲に分けて比べると差が見えます。

OpenShiftが向く企業と向かないケース

OpenShiftは、複数のアプリやチームを継続して運用するための標準化の手段です。変更頻度、環境の多様性、監査要件、運用人材、既存資産を点検し、費用に見合う効果があるかを判断します。

複数チーム・ハイブリッド環境・継続リリースの企業

次のような企業では、OpenShiftの適性を検討できます。

複数チーム：開発・検証・本番を使い分ける
ハイブリッド環境：オンプレミスとクラウドで運用する
継続リリース：毎月または毎週、安全に更新する

ProjectやNamespaceで利用単位を分けて、RBACとポリシーを共通化できます。さらに、CI/CDと監視も標準化すると、チームごとの手作業や環境差が減らしやすくなります。

個人情報や金融、医療などの機微データを扱い、アクセス制御、監査ログ、脆弱性管理、バックアップ、災害対策を説明する必要がある場合も、検討する価値があります。

法令や業界基準への適合には、OpenShiftの機能に加えて、組織の規程、契約、運用記録と一体で管理することが必要です。

単機能・低頻度変更・専任運用者不在の場合の慎重な判断

単機能アプリを一つだけ固定された小規模環境で動かし、ほとんど変更しない場合、通常のマネージドコンテナやサーバーレスのほうが簡単で安いことがあります。

運用負担：クラスタ、ネットワーク、監視、セキュリティ、アップグレードを学ぶ
費用：製品費に加え、教育費と運用の固定費が発生する

既存アプリがローカルファイル、固定ホスト名、常時接続セッション、特定ミドルウェアの管理者権限に依存している場合は、コンテナ化の前に改修範囲を見積もっておきます。

現行維持、部分的なモダナイズ、全面再構築を比べて、業務価値とリスクのバランスを取ります。

OpenShiftのセキュリティと法規制で確認すべき点

セキュリティは、クラスタの設定だけでなく、サプライチェーン全体で設計します。対象には、アプリの脆弱性、イメージの出所、認証情報が含まれます。ネットワーク、DB、委託先、運用手順も見落とせません。

法令や認証制度を導入の理由にする前に、誰がどこでデータを扱い、何を証跡として残すのかを明らかにしておきます。

最小権限・秘密情報・イメージ・監査ログの管理

技術面では、RBACを最小権限で設計し、外部OIDCや多要素認証と連携させます。開発者には本番の管理者権限を配らず、緊急時だけ承認を経て一時的に付与する運用も有効です。

通信と権限：Namespace間のNetworkPolicy、SCC、TLS
情報保護：暗号鍵、Secretsの外部保管、バックアップ暗号化
検査と記録：イメージ検査・署名、監査ログ保護、復元テスト

Compliance Operatorは、業界標準やベンチマークに対する技術的な検査と改善を補助しますが、監査人の代わりにはなりません。

適合や認証を目指す場合は、まず対象範囲を定め、構成、契約、運用記録をそろえます。必要に応じて認定監査機関の評価を受けます（出典: OpenShift Container Platform 4.19 Security and compliance、2026年）。

個人情報保護法とISMAPの確認単位

個人データを扱う場合は、取扱状況と管理責任を次の観点で整理しておきます。

データ：データフロー、利用目的、保存期間、削除方法
関係者：アクセス担当者、委託先・再委託先
事故対応：漏えい時の連絡と報告

個人情報保護委員会のガイドラインは、委託先の安全管理措置の確認、必要な契約、取扱状況の把握を示しています。

委託先管理や安全管理措置は、OpenShiftの認証設定とは別に、組織として整える必要があります（出典: 個人情報保護委員会「ガイドライン（通則編）」、2026年）。

行政・公共案件のISMAP確認では、基盤製品の名前ではなく、利用クラウド、リージョン、契約形態、データ処理範囲が登録対象と一致するかを確かめます。

デジタル庁は2026年3月にもISMAPクラウドサービスリスト等を更新しています。そのため、調達の時点で最新のリストと対象範囲を確かめます（出典: デジタル庁「ISMAPクラウドサービスリスト等を更新しました」、2026年）。

ポイント

まず、誰がどこでデータを扱い、何を証跡として残すかを決めます。そのうえで、利用サービスが対象範囲と一致するかを、サービスごとに判断する必要があります。

OpenShiftの開発会社・ベンダーの選び方

発注先は、製品サポート、クラウド基盤、クラスタ構築、業務アプリ開発、データ移行、運用監視のどこまでを任せるかで、選び方が変わります。

製品に詳しくても既存業務を移せない場合があります。一方で、アプリ開発に強くても、クラスタ更新や障害対応が不足することがあります。

基盤・アプリ・移行・運用ごとの実績

「OpenShiftの実績があります」という説明に加えて、実務経験を項目ごとに確かめます。

本番経験：クラスタ規模、利用方式、アプリ種類、移行データ量、停止時間、運用体制
移行設計：Java、.NET、COBOL、VMのコンテナ化、状態を持つ処理やバッチの設計
対応体制：資格者数だけでなく、本番担当者の経験や基盤・アプリの障害切り分けを確認

提案書に、RTO・RPOと24時間運用の条件が含まれているかを確かめます。加えて、脆弱性パッチ、バージョンアップ、バックアップ復元、監視通知のSLAの扱いも確かめます。

再委託がある場合は、範囲、データへのアクセス、責任者、障害時の連絡経路を、契約前に明らかにしておきます。

比較しやすい見積項目と納品物の形

複数社の提案を比べるときは、作業と費用を分けて見ます。

作業項目：要件定義から移行までの工程（設計、構築、アプリ改修、テストを含む）
引き継ぎ：教育、運用引き継ぎ、納品物の範囲
費用区分：製品・クラウド、構築、開発、月額運用

総額だけを見ると、監視やバックアップが抜けていないかを見分けにくくなります。

納品物として確認したいのは、設計書、構成図、ネットワーク・権限一覧です。加えて、マニフェスト、CI/CD定義、テスト仕様書・結果も確認したい項目です。

バックアップ・復元手順、障害対応手順、教育資料も対象です。さらに、ソースコード、リポジトリ、ライセンス情報も含まれます。

内製化や委託先の変更を考える場合は、マニフェストや自動化コードの所有者と、引き渡しの形式を契約に明記します。

▶ 詳細はこちら：OpenShiftのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：OpenShiftのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

▶ 詳細はこちら：OpenShiftのシステム開発の発注/外注/依頼/委託方法について

ポイント

発注先は、基盤とアプリ、移行、運用のそれぞれで実績があるかで比べます。見積もりは作業と費用、納品物を同じ形にそろえると、抜けに気づきやすくなります。

OpenShiftのシステム開発でよくある質問

導入前によく出る疑問に答えます。費用や移行の可否は環境によって変わるため、判断の軸を先に押さえておくと役立ちます。

OpenShiftはKubernetesが分かれば運用できますか？

Kubernetesの知識は役立ちます。ただし、OpenShift固有の認証、SCC、Route、Operator、アップグレード、サポートポリシーも理解する必要があります。

クラウドやオンプレミスで、どこまでが自社の責任かも把握しておきます。そのうえで、小規模な検証環境でoc CLI、ログ、権限、デプロイ、復元を経験してから、本番設計へ進みます。

既存のモノリシックアプリもOpenShiftへ移行できますか？

移行できる可能性はありますが、事前にアプリの状態管理と外部依存を調べておく必要があります。主な確認点は、ローカルファイル、固定IP、セッションです。加えて、バッチ、共有ストレージ、DB接続、ライセンス制約も確認点になります。

まずアプリ全体を移して動作を安定させ、その後に変更頻度の高い機能やAPIから分離する段階移行が現実的です。

OpenShiftを使うとシステム開発費は安くなりますか？

初期のサブスクリプションや基盤構築費は増える一方で、環境の標準化やリリースの自動化によって、長期の費用を下げられる可能性があります。

障害対応の再利用や、複数チームでのセルフサービスも、変更や運用のコストを下げる要因になります。一方で、単機能アプリでは別の方式が有利な場合もあります。

初期費用だけでなく、3〜5年のTCOとリリース回数で比べます。

OpenShiftのシステム開発は何から始めればよいですか？

まずは、現行アプリとデータ、利用者数、ピーク、停止許容時間を整理し、RTO・RPO、リリース頻度、データ所在地、運用体制も書き出します。

次に、代表アプリのPoCで、コンテナ化の難所と概算を確かめます。そのうえで、マネージド、セルフマネージド、OpenShift以外の方式を同じ条件で比べます。

PoCと比較の結果を材料に、基盤と業務アプリの両方を評価できる発注先へ相談します。

まとめ

OpenShiftは、Kubernetesを土台にしてコンテナを実行する基盤です。加えて、認証、権限、ネットワーク、ストレージも標準化の対象になります。さらに、CI/CD、監視、セキュリティ、運用自動化も含まれます。

2026年時点では、マネージド、セルフマネージド、VMとの共存、AIワークロードなどの選択肢があります。採用は、機能の新しさではなく、自社の条件に合うかで決めることが大切です。

採用判断の軸：変更頻度・運用体制・3〜5年TCO

採用の可否は、複数チームで継続リリースする必要があるか、オンプレミスとクラウドを併用するか、監査・セキュリティ要件があるか、クラスタを維持できる人材がいるかで判断します。

費用は、製品・クラウド、構築、アプリ改修、移行、保守に分けたうえで、初期費用と変更回数、停止損失、アップグレード、障害対応まで含むTCOを比べます。

最初の一歩：現状整理と小さなPoC

全社の基幹システムを一度に移すのではなく、代表的なアプリとデータを選び、非機能要件、コンテナ化の難所、運用手順、費用を検証します。

PoCの結果をもとに、移行範囲、導入方式、必要なスキル、発注先、3〜5年の予算を具体化します。そのうえで、自社にとって価値のある選択肢かを判断します。

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