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

containerdのシステム発注は、要件整理、PoC、設計・構築、移行・運用の順に進めると、本番基盤と運用を段階的に整えられます。

段階ごとに決めることは、発注形態、RFP、契約、費用、委託先の選び方に分かれます。全体像は完全ガイドにまとめています。

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

containerdのシステム発注の範囲

周辺機能を合わせて見ると、発注範囲の抜けを見つけやすくなります。

containerdのシステム発注とは、ランタイムだけでなく、業務アプリを動かす基盤の設計・構築・移行・運用まで委託することです。

containerdは、イメージの取得や展開、コンテナの作成・起動・停止、スナップショット管理を担います。ただし、複数ノードへの配置や自己修復、サービス公開、継続的デリバリーは単体では提供しません。

containerd、Docker、Kubernetesの役割の分担

発注時は、Docker、containerd、Kubernetesの担当範囲を分けて整理します。役割が混ざると、障害時の責任分界で行き違いが起きます。

Docker：開発者がイメージを作り、コンテナを扱うためのツール群です。
containerd：Docker Engineでも使われる実行基盤です。
Kubernetes：複数ノードへの配置、状態維持、更新やスケールを担うオーケストレーターです。

containerdは、低レイヤーのプロセス起動を通常runcなどのOCIランタイムに委ねます。なお、RFPにはクラウドまたはサーバー、Kubernetes構成、載せるアプリとデータまで記載します。

運用可能なサービスとしての発注対象

委託範囲は、本番運用に必要な要素まで含めて決めます。ランタイムだけを切り出すと、本番で動かすための部分が発注から抜けてしまいます。

実行と配布：レジストリ、CI/CD、脆弱性スキャンまでを含みます。
接続と保存：CNIによるネットワーク、CSIまたはクラウドストレージ。
運用と保護：ログ・メトリクス、秘密情報管理、バックアップ、障害時の切り分け。

Kubernetesでは、kubeletからCRIプラグインを通じてcontainerdへ要求が届きます。containerdは実行をruncへ委ね、Kubernetes 1.26以降はCRI v1だけが利用されます。このため、バージョン互換性は設計段階で確認します（出典：Kubernetes公式「Container Runtimes」、2026年確認）。

発注形態の選び方

社内体制とプロジェクトの確度を並べて検討できます。

発注形態は、社内のクラウド・Kubernetes人材、既存アプリの改修量、自社で担う運用範囲から決めます。また、小規模な検証を短期間で始めるのか、基幹システムを本番移行するのかによっても、適した方法は変わります。

マネージドKubernetesを使う発注

EKS、GKE、AKSなどのマネージドKubernetesを使う場合は、次のように発注範囲を分けて整理します。

委ねる範囲：コントロールプレーンの一部をクラウド事業者へ委ねられます。
向く条件：専任の基盤運用チームがない場合や、アプリのコンテナ化を優先する場合です。
別途設計する範囲：ノード、IAMやRBAC、ネットワーク、ロードバランサー、ストレージです。

監視とバックアップも、発注時に設計へ含める必要があります。「すべてお任せ」と考えていると、障害時の責任分界で行き違いが生じます。

OSS自社構築またはオンプレミスでの発注

オンプレミスやエッジ環境では、拠点や設備の制約から、基盤を自社側に置くことがあります。

構築対象：containerdとKubernetesを自社サーバーに構築します。
適する条件：データ保管場所、既存ネットワーク、低遅延、工場や拠点の制約を重視する場合です。
運用範囲：証明書とetcd、ノード障害、ストレージ、カーネルやランタイムの更新、脆弱性対応までを含みます。

本番運用を始めるには、設定ファイルのほかに、運用の手順も必要です。そこで、IaCと復旧手順を成果物に指定し、監視ルールや訓練も含めます。

PoCから本番までの段階的な発注

不確定要素が多い場合は、いきなり本番基盤を固定せず、PoC、設計・構築、移行・運用の3段階に分けて発注します。

PoC：イメージのビルドと取得、起動時間、ログと監視を確かめ、ローリング更新、永続ボリューム、障害復旧も見ます。
設計・構築：基盤を設計し、構築する段階です。
移行・運用：構築後の移行と、その後の運用を行う段階です。

