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

Drone CIのシステム開発を発注・外注するなら、単にCIツールをインストールするのではなく、Git連携、Runner、Secrets、監査ログ、デプロイ承認まで含む開発基盤として要件を定めることが重要です。

本記事では、Drone CIのシステムを外部へ委託する際の発注形態、RFPと要件整理、契約形態、費用相場、委託先の選び方、見積書の比較方法を、2026年8月時点の製品動向と公開事例を踏まえて解説します。自社で小さく試す場合から、Jenkinsなどから移行して本番運用する場合まで、発注前に確認したい論点を整理します。

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

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

Drone CIは、ソースコードの変更を起点にビルド、テスト、コンテナイメージの作成、ステージングや本番へのデプロイを自動化するコンテナネイティブなCI/CDプラットフォームです。販売管理や会計の業務システムとは異なり、開発チームのリリース作業を標準化する基盤として発注範囲を考えます。

基本構成は、GitHub・GitLab・BitbucketなどのGitリポジトリ、Webhookを受け取るDrone Server、ジョブを実行するDockerまたはKubernetes Runner、コンテナレジストリと成果物保管先、Secrets管理、認証認可と監査ログです。リポジトリ直下の.drone.ymlにパイプラインを記述し、push、Pull Request、tag、cron、手動のpromoteなどをトリガーにします。

外注時に「Droneを構築してください」とだけ伝えると、Serverのインストールだけで納品される可能性があります。発注書には、どのリポジトリを対象にするか、同時実行数、1ビルドの最大時間、成果物の保存期間、開発・検証・本番の権限分離、障害時の復旧方法まで含める必要があります。

外注に向いているのは、DockerやKubernetesの専門担当者が不足している企業、既存のJenkinsやシェルスクリプトを整理したい企業、監査・承認・閉域網などの非機能要件がある企業です。開発会社に初期設計を任せ、社内担当者が運用を引き継ぐ形にすれば、導入スピードと内製化の両方を狙えます。

一方、対象が1つの小規模リポジトリで、開発者がDockerとクラウドに慣れており、本番デプロイも手動でよい場合は、まず社内でPoCを行っても構いません。ただし、無償のOSS版でもインフラ、バックアップ、アップデート、障害対応は必要です。無料であることと、運用コストがゼロであることは分けて考えます。

Drone CIの発注形態はどれを選べばよいですか？

発注形態は、丸ごと任せる一括請負、要件を一緒に詰める準委任、短期間で適性を確かめるPoC、運用だけを任せる保守委託の4つに分けて検討します。最初から本番環境を一括発注するより、対象を絞った診断やPoCを先に行い、結果を本番要件へ反映する方が、Drone CIではリスクを抑えやすいです。

対象リポジトリ、パイプライン、接続先、受入条件が明確であれば、一括請負で設計から構築、テスト、移行までを依頼できます。納期と予算を固定しやすい一方、発注時点で決めていない要件は変更扱いになりやすく、あとから本番承認や監査ログを追加すると追加費用や納期延長につながります。

一括請負を選ぶ場合は、成果物を「Drone Serverが起動すること」だけにせず、構成図、IaC、.drone.ymlのテンプレート、Secretsの登録手順、運用Runbook、バックアップ復元記録、受入テスト結果まで定義します。検収の基準が文書化されているほど、見積比較と納品判定がしやすくなります。

要件が固まっていない、既存CIの棚卸しから始めたい、社内メンバーにも運用を覚えてほしいという場合は、準委任が適しています。発注側と委託先が週次で優先順位を見直しながら、診断、標準テンプレート作成、パイプライン移行、教育を進めます。技術的な不確実性が高いテーマほど、作業時間と専門人材を確保する契約が現実的です。

ただし、準委任は完成物の範囲が自動的に保証される契約ではありません。月ごとの稼働上限、担当者、会議体、成果物の定義、課題管理、未消化時間の扱い、追加作業の承認方法を決めます。内製化を目的にするなら、委託先だけが設定を変更できる状態を避け、共同レビューと引き継ぎを契約の作業項目に入れます。

初回発注では、1〜3リポジトリを対象にした2〜6週間程度のPoCを設定し、Webhook、Runner、テスト、通知、成果物保存、失敗時の再実行を確認します。PoCの目的は「動いた」というデモではなく、本番で困る同時実行数、ビルド時間、権限、ネットワーク到達性、Secretsの取り扱いを確かめることです。

