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

LXCのシステム開発は、要件と運用責任の整理から始めます。そのうえで方式と委託範囲を決め、PoCを経て構築・移行へ進みます。この順番を守ると、追加費用や責任の行き違いを抑えやすくなります。

発注形態、RFPと要件整理、契約と費用、委託先の選び方の順に、決めることと注意点を見ていきます。

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

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

LXCのシステム開発を発注する前に知るべき全体像

LXCは、Linuxのプロセスやネットワーク、ファイルシステムを隔離し、コンテナごとに比較的完全なLinuxユーザー空間を動かす技術です。Dockerのように単一アプリを配布する仕組みとは、目的が異なります。

Web、API、DB、監視などをLinux環境単位で分けたい場合に検討されます。また、管理層のLXD・Incus、仮想化基盤のProxmox VE、VMやDocker/OCIとの組み合わせも比較します。

LXC・LXD・Incus・Proxmoxの役割の分け方

各層の役割を分けて発注すると、必要な管理機能や運用体制を明確にできます。

• LXC：コンテナを動かす低レベルのランタイムです。単体ではクラスタ管理やバックアップを解決しません。
• LXD・Incus：イメージ、API、ネットワーク、ストレージ、権限、クラスタなどを管理する層です。
• Proxmox VE：LXCとKVMを同じ基盤で扱え、Web管理画面やHA、ライブマイグレーション、バックアップを組み合わせやすい選択肢です。

役割を混同したまま発注すると、構築後に運用画面や復旧手順がないという行き違いが起きることがあります。

採用可否の判断軸は業務要件

方式を選ぶときは、性能面の利点に加えて、必要な分離やアプリの運用方法とも照らし合わせます。

• LXC：ホストのカーネルを共有する方式です。VMより起動が速く、メモリやディスクの負担を抑えやすい特徴があります。
• VM：異なるカーネルやWindows、強いテナント分離、特殊なカーネルモジュールが必要な業務に向く場合があります。
• Docker/OCI・Kubernetes：短い周期でのアプリ配布や自動スケール、CI/CDを重視する場合の候補です。

発注書には、LXCを使う理由を記します。停止許容時間やRTO/RPO、データ保護、既存ソフトのサポート条件に合う方式かどうかも、委託先に説明してもらいます。

LXCの発注形態の選び方

発注形態は、社内にLinux人材がいるか、既存環境がどうか、どこまで内製したいかで決めます。障害時の責任を誰が負うかも、判断材料になります。そのうえで、費用だけでなく、設計判断や運用ノウハウが社内に残るかも比べます。

企画から運用まで一括外注する形態

社内でLinuxやネットワーク、業務アプリを担当する人が少ない場合は、一社への一括委託が選択肢です。

依頼の範囲は、現状調査から運用引き継ぎまでの全体です。要件定義と基盤構築、アプリ移行に加えて、監視やバックアップも一社が担います。

窓口が一本化され、障害時に切り分けやすい一方で、設計品質は委託先に左右されます。そのため、納品物には構成図や設定値、IaCを含めます。手順書やアカウント一覧、ログ保管場所も残しておき、保守会社の変更に備えます。

基盤とアプリを分けて部分委託する形態

社内にアプリ開発者がいる場合は、インフラ会社にLXCの設計・構築・監視を任せられます。また、業務アプリの改修やデータ移行を別会社が担当する分離型も選べます。

専門性を生かしやすい反面、担当が分かれるぶん、責任分界を細かく決めておく必要があります。ネットワークやOSの層から、アプリやDBの層まで、境目を一つずつ確かめます。障害の一次受付と必要なログはRFPと契約書に書き、夜間の連絡先や切替作業の指揮者も同じ書類に記載します。

PoCから始めて伴走支援を発注する形態

本番採用の判断材料が足りない場合は、大規模な構築の前に、1台のホストと少数のコンテナでPoCを依頼します。PoCでは、既存アプリの動作とDB性能、バックアップからの復元、ホスト障害時の復旧範囲を確かめます。

PoCの成功条件と本番発注へ移る条件は、検証の前に決めておきます。そうすると、検証だけが長期化する事態を防ぎやすくなります。

RFPと要件整理の項目

RFPは、LXCの知識を試す資料というより、委託先が同じ前提で提案と見積を作るための資料です。そのため、業務の目的と現状を記し、技術方式は候補として比較してもらいます。

最初からLXC単体に固定すると、VMやLXD/Incus、Proxmoxを含めた安全な代替案が出にくくなります。

業務要件と非機能要件の分け方

RFPでは、業務の規模と運用上の制約を分けて書きます。