PoCの合格条件を先に決めると、継続発注か構成見直しかを判断できます。一社へまとめる場合も、中間成果物と検収条件を置けば、予算と品質を管理できます。

ポイント

形態に迷うときは、本番移行か小規模な検証かを先に分けます。そのうえで、社内の人材と運用範囲に照らし、どこまで自社で担うかを決めます。

RFPと要件整理で決める項目

区分ごとに前提を置くと、候補企業間の見積条件をそろえやすくなります。

RFPは、候補企業へ同じ条件で提案と見積を依頼する資料です。containerdのバージョン名だけでは比べられないため、業務目的や対象アプリなども一つの文書にまとめます。

RFPには、バージョン、業務目的、対象アプリ、利用者・環境数、可用性を記します。さらに、セキュリティ、運用体制、納品物、予算、期限も書き込みます。要件が曖昧なまま価格だけを比べると、安く見える提案にも追加費用が生じる場合があります。

業務要件と非機能要件の書き分け

業務要件と非機能要件を分けて書くと、候補各社が同じ条件で見積もれます。

業務要件：対象業務、画面やAPI、バッチ、外部連携を書きます。利用者、データの種類、リリース頻度も含めます。
非機能要件：ピーク時のリクエスト数、応答時間、稼働時間、停止許容時間、RTO、RPO。
保護と保管：バックアップ保持期間、監査ログ、個人情報の保管場所。

可用性は「高可用性」と書くだけでなく、単一ノード障害時にも業務を続けられるか、復旧目標が何分かまで示します。そうすると、各社の見積の前提がそろいます。

技術スコープと責任分界の決め方

技術要件と担当範囲は、構成要素ごとにそろえて書きます。

基盤：クラウドまたはオンプレミス、Kubernetesの種類、containerdとruncのバージョン。
接続・実行：CRI、snapshotter、レジストリ、CNI、CSI、Ingress。
運用：CI/CD、ログ・監視、秘密情報管理。

Docker移行では、Composeとビルドの互換性を確かめます。加えて、認証やログ、タグ、ボリューム、ホストマウントも対象になります。そのうえで、一次対応者を構成要素ごとに表にまとめ、障害時の責任争いを防ぎます。

納品物と検収条件の決め方

納品物と合格条件を具体的に決めておくと、完成後の認識違いを防げます。

設計・構築：基本・詳細設計書、構成図、TerraformなどのIaC、config.toml、Kubernetesマニフェスト。
運用：CI/CD定義、監視ダッシュボード、アラート一覧、バックアップ設計、障害対応Runbook。
引き継ぎ：テスト結果、操作手順、教育資料、ソースコードと設定。

検収では、イメージ取得から起動までの時間、負荷試験、ノード障害を確かめます。あわせて、ロールバックとバックアップからの復元を条件に含めます。権限分離と脆弱性対応も、検収で見る対象です。

ソースコードや設定をベンダーの環境だけに置かないよう、自社リポジトリへの納品を条件に入れます。

ポイント

候補各社の見積を比べられるかは、RFPの前提がそろっているかで決まります。業務要件と非機能要件を分け、担当範囲も明記しておくと、前提をそろえやすくなります。

契約形態（請負と準委任）の使い分け

基本は、仕様を固定できるフェーズに請負を、要件を詰めながら専門知識を借りるフェーズに準委任を使うことです。

すべてを請負にすると、PoCや要件定義での変更が追加費用になりやすくなります。一方で、すべて準委任にすると、成果や責任範囲が曖昧になりがちです。そのため、フェーズごとに契約を分け、それぞれの特徴を活かします。

請負契約が向く範囲

請負契約は成果物の完成を目的とするため、次のような作業に向いています。

完成物：合意した設計書、構築物、テスト結果。
対象作業：環境構築、標準構成のIaC化、CI/CD、監視設定、移行リハーサル。

いずれも、成果物と検収条件を決められる作業です。契約書では、仕様変更、受入テスト、不具合修正の範囲を確かめます。

さらに、第三者サービスの障害とOSSライセンスを確かめます。知的財産権と再委託の条件も、見ておきます。

準委任契約が向く範囲