PoC後は、本番展開を一括請負または準委任で進め、月次のアップデート、Runnerの増減、監視、障害一次対応を保守契約に切り出します。構築担当と運用担当が異なる場合は、アラートの通知先、営業時間外の連絡方法、復旧目標時間、責任分界を明確にします。

RFPと要件整理では何を決めるべきですか？

RFPでは、製品名だけでなく「どの開発プロセスを、どの水準まで自動化するか」を記載します。リポジトリ数、開発言語、ブランチ運用、デプロイ先、利用中のクラウド、既存CI、社内の承認フロー、セキュリティ規程、運用体制を先に棚卸しすると、委託先から同じ前提の見積を受け取れます。

機能要件は、「Pull Request作成時に静的解析と単体テストを実行する」「mainへのマージ時にコンテナイメージをビルドし、レジストリへタグ付きで保存する」「ステージングでは自動デプロイし、本番では承認者の操作後にpromoteする」のように、イベントから結果まで記述します。失敗時に通知する場所、再実行の条件、ロールバックする対象も合わせて書きます。

テストも、単体テストだけでなく結合テスト用のDBコンテナ、脆弱性スキャン、ライセンス確認、イメージの署名、SBOMの生成まで必要性を判断します。Harnessの公式資料では、2026年3月時点でコンテナイメージのSBOM生成と署名・アテステーションが案内されています。Drone単体で実装する範囲と、レジストリや外部セキュリティ製品に任せる範囲をRFPで分けると、過剰なスクラッチ開発を防げます。

非機能要件では、同時実行数、ビルドの目標時間、稼働時間、バックアップ頻度、復旧目標時間、ログと成果物の保存期間、アップデートの許容停止時間、監視の通知先を数値で定めます。例えば「平日9〜19時に10本のビルドが並行しても、キュー待ちを平均5分以内にする」のように書けば、Runnerの台数やスペックを見積もりやすくなります。

本番デプロイの権限は開発者と分け、環境ごとのSecrets、短期トークン、外部Vault、SSO、RBAC、監査ログの要否を明示します。Docker privilegedやDockerソケットの利用はホストに強い権限を与えるため、利用するなら対象Runner、ネットワーク、イメージの信頼条件、監視方法を記載します。

受入テストは、正常系だけでなく失敗系を含めます。Pull Requestでテストが失敗すること、本番Secretsがログに表示されないこと、Runner停止時にジョブが再実行できること、バックアップからServer設定を復元できること、承認者以外が本番promoteできないことを確認します。

また、委託先から受け取るものを、設定ファイル、IaC、CIテンプレート、接続情報の管理方法、運用手順、障害時の連絡先、ライセンス一覧、変更履歴に分けます。Secretsそのものを納品物に含めず、発注側の管理領域へ登録する手順と、委託先のアクセスを失効する手順まで用意します。

Drone CIの外注では契約形態をどう選びますか？

Drone CIは、技術検証の結果によって構成が変わりやすいため、契約形態を価格だけで決めないことが大切です。固定範囲の構築は請負、調査・設計・移行支援は準委任、継続監視と障害対応は保守契約というように、作業の不確実性と責任範囲に合わせて分けます。

請負契約では、完成させる範囲、納期、検収方法、契約不適合への対応、仕様変更の手続き、再委託の可否、知的財産権の帰属を確認します。特に.drone.yml、TerraformなどのIaC、運用スクリプト、テストコードの利用権と引き渡し範囲が曖昧だと、契約終了後に自社で直せません。

納品後の保証範囲も、Drone Serverの不具合、委託先が作成した設定の不備、クラウドやGitサービスの障害を分けて記載します。第三者サービスの仕様変更まで無期限に保証する契約は現実的ではないため、対応時間と追加費用が発生する条件を明確にします。

準委任では、月の稼働時間、担当者のスキル、作業の優先順位、定例会、報告書、コードレビュー、教育時間を決めます。保守では、監視対象、問い合わせの受付時間、一次切り分け、復旧支援、アップデート、脆弱性対応、Runnerのキャパシティ調整をサービスレベルとして分けます。

月額を比較するときは、保守時間に含まれる作業と含まれない作業を分けてください。例えば、通常のログ確認は含むが、パイプラインの新規作成やクラウド構成変更は別見積もりとするなど、将来の追加作業の単価も契約書や料金表に残します。

