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

Drone CIのシステム開発は、Git連携とRunnerの基盤に、Secrets、監査ログ、デプロイ承認を加えた形で発注します。

発注形態を選び、要件を整理してから、契約と費用、委託先を決めます。2026年8月時点の製品動向と公開事例を踏まえ、小規模PoCからJenkins移行までを扱います。

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

Drone CIのシステム開発を外注する前の全体像

Drone CIは、コードの変更を起点に、ビルド、テスト、イメージ作成を自動化します。

ステージングや本番へのデプロイも担うCI/CD基盤です。業務システムとは違い、開発チームのリリース作業を標準化する役割を持ちます。

発注対象になる構成要素

Drone CIは、リポジトリから実行基盤、保存先、安全管理まで複数の要素で動きます。そのため、どの要素を発注範囲に含めるかを先に決めておきます。

リポジトリ：GitHub、GitLab、Bitbucketなど
実行基盤：Webhookを受けるServerと、DockerまたはKubernetesのRunner
保存先：コンテナレジストリと成果物の保管先
安全管理：Secrets、認証認可、監査ログ

パイプラインはリポジトリ直下の.drone.ymlに記述し、push、Pull Request、tag、cron、手動のpromoteなどをトリガーにします。

「Droneを構築」とだけ依頼すると、Serverのインストールだけで納品されることがあります。依頼の時点で、対象リポジトリや同時実行数を指定し、1ビルドの最大時間と成果物の保存期間も決めておく必要があります。

開発、検証、本番の権限分離と、障害時の復旧方法も、発注書に含めます。

外注に向いている企業と内製に向いている企業

外注が合うか内製が合うかは、社内の人材と抱えている課題で分かれます。判断の材料として、外注に向く企業と課題、内製を始めやすい企業の特徴を挙げます。

外注に向く企業：DockerやKubernetesの専門担当者が不足している
外注に向く課題：Jenkinsやシェルスクリプトの整理、監査・承認・閉域網への対応
内製を始めやすい企業：小規模な単一リポジトリで、Docker・クラウドに慣れ、本番デプロイも手動でよい

非機能要件がある場合も、外注を検討する価値があります。初期設計を任せ、社内担当者が運用を引き継ぐ形なら、導入の速さと内製化の両立を目指せます。

OSS版はライセンスが無償でも、インフラの用意に加えて、バックアップ、更新、障害対応が必要です。そのため、ライセンス費用と運用コストは分けて考えます。

Drone CIの発注形態の選び方

発注形態は、完成物を請け負う一括請負と、作業時間を委ねる準委任に大きく分かれます。PoCや保守委託は、この2つと組み合わせて使われます。対象を絞った診断やPoCを先に行い、その結果を本番要件に反映すると、リスクを抑えやすくなります。

一括請負で完成形を依頼する場合

対象リポジトリと受入条件が明確で、パイプラインや接続先も決まっていれば、設計から構築、テスト、移行までを一括請負で依頼できます。納期と予算を固定しやすい契約です。

ただし、未決定の要件は後から変更扱いになりやすいです。本番承認や監査ログを追加する場合も、費用や納期に影響します。

成果物には、構成図やIaC、.drone.ymlテンプレートを含めます。Secrets登録手順とRunbookも、成果物として渡してもらいます。バックアップ復元記録と受入テスト結果も定めておくと、検収の判断材料になります。

準委任で設計・内製化を伴走してもらう場合

要件がどこまで確定しているか、社内でどこまで担いたいかによって、準委任の進め方を決めます。

適する状況：要件が未確定、既存CIを洗い出すところから始めたい、社内でも運用を学びたい
進める作業：週次で優先順位を見直し、診断、標準テンプレート、移行、教育を行う

技術面の不確実性が高いテーマでは、作業時間と専門人材を確保する契約が現実的です。ただし、準委任では完成物の範囲が自動的に保証されるわけではありません。

まず、月の稼働上限と担当者、会議体を決めます。次に、成果物と課題管理の進め方を定めます。未消化時間や追加作業の承認方法も、決めておきます。

内製化を目指す場合は、委託先だけが設定を変えられる状態を避ける必要があります。そこで、共同レビューと引き継ぎを作業項目に含めます。