準委任契約は、専門家が善管注意義務をもって業務を遂行する契約です。一般に、時間や体制に対して対価を支払います。

要件定義や既存環境の調査は、準委任に適しています。移行方式の検討や設計レビューも、準委任に向いた作業です。

支援する業務：運用設計や内製化支援など、進めながら判断が変わる業務。
契約に記す事項：担当者の役割、会議体、成果報告、作業記録、知識移転。
体制の条件：月ごとの上限と増員・減員のルール。

保守運用契約で確認する項目

本番稼働後は、開発契約とは別に保守運用契約を結ぶことが多くなります。

対応体制：対象時間、窓口、一次切り分け、重大障害の連絡時間、オンコール。
定期作業：アップデート、脆弱性対応、ログ保管、バックアップ確認。
報告：月次レポートと対応状況を定義します。

保守の対象には、containerd、runc、Kubernetesの更新も含みます。公式ガイドも、カーネルや各ソフトの更新、ソケット権限、レジストリTLSを基本要件としています。プラグインの信頼性も対象です（出典：containerd Operator Security Guidelines、2026年確認）。

ポイント

成果物と検収条件を決められる作業は請負に、要件を詰めながら進める作業は準委任に分けます。フェーズの区切りごとに見直すと、契約の食い違いを防ぎやすくなります。

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

containerd単体の受託開発には、統一された公開価格がありません。ここに示す金額は、一般的な業務システムの費用情報と、基盤の設計・構築・移行・運用を組み合わせた編集上の推定レンジです。

金額は、ノード数や環境数、クラウド利用量によって変わります。アプリ改修やデータ移行、可用性や24時間監視の有無でも変動します。そのため、予算計画の目安として使います。

規模別の初期費用と期間の目安

規模と作業範囲によって、初期費用と期間の目安は異なります。

学習・PoCまたは開発環境1つ：100万〜300万円程度、2〜6週間。
小規模な本番基盤：1クラスタ、数ノードで500万〜1,500万円程度、2〜4か月。
既存システムのコンテナ化・移行：1,500万〜5,000万円程度、6〜12か月。
大規模案件：5,000万〜2億円以上、12〜24か月。

PoC環境には、containerd、レジストリ、簡易CI、基本監視、サンプルアプリを含みます。

小規模な本番では、要件定義とネットワーク、Kubernetesを含みます。加えて、CI/CDやログ、監視、バックアップも対象です。

運用手順も対象に入ります。既存システムの移行費には、アプリ改修や複数環境も含みます。さらに、データと設定の移行、性能試験、段階リリース、教育も加わります。

大規模案件は、高可用性や複数クラスタ、災害対策に加えて、監査や24時間監視を含む場合の推定です。各金額は確定した価格ではなく、要件の不確実性を含む概算です。

クラウド費用と保守費用の見積もり方

EKS標準は1クラスタ・1時間あたり0.10米ドル、延長は0.60米ドルです（出典：AWS「Amazon EKS Pricing」、2026年確認）。EC2やEBS、IPアドレスは別料金です。ロードバランサーや転送量、ログ、バックアップも、別に課金されます。

GKE管理料は1クラスタ・1時間あたり0.10米ドルです（出典：Google Cloud「Google Kubernetes Engine pricing」、2026年確認）。

見積範囲：クラウド実費と保守費用を開発費と分けます。
EKS：標準と延長のサポート料金を区別します。
GKE：無料枠の条件と別料金を確認します。
AKS：Freeは検証向け、Standard・PremiumはSLAや信頼性重視の本番向けです。
保守・改修：年15〜20％が目安。脆弱性・夜間・更新・監視範囲で増減します。

月74.40米ドルのGKE無料クレジットは、ゾーンまたはAutopilotクラスタに適用されます。ただし、GKEのコンピュートやストレージは別料金です（出典：Google Cloud「Google Kubernetes Engine pricing」、2026年確認）。

ノードはAzure仮想マシンとして別途課金されます（出典：Microsoft Learn「AKS Free, Standard, and Premium Pricing Tiers」、2026年確認）。「無料」という表示があっても、本番費用は見積の全体で判断します。

ポイント

金額はノード数や環境数で変わるため、見積の範囲を決めてから予算の目安に使います。クラウド実費と保守費は、開発費と分けて見積もります。