• 業務要件：利用部門、ユーザー数、同時接続数、画面・API処理、バッチ時刻、外部連携、データ量、将来の増加見込み。
• 稼働条件：稼働時間、停止可能時間、目標復旧時間であるRTO、許容できるデータ損失の目標であるRPO。
• 運用・保護要件：バックアップ保持期間、監査ログ、暗号化、アクセス権限、脆弱性対応、問い合わせ時間。
• 個人データ：安全管理措置、委託先の監督、漏えい時の連絡・報告分担。

個人データを扱う場合は、個人情報保護委員会のガイドラインを踏まえて要件を定めます。

インフラとセキュリティの前提

委託先が設計を具体的に組めるよう、基盤の構成やコンテナの制限は、曖昧な表現を避けて書きます。

• 基盤：ホスト台数、CPU・メモリ・ディスク、ストレージ、固定IP、VLAN、ファイアウォール、DNS、TLS証明書、監視先、バックアップ先。
• コンテナ設定：CPU・メモリ上限、プロセス数、公開ポート、デバイスアクセス、root権限、特権コンテナの扱い。
• 権限管理：非特権コンテナを原則とし、例外には理由、代替策、承認者、見直し時期を残します。

LXC 6.0 LTSのサポート期限は、公式に2029年6月までと案内されています。

採用するバージョンやOS、管理層のサポート期限も、あわせてRFPに書いておきます（出典: Linux Containers公式「LXC 6.0 LTS has been released」、2024年）。

納品物と受入れ条件

RFPでは、成果物と、受入れ時に確認する動作を分けて指定します。

• 納品物：構成図、基本設計書、詳細設定、コンテナ一覧、イメージの出所・ハッシュ、ネットワーク・権限一覧。
• 運用資料：監視・バックアップ設計、復元・障害対応手順、運用引き継ぎ資料、IaCやスクリプト、テスト結果。
• 受入れ確認：コンテナ再起動、ホスト再起動、ディスク逼迫、ネットワーク断、バックアップ復元、管理者権限の棚卸し、脆弱性修正の手順。

成果物の形式や引き渡し時期が曖昧なままだと、構築後に追加費用が発生しやすくなります。

LXCの外注で選ぶ契約形態と進め方

LXC案件では、要件が固まった部分とPoCで検証する部分が混在します。そこで、調査・要件定義から保守まで段階を分けておくと、追加費用と責任の境界を管理しやすくなります。

請負契約が向く範囲と受入れ条件

請負契約は、完成と検収の条件を明確にできる作業に向きます。たとえば、構築や設計書、テスト、移行が該当します。

そのうえで、RFPの要件と作業範囲、前提条件を契約の土台にし、納期と検収期間も定めます。瑕疵や不具合の扱い、再実施の範囲も、契約書や個別仕様書で決めます。発注者側のサーバー提供やアカウント発行、データ確認が遅れた場合の納期扱いも明記します。

準委任契約が向く調査・設計・保守の専門作業

準委任契約は、専門家の知見や作業時間を提供してもらう形態です。現行環境の調査や方式比較、PoCなどの検証が適します。技術支援や運用改善も、この契約の対象になります。

準委任契約は成果物の完成を約束するものではなく、作業を提供する契約です。そのため、稼働時間と担当者を決め、定例会と報告内容も取り決めます。作業記録と秘密情報の扱い、再委託の可否も確かめます。

PoCで方式を検証したあとに、構築部分だけを請負契約へ切り替える組み合わせも現実的です。

保守契約の障害対応と更新責任

保守では、OSやLXCの更新、イメージの脆弱性対応、監視アラートへの対応を、作業ごとに分けて記載します。さらに、バックアップ確認と障害の一次切り分け、復旧作業、月次報告も、担当を分けて記載します。

対応時間は、平日日中だけか夜間・休日も含むかを決めます。目標応答時間や復旧目標、連絡方法も、あわせて取り決めます。

追加作業の単価と、予備機やクラウド費用の負担者も決めておきます。特に、業務アプリやDBの障害をどこまで扱うかは、保守費用と安心感を左右します。

LXCのシステム開発費用相場と内訳

LXC単体の国内受託開発価格を横断した公的な統計は確認できません。そのため、業務システム一般の相場に、LXC基盤の設計・構築・移行に加えてテストや運用設計を組み合わせた概算レンジを示します。

金額は、ハードウェアやクラウドの利用、ライセンスの有無で変わります。さらに、アプリ改修やデータ移行、24時間保守の有無も、金額を左右します。この数字はRFPの予算検討用として使い、確定値とは扱わないでください。

規模別の初期費用の目安

費用は、ホスト数や移行範囲によって、次のような概算になります。