PoCと運用委託を組み合わせる場合

PoCの範囲と検証項目を決め、本番展開後の保守分担も整理しておきます。

PoC範囲：1〜3リポジトリを2〜6週間で検証し、Webhook、Runner、テスト、通知、成果物保存、再実行を確認
検証項目：デモだけでなく、同時実行数、ビルド時間、権限、ネットワーク、Secretsも検証の対象
本番と保守：PoC後は請負か準委任で展開し、月次更新、Runner調整、監視、障害一次対応は保守契約に含める
運用分担：担当が異なる場合は、通知先、時間外連絡、復旧目標時間、責任分界を明確にする

ポイント

要件が固まっていれば一括請負、未確定なら準委任を候補にします。迷うときは、対象を絞ったPoCで適性を確かめてから本番の発注形態を決めると、判断材料が増えます。

RFPと要件整理で決める内容

RFPには製品名だけでなく、自動化する開発工程と水準を書きます。そのために、リポジトリ数、言語、ブランチ運用を洗い出します。あわせて、デプロイ先やクラウドの構成、既存CIと承認フローを整理します。

セキュリティ規程と運用体制も整理しておけば、委託先は同じ前提で見積を出せます。

パイプラインの流れに沿った機能要件

機能要件は、イベントから処理結果までの流れに沿って書きます。

Pull Request：静的解析と単体テストの実行
mainへのマージ：イメージのビルドと、タグ付きでのレジストリ保存
デプロイ：ステージングは自動、本番は承認後のpromote
失敗時：通知先、再実行条件、ロールバック対象の決定

単体テストだけでなく、結合テスト用のDBコンテナ、脆弱性スキャン、ライセンス確認も、必要かどうかを判断します。イメージ署名とSBOM生成も、判断の対象になります。

Harness公式資料は2026年3月時点で、コンテナイメージのSBOM生成と署名・アテステーションを案内しています。

Drone、レジストリ、外部製品ごとに担当範囲を分けると、過剰なスクラッチ開発を防げます。

数値と責任分界で書く非機能要件

性能、アクセス制御、実行環境のそれぞれについて、数値と責任範囲を定めます。

性能と稼働：実行数、時間、稼働、保存、復旧と停止許容、監視
権限と認証：本番権限、環境別Secrets、短期トークン、Vault、SSOとRBAC、監査ログ
特権実行：Docker privilegedやDockerソケットの使用条件

たとえば、平日9〜19時に10本を並行実行し、キュー待ちを平均5分以内にする条件を示せば、Runnerの台数やスペックを見積もれます。

Docker privilegedやDockerソケットを使う場合は、対象のRunnerとネットワークを定めます。加えて、信頼するイメージと監視方法も決めておきます。

受入条件と引き継ぎ条件

受入テストには、正常系だけでなく失敗系も含めます。加えて、運用引き継ぎの条件も、あらかじめ明確にしておきます。

動作確認：Pull Requestのテスト失敗、Secretsの非表示、Runner停止後の再実行
権限と復旧：Server設定の復元、承認者以外による本番promoteの防止
受領物：設定とIaC、CIテンプレート、接続管理、運用手順、連絡先とライセンス、変更履歴
Secrets管理：納品物からは除外し、自社での登録と委託先のアクセス失効の手順を用意する

ポイント

RFPは製品名で止めず、自動化する工程、非機能要件の数値、責任分界まで書きます。そうすると、委託先が同じ前提で見積もりを出せます。

Drone CIの外注における契約形態の選び方

依頼する作業の不確実性と継続性が契約選びの軸になります。

技術検証によって構成が変わるため、価格だけで契約形態を決めるのは避けます。固定範囲の構築は請負、調査・設計・移行支援は準委任、継続監視と障害対応は保守契約に分けて考えます。

請負契約で確認する項目

請負契約では、完成範囲、納期、検収方法を確認します。契約不適合への対応や仕様変更の手続きも、同じ確認項目に含めます。加えて、再委託の可否と知的財産権の帰属を取り決めます。