DroneにはOpen Source EditionとEnterprise Editionがあり、公式FAQではEnterpriseの無料条件や、分散Runner、Kubernetes Runner、組織Secrets、スケーラブルなストレージなどの差が案内されています。Enterpriseの料金ページでは、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へ移行するのか、別のGit統合CIへ切り替えるのかで、発注する設計や保守窓口が変わります。契約書には対象製品の名称、バージョン、サポート期限、アップデート方針、移行時の追加費用を明記します。

Drone CIのシステム開発費用と相場はいくらですか？

Drone CIの外注費は、ライセンス料だけでなく、現状診断、設計、パイプライン作成、クラウド構築、移行、テスト、教育、保守を合算して考えます。以下はDroneの定価ではなく、リポジトリ数やセキュリティ要件を前提にした導入支援の推定レンジです。実際の金額は、委託先の単価、既存環境、Kubernetesの有無、監査要件、24時間運用の有無で変動します。

1〜5リポジトリを対象に、Docker Runner、基本的なビルドとテスト、通知、最低限のバックアップを試すPoCなら、初期費用は50万〜150万円程度が一つの推定目安です。期間は2〜6週間程度を想定します。これはDrone公式の価格ではなく、現状確認、設計、設定、テスト、報告を外部へ依頼した場合の作業量から算出したレンジです。

クラウドのVM、ストレージ、レジストリ、ログ保管などのインフラ費用は別に発生します。PoCでは本番同等の高可用性を作り込まず、検証目的を明確にすることで、初期費用を抑えながら本番化の課題を洗い出します。

10〜50リポジトリ、複数Runner、レジストリ、Secrets、監視、ステージング連携、標準パイプラインの整備まで含める中規模導入では、初期費用150万〜500万円程度、期間2〜4か月程度が推定レンジです。既存Jenkinsからの移行、SSOや承認ゲート、閉域ネットワークを加えると、同じリポジトリ数でも上限を超える可能性があります。

月額は、インフラ5万〜30万円程度に加え、監視・アップデート・問い合わせ対応などの保守15万〜50万円程度を見込むケースがあります。これも一般的なCI/CD基盤の構築工数から置いた推定であり、Runnerの稼働時間やクラウド料金、SLAの有無で変わります。見積書では初期費用と継続費用を分け、保守に含む作業を確認します。

複数部門での利用、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の運用力、既存CIからの移行経験、Secretsと監査の設計力、導入後の保守体制で比較します。Droneそのものの構築経験が公開されていない場合は、担当者の実績、利用バージョン、構築範囲、運用期間を面談で確認します。

候補会社には、「Drone ServerとRunnerをどの規模で構築したか」「Docker RunnerとKubernetes Runnerのどちらを使ったか」「GitHub・GitLab・Bitbucketのどれと連携したか」「Jenkinsから移行した経験があるか」を質問します。Harness公式がDroneからHarness Open Sourceへの移行を案内しているため、既存Droneの保守だけでなく、将来の移行計画まで説明できる会社かも確認します。

Avykaの公開事例では、Droneのパイプラインを評価し、低リスク環境でパイロットを行い、段階移行する4段階の進め方が紹介されています。移行事例の数値は個別案件の成果ですが、発注者が見るべきなのは、いきなり全面移行せず、依存関係とリスクを棚卸ししてから進めるプロセスです（出典: Avyka公開事例、2026年8月確認）。

見積比較では、総額の安さより、現状調査、基本設計、詳細設計、Server構築、Runner構築、パイプライン移行、テスト、教育、ドキュメント、保守がどこまで含まれるかを揃えます。A社は構築だけ、B社は移行と教育まで含むという比較では、金額だけ見ても判断できません。

見積書の前提には、対象リポジトリ数、ブランチ数、環境数、同時実行数、クラウドアカウントの準備状況、既存CIの設定量、ネットワーク制約、レビュー回数を記載してもらいます。追加費用の単価、リポジトリ追加時の料金、夜間対応、ライセンス料、クラウド利用料も別行に分けると、TCOを比較できます。

CI/CD基盤は高い権限を持つため、価格だけでなく安全な実行環境を評価します。OWASPのCI/CD Security Cheat Sheetは、アクセス制御、Secrets、依存関係、第三者プラグイン、成果物の完全性、ログと可視性などを主要なリスク領域として整理しています（出典: OWASP「CI/CD Security Cheat Sheet」、2026年8月確認）。委託先の提案に、最小権限、Pull Requestの信頼境界、イメージ固定、脆弱性スキャン、監査ログが含まれているか確認します。