• PoC・開発環境：1ホスト・1〜5コンテナ、簡易ネットワークと手順書までで50万〜150万円程度。
• 小規模本番：1〜2ホスト・5〜15コンテナ。Web・API・DB分離、監視、バックアップ、TLS、移行、引き継ぎ込みで150万〜500万円程度。
• 中規模本番：3ノード以上のHA、共有ストレージ、冗長ネットワーク、復旧訓練、性能試験込みで500万〜1,500万円程度。
• 移行・改修込み：現行調査、アプリ改修、データ移行、連携テスト、段階稼働、旧環境との並行運用を含むと1,000万〜3,000万円以上の場合があります。

これらは、要件定義から保守体制までを含めた推定です。LXCのライセンス料だけを指すものではありません。

根拠は、業務システム一般の相場とLXC固有の作業です。LXC専門市場の公表統計による数字ではありません。

費用の内訳：基盤・移行・運用

費用は基盤、移行、運用の三つに分けて見積もると、会社同士を比べやすくなります。

• 基盤：サーバーやVPS、ストレージ、ネットワーク、OS、LXC、管理層、監視、バックアップ
• 移行：現行調査、アプリ改修、DB移行、データ整備、連携テスト、切替リハーサル
• 運用：更新、脆弱性対応、監視、問い合わせ、障害対応、復元テスト、定期報告

内訳のない一式見積では、会社同士を比べられません。さらに、後から作業が増えたときの判断も難しくなります。

Proxmox VEの公式料金ページによると、2026年8月時点でCommunityは物理CPUソケットあたり年120ユーロです。Basicは年370ユーロ、Standardは年550ユーロ、Premiumは年1,100ユーロと示されています（出典: Proxmox VE公式料金ページ、2026年確認）。

対象はすべての物理CPUソケットで、クラスタの各ノードに契約が必要です。ここに示すのは製品サブスクリプションの価格で、設計や構築、移行の委託費、ハードウェア費用は別途必要です。また、為替や税、販売代理店の支援費用も含めて見積もります。

3年TCOでの判断

初期費用だけで判断しないよう、3年間にかかる費用を合算します。

• 利用・設備：サーバー・クラウド利用料、電源・回線、バックアップ保管、予備機、将来の増設。
• 運用・復旧：監視、保守、脆弱性対応、障害復旧。

業務システム一般では、保守費を初期費用の年15〜20％程度とする考え方があります。ただし、24時間365日対応やDB保守を加えると、この目安より上振れします。遠隔拠点や復旧訓練も、上振れの要因になります。

この比率は、リサーチノートに記載した一般的な目安で、LXC固有の統計ではありません。

見積書では、通常保守と追加作業を分けて示してもらいます。

LXCの委託先選定と見積比較のポイント

委託先は、LXCを知っているだけでなく、業務システムとして設計し、障害時に説明できる会社を選びます。あわせて、LXC・LXD・Incus・Proxmoxのどこまで対応できるかも確認します。

Linuxカーネルやネットワーク、ストレージを自社で診断できるか、アプリとDBの責任を持てるかも判断材料になります。

実績の確認方法：担当範囲

候補会社には、どの技術を担当したかを分けて質問します。たとえば、LXC単体とLXDまたはIncus、Proxmox VEを区別して答えてもらいます。KVMやDocker/OCIについても分けて確認します。

非特権コンテナやcgroups、AppArmorやSELinuxの経験の有無を聞きます。ネットワーク分離や共有ストレージ、監視、バックアップ復元の経験も、あわせて確認します。さらに、既存VMや物理サーバーからの移行実績も確かめます。

実績を開示できない会社には、匿名化した構成図や、テスト計画、障害時の切り分け例を出してもらいます。こうした資料は、提案の具体性を比べる材料になります。

見積の比較項目：作業範囲・前提・除外

合計金額の順位だけでなく、次の条件を同じ粒度で比べます。

• 工程：要件定義、方式設計、PoC、構築、改修、移行、テスト、切替、文書、教育、保守を分けます。
• 工数・条件：各工程の人月・作業時間、期間、担当者、前提条件、除外項目。
• 費用範囲：サーバー、ストレージ、回線、バックアップ、商用サポート、クラウド利用料の扱い。
• 金額の差：差が出た理由を、作業範囲と前提の違いから読み解きます。
• 比較社数：同じRFPで3社程度から同じ粒度の見積を取り、差を質問で埋めます。

極端に安い見積では、非機能要件や移行リハーサル、復元テストが抜けている場合があります。さらに、監視設定や運用手順、脆弱性対応も抜けやすい項目です。

見積が高くても、必要な予備機や24時間対応が含まれているなら、単純な割高とは言えません。

契約前の障害・更新・引き継ぎの確認