.drone.ymlやTerraformなどのIaCは、利用権と引き渡しの範囲を明確にします。運用スクリプトとテストコードについても、利用権と引き渡しの範囲を決めておきます。これらの範囲が曖昧だと、契約終了後に自社で修正できないことがあります。

保証範囲は、Serverの不具合、委託先の設定不備、クラウドやGitサービスの障害に分けて定めます。第三者サービスの仕様変更を無期限に保証するのは現実的ではないため、対応時間と追加費用の条件も決めておきます。

準委任・保守契約で確認する項目

準委任と保守では、月額に含まれる業務と、追加費用が発生する条件を契約に明記します。

準委任：月の稼働時間、担当者のスキル、優先順位、定例会と報告書、コードレビュー、教育時間
保守：監視対象と受付時間、一次切り分け、復旧支援、更新と脆弱性対応、Runnerの容量調整
作業範囲：ログ確認は含め、新規パイプラインやクラウド変更は別見積もりにする例
追加費用：将来の追加作業の単価を、契約書や料金表に記載

ライセンスと製品の将来性の確認

ライセンスの機能差と製品の移行方針を確認し、その内容を契約条件に反映します。

Editionの差：DroneにはOpen Source EditionとEnterprise Editionがある
Enterprise機能：無料条件、分散・Kubernetes Runner、組織Secrets、拡張ストレージ（公式FAQ）
Drone CI Essentials：年払いで月額300ドル。開発者100人以上はボリューム価格を問い合わせ
契約条件：製品名、バージョン、サポート期限、更新方針、移行費用を明記

この料金条件は、Drone公式の「Drone CI Essentials」「Enterprise FAQ」に記載されています（2026年8月確認）。

Harness公式は、Drone 2.0からDrone 3.0、そして現在のHarness Open Sourceへの移行の流れを案内しています。

Drone継続、Harness移行、別CIへの切替のどれを選ぶかで、設計と保守窓口が変わります。

ポイント

作業の不確実性と継続性を見て、請負、準委任、保守の契約を組み合わせます。価格だけで比べると、保証範囲や追加費用の条件を見落とす恐れがあります。

Drone CIのシステム開発費用の相場

規模が大きくなるほど、費用の幅も広がります。

外注費は、ライセンス料だけでなく、作業ごとの費用を合算したものです。対象は、診断や設計、パイプライン、クラウド構築から、移行、テスト、教育、保守までです。

ここで示すのは、Droneの定価ではなく、リポジトリ数やセキュリティ要件を前提にした導入支援の推定レンジです。

金額は、リポジトリ数や委託先の単価、既存環境によって変わります。さらに、Kubernetesの利用、監査要件、24時間運用の有無も影響します。

小規模PoCは50万〜150万円程度が一つの目安

1〜5リポジトリでDocker Runner、基本的なビルドとテスト、通知、最低限のバックアップを試す場合、初期費用は50万〜150万円程度です。期間は2〜6週間程度を想定します。

これは公式価格ではなく、現状確認から設計、設定、テスト、報告までを外部委託した場合の作業量から算出した推定です。

VMやストレージ、レジストリを含むクラウド費用は別途かかります。ログ保管の費用も見込んでおく必要があります。そのうえで、本番同等の高可用性を避け、検証の目的を絞ると、初期費用を抑えながら課題を洗い出せます。

中規模の本番導入は150万〜500万円程度が目安

中規模導入では、対象範囲と運用条件によって、初期費用と月額費用が変わります。

初期導入：10〜50リポジトリを対象に、150万〜500万円程度、2〜4か月程度
上振れ要因：Jenkins移行、SSO、承認ゲート、閉域ネットワーク
月額の推定例：インフラ5万〜30万円程度、保守15万〜50万円程度

初期導入には、複数のRunnerやレジストリ、Secretsの設定を含む想定です。監視、ステージング連携、標準パイプラインも含みます。期間と金額は、いずれも推定レンジです。

月額は、一般的なCI/CD基盤の工数に基づく推定です。Runnerの稼働時間やクラウド料金、SLAで変わるため、初期費用と継続費用を分けて見ます。保守範囲も確認します。

大規模移行・高可用性では500万〜1,500万円以上の想定

大規模導入では、高可用性や既存CIからの移行条件によって費用が変わります。