委託先の選定と見積比較

委託先は、containerdの知識だけでなく、基盤を設計・移行・運用できるかで選びます。ただし、公開実績がKubernetesやOpenShift中心で、containerd単体の事例でない場合もあります。

そのため、runtimeのバージョン、CRI構成、障害対応経験、IaCとRunbookの納品範囲を確認します。実績を過大評価しないことが大切です。

候補会社へ必ず聞く質問

候補会社には、技術構成や障害対応、セキュリティ、引き継ぎについて質問します。

互換性：Kubernetesとcontainerdの対応バージョンをどう固定しますか。
構成：CRI、runc、snapshotter、CNI、CSIに何を採用しますか。
運用範囲：EKS・GKE・AKSのどこまでを担当し、障害の一次切り分けは何分以内ですか。
セキュリティ：イメージ署名、SBOM、脆弱性スキャンをどこで行いますか。
引き継ぎ：設定やcontainerd.sockの権限、障害検知、更新テスト、IaCとRunbookの納品をどう扱いますか。

ノード障害とストレージ枯渇を、どう検知するかも確かめておくと、各社の運用力の差が見えてきます。

見積書の粒度をそろえた比較

見積は、含まれる作業と含まれない作業をそろえて比べます。総額は、その後で見ます。

作業範囲：要件定義、PoC、設計、構築、アプリ改修、データ移行。
導入後作業：試験、教育、リリース、保守、クラウド実費。
見積前提：単価と工数、期間、担当ロールを示します。ノード数、環境数、データ量も記します。

一社が監視を含み、別の会社が構築後の設定だけを含む場合、総額を比べても意味がありません。さらに、追加費用が発生する条件も並べて確かめます。

評価軸としてのセキュリティとTCO

containerdのnamespaceは管理上の論理分離であり、強いテナント分離の境界ではありません。

セキュリティ：機密データの分離とアクセス制御を確認します。
SBOM管理：部品表の納品・更新をRFPに含めます。
TCO：初期費用だけでなく、5年程度の費用で比べます。
運用人件費：OSSでも設計・検証・運用の費用を見込みます。
長期リスク：更新時に特定会社へ依存しないか評価します。

機密データを扱う場合は、RBACやNetworkPolicy、Pod Securityを確かめます。

イメージ署名とノード分離も評価対象です。さらに、rootlessやuser namespace、ホストOSの権限も見ます。

経済産業省は2025年、SBOM活用の重要性を示す国際ガイダンスに共同で署名しました。部品表を納品・更新する運用も、RFPに含める価値があります（出典：経済産業省「SBOMの共有ビジョンに関する国際ガイダンス」、2025年）。

TCOは5年程度で比べ、クラウドやレジストリ、ログ保管、監視の費用も含めます。さらに、バックアップや証明書、脆弱性スキャン、アップグレード、オンコール、社内担当者の教育も含まれます。

OSSのcontainerdはライセンス料が原則として無料です。一方で、設計・検証・運用の人件費がかかります。さらに、資料が不足したまま更新時に一社へ依存すると、長期費用とリスクが高まります。

ポイント

実績がKubernetesやOpenShift中心のときは、containerd単体の経験があるかを別に確かめます。見積は総額で比べず、含まれる作業をそろえてから判断します。

発注後に起きやすい失敗と対策

ランタイム導入を完了地点にすると、アプリ公開や障害対応で問題が表面化します。そこで、本番で誰が何をするかを決めておき、設計レビューや移行リハーサル、運用訓練も計画に入れます。

バージョン更新と互換性の確認

containerdとKubernetesは別々に更新されるため、互換性を確認しながら採用します。

containerd 2.3：2026年4月30日にLTSとなり、2028年4月30日までサポート予定です。
Kubernetes 1.36：containerd 2.3.0以上または2.2.0以上が推奨対応です。

このリリース情報をもとに互換性表を作ります（出典：containerd公式「Releases」、2026年確認）。

RFPと契約には、更新対象や検証環境、互換性テスト、ロールバックを記載します。さらに、サポート終了の通知期限も決めておきます。

障害対応と引き継ぎの訓練