契約前に、障害対応や更新、引き継ぎの責任を、次の質問で確かめます。

• 更新・脆弱性：LXCや管理層の更新を誰が判断・実施し、脆弱性公開時の初動と費用をどう定めますか。
• 復旧：ホスト障害時の手順を試験しますか。バックアップから何時間以内にどこまで戻しますか。
• 引き継ぎ・委託：設定とIaCの引き渡し形式、再委託先、データ保管場所を開示できますか。
• 障害対応：一次受付、調査に必要なログ、夜間の連絡先、切替作業の指揮者を決めていますか。

回答が担当者の経験談で終わらず、設計書や試験項目に反映されるかを見ます。SLAや報告書への反映も、あわせて確認します。

CanonicalのLXDは、システムコンテナとVMを管理するプラットフォームとして案内されています。スナップショットやリソース制限、クラスタの管理も含まれます。Proxmox VEでは、LXCとKVM、バックアップ、HAなどを統合できます。

公式に機能があることと、委託先が自社環境で設計・運用できることは、別の話です。会社が選ぶ設定と想定する障害も、機能一覧とあわせて確認します（出典: Canonical LXD公式、Proxmox VE公式、2026年確認）。

よくある質問（FAQ）

LXCの発注では、技術の選び方のほかに、本番利用や費用、外注範囲についての質問が多く寄せられます。契約後の責任についても、よく問われます。発注前に判断しやすいよう、次の質問に答えます。

LXCは本番の業務システムに使えますか？

要件と運用設計が合えば、本番の業務システムにも利用できます。そのうえで、ホストのカーネル共有や特権設定、障害分離を検証します。さらに、バックアップ復元や更新手順、監視、RTO/RPOも確かめます。

VMや別のコンテナ方式と比べて、採用理由を説明できるようにしておきます。異なるカーネルや強い分離が必要な場合は、VMか、LXCとVMの組み合わせを選びます。

LXCは無料なので開発費も安くなりますか？

LXCのソフトウェア費用を抑えられても、開発費が自動的に安くなるわけではありません。要件定義やネットワーク、ストレージ、セキュリティの設計には、専門作業が必要です。移行や監視、復旧試験、保守体制も、専門的な作業を伴います。

ライセンス費用や委託費、インフラ費、3年TCOに分けて見積もり、「無料」という言葉だけで判断しないことが大切です。

LXCの外注先には何を伝えれば見積を出せますか？

業務目的と現行構成、利用者数、データ量を伝えます。さらに、連携や希望時期、停止許容時間、RTO/RPO、セキュリティ要件も書き添えます。加えて、予算の考え方と、社内で担当できる範囲も伝えます。

構築のほかに、移行や監視、バックアップも見積に含めるかを明示します。復元訓練や保守、納品物も、対象かどうかを示します。情報が不足する場合は、有償の現行調査やPoCを発注し、その成果を本番見積に反映してもらいます。

LXCとDockerはどちらを外注すべきですか？

複数のサービスを含むLinux環境をOS単位で扱う場合はLXC系、アプリをイメージ化して頻繁に配布する場合はDocker/OCI系が候補になります。

基盤にLXCやVM、アプリ配布にDockerを使う組み合わせもあります。その場合、委託先には両方式の比較理由と、将来の移行や運用の違いを提案書に書いてもらいます。

まとめ

LXCの発注では、まず業務要件と非機能要件を整理します。そのうえで、LXC単体やLXD/Incus、Proxmox VE、VM、Docker/OCIの役割を比べ、社内体制に合う発注形態を選びます。

一括外注、部分委託、PoCから始める伴走支援のうち、責任範囲に合う方法を選びます。

発注前に確認する条件

発注前には、RFPの条件と要件別の概算を次のとおり揃えておきます。

• RFP：利用規模、現行環境、RTO/RPO、セキュリティ、移行、監視、バックアップ、復元試験、納品物、保守範囲。
• PoC・小規模本番：前者は50万〜150万円程度、後者は150万〜500万円程度。
• 中規模HA：500万〜1,500万円程度。移行・アプリ改修込みでは1,000万〜3,000万円以上の場合があります。
• 見積条件：金額はLXC固有の公表統計ではなく要件別の概算です。各社から工程別・前提条件付きの見積を取ります。

委託先と合意する運用責任

委託先は、安さだけで決めず、障害時の責任分界や更新と脆弱性対応で選びます。さらに、バックアップからの復旧や設定、IaCの引き渡し、3年TCOも判断材料にします。

不安があるなら、現行調査とPoCを先に依頼します。そのうえで、実測した性能と運用課題を本番発注へつなげる進め方が安全です。

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

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