想定する構成：複数部門、Kubernetes Runner、SSOとRBAC、承認ゲート、監査ログ、災害復旧
移行・運用：Jenkins移行、24時間運用
推定レンジ：初期費用500万〜1,500万円以上、期間4〜9か月以上となる場合
費用を左右する作業：プラグイン代替、Secrets再設計、過去成果物の扱い、並行稼働の検証

ScienceSoftは、7人のチームで、最大1日100コミットのマルチクラウド向けパイプラインにDrone CIを利用したと説明しています（出典: ScienceSoft公開事例、2026年8月確認）。

この数値は個別案件の実績であり、自社の費用や成果にそのまま当てはめにくいです。そのため、自社のコミット数、ビルド時間、環境数を示して見積もりを依頼します。

ポイント

まず、自社の対象リポジトリ数と既存環境を示し、初期費用、月額費用、クラウド費用を分けて見積もりを取ります。金額の比較がしやすくなります。

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

委託先は、CI/CD対応の有無に加えて、Drone実績とDocker・Kubernetesの運用経験で比べます。移行の経験、Secretsと監査の設計、保守体制も観点に入ります。

公開実績がない場合は、面談で担当者や利用バージョンを確認します。構築範囲と運用期間も、あわせて聞いておきます。

Droneの直接経験と移行経験の確認

候補会社には、Droneの構築実績と移行経験を具体的に尋ねます。

構築規模：ServerとRunnerをどの規模で構築したか
Runner経験：DockerとKubernetesのどちらを使ったか
Git連携：どのGitサービスと連携したか
移行経験：Jenkinsから移行した経験の有無

Harness公式は、DroneからHarness Open Sourceへの移行を案内しています。既存Droneの保守に加えて、将来の移行計画も説明できるかを確認します。

Avykaの公開事例では、Droneのパイプラインを評価し、低リスク環境でパイロットを行ったうえで段階移行する、4段階の進め方を紹介しています（出典: Avyka公開事例、2026年8月確認）。

この事例の成果や進め方は、個別事例のものです。委託先が、全面移行の前に依存関係とリスクを洗い出す手順を持つかを確認します。

見積書の作業範囲と前提条件

見積書は、総額だけでなく作業範囲をそろえて比べます。調査から移行まで、テストや教育、文書、保守を含めた範囲を確認します。構築のみの会社と、移行や教育まで含む会社の金額は、そのままでは比べにくいです。

前提には、リポジトリ数やブランチ数、環境数を記載します。同時実行数やクラウドの準備状況、既存CIの設定量も書き添えます。ネットワーク制約やレビュー回数も、同じ前提として示してもらいます。

追加作業単価、リポジトリ追加料金、夜間対応を分けて示してもらうと、ライセンス料やクラウド利用料も含めて、TCO（総所有コスト）で比べられます。

提案に含まれるセキュリティと運用の範囲

CI/CD基盤は高い権限を持つため、安全性と提案の範囲を確認します。

OWASPは、リスク領域としてアクセス制御やSecrets、依存関係を挙げています。第三者プラグインや成果物、ログも、同じ領域に含まれます。

出典: OWASP「CI/CD Security Cheat Sheet」（2026年8月確認）。

安全対策：最小権限、Pull Requestの信頼境界、イメージ固定、脆弱性スキャン、監査ログ
安価な見積もり：Secrets設計やバックアップ、監視、受入テスト、引き継ぎが省かれていないかを確認
高額な独自開発：Droneや既存クラウドで代替できる部分を見直す
保守しやすさ：製品を基盤にし、必要な社内標準テンプレートや承認フローを追加

ポイント

公開実績がない委託先は、担当者や利用バージョン、構築範囲を面談で確かめてから選びます。見積もりは、作業範囲と前提条件をそろえて比べます。

発注後のDrone CI導入の進め方

各段階の確認を挟むことで、課題を次工程へ持ち越しにくくなります。

導入は、現状診断から始まり、基本設計とPoC、標準化、段階移行を経て、受入と運用引き継ぎへ進みます。各段階で成果物と判断基準を定め、課題を残したまま次へ進まないようにします。