障害対応の演習と引き継ぎでは、確かめる対象と使う道具をあらかじめ決めておきます。

切り分け：アプリ、Kubernetes、containerd、クラウドの問題を判別します。
障害演習：ディスク枯渇、取得失敗、CrashLoopBackOff、CRIソケット、DNS、ストレージを想定します。
調査コマンド：ctrは低レイヤー、crictlはCRI、nerdctlはDocker CLIに近い操作に使います。

監視項目と一次対応を定めます。そのうえで、担当者が見るコマンドとログまでRunbookに記載します。

永続データと切り戻しの設計

containerdは実行基盤であり、業務データを安全に保存するデータベースではありません。

保存先：DB、ファイル、アップロード、キュー、キャッシュを別途設計します。
復旧：バックアップと復元を検証し、監視や切り戻し期限も決めます。
移行方式：並行稼働、データ同期、DNSやロードバランサーの切り替えを定めます。

既存VMの移行を、営業時間外の一度きりの作業にしないことが大切です。

よくある質問（FAQ）

技術、費用、運用、契約の責任分界を確かめてから相談すると、提案を比べやすくなります。

containerdだけを外注すればシステムは動きますか？

containerd単体では、複数ノードへの配置、ネットワーク公開、永続ストレージ、監視、CI/CDが不足します。Kubernetesやクラウド、レジストリ、CNI・CSIも発注範囲です。加えて、業務アプリや運用体制も含まれます。

OSSのcontainerdなら開発費や保守費は無料ですか？

containerd自体はOSSのため、ライセンス費用は原則かかりません。

開発・運用作業：設計や構築、移行、監視が含まれます。脆弱性対応、更新、障害対応も含まれます。
基盤の実費：クラスタ管理料、ノード、ストレージ、ログ、転送量。

初期費用だけでなく、数年分のTCOと社内の運用工数も含めて比べます。

containerdの委託先は何社くらい比較すべきですか？

比べる社数は、要件がどこまで固まっているかで変わります。

要件が整理済み：前提をそろえて3社程度へRFPを出します。
要件が未確定：まず2社程度へ要件定義やPoCを相談します。

同じ評価表で、対応範囲や実績、担当者の経験、障害対応、セキュリティを比べます。納品物と保守条件も評価に入れ、価格以外の条件も含めて選びます。

要件定義やPoCの結果は、本番構築のRFPに反映できます。

Dockerからcontainerdへ移行するときに注意することは何ですか？

OCIイメージやDockerfileは、継続して使える場合が多いです。ただし、周辺機能の互換性は確かめる必要があります。

互換性確認：Docker Engine API、Compose、ビルド、ログ、ボリューム、権限。
ツールの役割：ビルドはBuildKitなど、CRI確認はcrictl、低レイヤー調査はctr。

代表アプリで、起動やログ、監視、ボリュームを検証します。ロールバックも確かめたうえで、本番移行します。

まとめ

発注時は、ランタイムだけでなく、Kubernetesやクラウドまたはオンプレミスも対象にします。レジストリやネットワーク、ストレージも含めます。CI/CDや監視、セキュリティ、移行、保守も対象です。

業務要件と非機能要件を整理し、PoCで不確定要素を減らしてから、本番基盤と運用を契約します。

発注前に押さえる三つの結論

発注前に押さえるのは、基盤の範囲、RFPの記載事項、継続費用の三つです。

第一に：containerdだけでなく、運用可能な基盤を発注します。
第二に：対象アプリ、可用性、RTO・RPO、バージョンをRFPに記載します。セキュリティ、納品物、責任分界も、同じRFPに盛り込みます。
第三に：クラウド実費や保守もTCOに含めて比べます。

次に行うこと

発注準備は、現行環境と希望条件をまとめてから依頼先を選ぶ順で進めます。

構成図、対象アプリ、利用者数とピーク負荷を一枚にまとめます。
データ量、停止許容時間、希望時期、社内運用体制も記載します。
マネージドKubernetes、OSS自社構築、既存VMとの段階移行を比較します。
要件定義とPoCを含むRFPを作成します。

バージョン互換性、セキュリティ、引き継ぎ条件を確かめられる会社を選ぶと、長く使えるシステムにつながります。

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

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