見積が極端に安い場合、Secretsの設計、バックアップ、監視、受入テスト、引き継ぎが省かれていないかを確認します。逆に、すべてを独自開発する高額提案も、Droneや既存のクラウドサービスで代替できる部分がないか見直します。製品を基盤に、社内標準テンプレートや承認フローなど必要な部分だけを追加する方が、保守しやすい構成になりやすいです。

発注後のDrone CI導入はどのように進みますか？

発注後は、現状診断、基本設計、PoC、標準化、段階移行、受入、運用引き継ぎの順に進めます。各段階で成果物と判断基準を置き、前段の課題を残したまま次へ進まないことが大切です。特に本番デプロイを含む場合は、低リスクのサービスから移行して、旧CIと結果を比較します。

現状診断では、リポジトリ、ブランチ、既存パイプライン、プラグイン、Secrets、成果物、デプロイ先、障害履歴を一覧化します。設計では、Server、Runner、DB、レジストリ、ログ、認証の構成図とネットワークフローを作成します。PoCでは1〜3リポジトリを対象に、成功だけでなく失敗・再実行・復旧を検証します。

標準化では、言語やフレームワークごとの.drone.ymlテンプレート、命名規則、Secretsの登録ルール、承認フローを整えます。段階移行では、開発環境、ステージング、本番の順に対象を広げ、各段階でビルド時間、失敗率、デプロイ頻度、手作業時間を比較します。

引き継ぎでは、日常運用、障害対応、Runnerの増設、Secretsのローテーション、証明書更新、バージョンアップ、バックアップ復元、脆弱性対応をRunbookにします。委託先の担当者が不在でも対応できるよう、構成図と手順書だけでなく、実際に社内担当者が操作するハンズオンを行います。

運用開始後のKPIは、ビルド成功率、平均ビルド時間、キュー待ち時間、デプロイ頻度、変更失敗率、復旧時間などから選びます。導入前の数値を計測していないと効果を評価できないため、発注時点で計測方法と報告頻度を決めます。

よくある質問（FAQ）

Drone CIの発注では、製品の使い方だけでなく、費用、契約、セキュリティ、将来の移行まで確認する必要があります。ここでは、外注を検討する企業からよく寄せられる質問に直接回答します。

現状診断、アーキテクチャ設計、ServerとRunnerの構築、パイプライン作成、既存CIからの移行、セキュリティ設計、テスト、教育、保守まで外注できます。ただし、業務上の承認者やリリース基準は自社が決め、外注先には実装と改善を委託する形が望ましいです。

不要にはなりません。ソフトウェアのライセンスが無償でも、クラウドやオンプレミスのインフラ、Runner、DB、ログ、バックアップ、アップデート、監視、障害対応の費用がかかります。自社に運用担当者がいない場合は、初期構築と保守を外注費として見積もります。

Jenkinsfile、プラグイン、Secrets、認証、成果物、通知、権限、デプロイ先を棚卸しし、Droneの.drone.ymlへ置き換えられる処理と、外部サービスへ移す処理を分けます。低リスクのリポジトリを先に並行稼働し、テスト結果、ビルド時間、成果物の同一性、ロールバック手順を確認してから対象を広げます。

採用可否は、既存Droneを継続する期間、Enterpriseの契約条件、Harness Open SourceやHarness CIへの移行方針、社内の運用体制を確認して判断します。Droneの機能だけで決めず、サポート期限、セキュリティ更新、移行時のデータと設定の扱いをRFPに含め、委託先から複数案を出してもらうことが安全です。

まとめ

Drone CIのシステムを発注・外注するときは、ツールの導入作業ではなく、開発チームが安全に何度もリリースできる仕組みの構築として考えます。まずは現状のリポジトリ、パイプライン、Secrets、デプロイ先、運用課題を整理し、1〜3リポジトリのPoCで適性を確認します。

RFPには、機能要件だけでなく、同時実行数、ビルド時間、保存期間、復旧目標、権限分離、監査ログ、Secrets、受入テスト、IaCとドキュメントの引き渡しを記載します。見積比較では、初期費用、ライセンス、クラウド費用、保守費用、追加作業の単価を分け、同じ前提条件で比較してください。

要件が固まっていない企業は、診断とPoCを準委任で依頼し、構成が定まった部分を請負で構築する方法が適しています。導入後は、Runnerのキャパシティ、Secrets、アップデート、バックアップ復元、障害対応を保守範囲に含め、社内担当者が運用できるように引き継ぎます。製品の将来性も含めて説明できる委託先を選ぶことが、Drone CIの発注を成功させる近道です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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