本番デプロイを含む場合は、低リスクのサービスから移行し、旧CIと結果を比べます。

フェーズごとの成果物と判断基準

次の段階へ進む前に、そのフェーズの成果物を判断基準に照らして検証します。

現状診断：リポジトリとブランチ、パイプライン、プラグイン、Secrets、成果物とデプロイ先、障害履歴を一覧にする
設計とPoC：Server、Runner、DB、レジストリ、ログ、認証の構成図とネットワークフローを作成し、1〜3リポジトリで成功と失敗、再実行と復旧を検証
標準化：言語・フレームワーク別の.drone.yml、命名、Secrets登録、承認フローを整備
段階移行：開発、ステージング、本番の順に広げ、ビルド時間と失敗率、デプロイ頻度、手作業時間を比べる

運用引き継ぎと属人化の防止

引き継ぎの対象として、Runbookと社内操作訓練、運用KPIを決めます。

Runbook：日常運用、障害対応、Runner増設、Secretsのローテーション
保守手順：証明書更新、バージョンアップ、バックアップ復元、脆弱性対応
KPI：ビルド成功率、平均時間、キュー待ち、デプロイ頻度、変更失敗率、復旧時間

構成図や手順書に加えて、社内担当者が実際に操作するハンズオンを行っておくと、委託先が不在のときにも対応できる体制に近づきます。

導入前に計測していなければ、効果を評価できません。そのため、発注時に計測方法と報告頻度を決めておきます。

よくある質問（FAQ）

発注時には、費用と契約、セキュリティ、将来の移行を確認しておく必要があります。よくある質問への答えは、次のとおりです。

Drone CIのシステム開発はどこまで外注できますか？

現状診断から設計、Server・Runner構築、パイプライン作成までを依頼できます。既存CIからの移行やセキュリティ設計も、対象に含められます。テスト、教育、保守も依頼の範囲に入ります。

業務上の承認者やリリース基準は自社で決め、外注先には実装と改善を委ねる形が望ましいです。

OSS版を使えば外注費は不要ですか？

ライセンスが無償でも、インフラや運用には費用がかかるため、外注費は引き続き必要になります。具体的には、Runnerの基盤やDB、ログの費用です。加えて、バックアップ、更新、監視、障害対応の費用もかかります。

自社に運用担当者がいない場合は、初期構築と保守を外注費に含めて考えます。

JenkinsからDrone CIへ移行する場合の注意点は何ですか？

移行は、Jenkinsfileやプラグインの洗い出しから始まります。Secrets、認証、成果物のほか、通知や権限、デプロイ先も同じ一覧に入れます。.drone.ymlへ置き換える処理と、外部サービスへ移す処理は、分けて整理します。

低リスクのリポジトリを先に並行稼働させ、テスト結果やビルド時間、成果物の同一性、ロールバックを確認してから広げます。

2026年時点でDrone CIを発注しても問題ありませんか？

既存Droneを継続する期間やEnterprise契約の有無、Harness Open SourceやHarness CIへの移行方針を確認し、社内体制と合わせて判断します。

機能だけでなく、サポート期限やセキュリティ更新、移行時のデータと設定もRFPに含めます。そのうえで、委託先から複数の案を出してもらいます。

まとめ

Drone CIは、安全なリリースを繰り返すための仕組みとして発注します。まず現状を整理し、1〜3リポジトリのPoCで適性を確認します。

発注前にRFPへ入れるべき要素

RFPには機能要件に加えて、同時実行数やビルド時間、保存期間を記載します。復旧目標と権限分離、監査ログ、Secretsも入れておきます。

受入テストと、IaCや文書の引き渡しも定めます。初期費用とライセンス、クラウド、保守、追加作業単価を分けて示してもらい、同じ条件で見積もりを比べます。

PoCと段階移行の組み合わせ

要件が未確定であれば、診断とPoCは準委任で行い、確定した部分を請負で構築します。導入後は、RunnerやSecretsの管理、更新、復元、障害対応を保守の範囲に含めます。

社内担当者へ運用を引き継ぎ、製品の将来性も説明できる委託先を選ぶと、導入後も自社で運用を回せる状態に近づきます。

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

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