Drone CIの導入は、要件整理から定着運用まで、6つのフェーズを順に進めます。この順で進めると、安全なリリース基盤につながります。段階ごとに技術と運用の課題を分けて見ると、判断がぶれにくくなります。
▼全体ガイドの記事
・Drone CIのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Drone CIのシステムの全体像
Drone CIは、ソフトウェアを安全に繰り返しリリースするための開発基盤です。販売管理や会計のように業務を管理するシステムとは、目的が異なります。
導入効果は、変更から検証完了までの時間やリリース失敗率で測ります。自動化の可否だけでは効果を捉えきれないため、手作業の削減と監査証跡の追跡性も指標にします。
Server・Runner・実行基盤の構成
基本構成は、Gitリポジトリ、Webhookを受けてジョブを管理するDrone Server、ジョブを実行するRunnerです。実行基盤として、DockerやKubernetesなども必要になります。
- コード管理：ソースコードを置くGitリポジトリ。
- ジョブ管理：Webhookを受け、Runnerへ処理を割り当てるDrone Server。
- 実行と保管：コンテナ内での処理と、成果物をレジストリや保管先へ送ること。
- 統制：Secrets、認証認可、監査ログの組み込み。
Runnerは、ビルドやテストの結果をServerへ返します。また、処理は指定されたコンテナイメージの中で行います。
Drone公式では、パイプラインをリポジトリ直下の.drone.ymlに定義します。起動イベントには、push、Pull Request、tagがあります。さらに、cron、promote、rollbackも起動のきっかけになります（出典: Drone公式Pipeline Overview、2026年8月確認）。
定義をコードで管理すると、画面で設定する場合と違い、変更をレビューしたり履歴をたどったりできます。
製品の現在地と適用範囲
2026年時点では、「DroneはOSSで無料」と決めつけないことが大切です。ただし、Open Source Editionには、機能や構成上の制限があります。
Enterprise Editionには、分散Runner、Kubernetes Runner、組織Secretsがあります。加えて、スケーラブルなストレージやオートスケールも利用できます（出典: Drone公式Enterprise FAQ、2026年8月確認）。
Harness公式は、Drone 2.0からDrone 3.0、さらに現在のHarness Open Sourceへの移行について案内しています。
- 現行製品：Droneを長く使うか、Harnessへ移行するかの判断。
- 比較する条件：契約、サポート、将来の運用費、技術検証。
新規構築では、採用エディションとライセンスを要件に明記します。データの所在、オンプレミスや閉域網への対応、移行方針も入れておきます。
Drone CIのシステム開発・導入の進め方
サーバー構築と.drone.ymlの作成は、導入の一部です。要件整理から定着までを6フェーズに分けると、技術課題と運用課題を切り分けられます。
各フェーズの成果物と判断基準、次へ進む条件を、関係者で合意しておきます。そのため、本番承認や監査要件が後から増えるリスクを抑えやすくなります。
フェーズ1：要件整理とフェーズ2：選定
要件整理では、対象リポジトリ数、言語・フレームワーク、現在のCIを洗い出します。ビルド時間、同時実行数、デプロイ先も、同じ一覧に書き出します。
Gitやクラウド、レジストリの構成も確認します。ログと成果物については、保存期間も押さえておきます。
手作業が残っている箇所も調べて、運用ルールに落とし込みます。たとえば、Pull Requestごとの単体テスト、mainへのマージ後のステージングデプロイ、本番での承認者2名による確認などが挙げられます。
選定では、Runnerの種類、Serverの設置方法、Harness Open Sourceや別のマネージドCIを比較します。技術的な好みだけで決めると、運用条件の確認が抜けがちです。そのため、次の3つの観点で比べます。
- 接続と配置：既存のGit、閉域網、セルフホストに合うか。
- 安全性：SSO・RBAC、Secrets、監査ログ、バックアップと復旧の備え。
- 拡張と支援：Runnerの増減への対応、サポート窓口、将来の移行のしやすさ。
最初は1〜3リポジトリのPoCで検証し、本番に必要な機能とは分けて考えます。そうすると、初期から過剰な構成を抱えにくくなります。
製品を選ぶ前に、利用者と管理者、開発・ステージング・本番の権限が分かれているかを確かめます。次に、ログと成果物の保存期間、失敗時の通知先と一次対応者を決めておきます。
DroneからHarnessへの将来方針も確かめます。未決定の項目が残っている場合は、製品選定を確定させない方が安全です。
フェーズ3：設計・開発と安全な標準形
設計では、Server、Runner、データベースについて、どこまでを誰が受け持つかを図にします。レジストリ、オブジェクトストレージ、Secretsも、同じ図に入れます。監視とバックアップも、図に加えます。
.drone.ymlには、社内標準の型を用意します。型には、ビルド、単体テスト、静的解析を含めます。
さらに、依存関係スキャン、イメージ作成、成果物保存も入れます。最後に、ステージングデプロイと本番承認まで含めます。
- 小規模PoC：Docker Runnerと既存のマネージドDBでの検証。
- 中規模以上：Runnerの分散と、待ち時間や障害時の切り替えの設計。
- Kubernetes利用時：Namespace、ノード、通信範囲、上限、イメージ元の決定。
- 安全な標準形：テスト、スキャン、成果物保存、デプロイ承認の定義。
Drone公式のDocker Pipelineでは、各stepを指定したDockerコンテナで動かし、step同士でワークスペースを共有できます（出典: Drone公式Docker Pipeline仕様、2026年8月確認）。
DBを使う結合テストでは、サービスコンテナを使えます。ただし、起動の完了はヘルスチェックで確かめ、待機時間を固定する設計は避けます。
本番デプロイ用のIDは、開発用と分けます。具体的には、短期トークン、最小権限、環境別Secretsを組み込みます。さらに、承認ゲートと監査ログも加えます。
Dockerソケットのマウントやprivileged設定は、Runnerやホストに強い権限を与えるおそれがあります。そのため、信頼できないPull Requestは、同じ実行環境で動かさないようにします。
イメージは、タグだけでなくダイジェストで固定します。プラグインや依存パッケージも、入手元を管理します。
フェーズ4：テストで確かめる機能・失敗・復旧
テストでは、正常系のビルドが通るだけでは足りません。失敗や移行も含めて、次の観点を確かめます。
- 起動と停止：Webhookや、Pull Request・tagによる起動、step失敗後の停止。
- 権限と実行：本番承認、同時実行の上限を超えたときの待機、Secretsの非表示。
- 移行比較：旧CIとの並行稼働で、結果、件数、イメージ、時間、デプロイ先を比べる。
- 受入と復旧：通知、復元、再実行、承認記録、脆弱性基準の確認。
Pull Requestの変更から本番用の資格情報を取り出せないことも、テストケースに含めます。
過去の成果物や履歴をどこまで移すかは、必要性と費用をもとに決めます。すべてを移さない方法もあります。その場合は、旧CIを参照専用で残し、新しい実行履歴は新システムで管理します。
受入条件には、ビルドの成功以外の状態も書いておきます。このため、導入会社の作業完了と社内の運用開始を分けて評価できます。脆弱性スキャンで定めた重大度を超える成果物は、公開できないことを条件にします。
フェーズ5：稼働とフェーズ6：定着
稼働は、影響の小さいリポジトリから段階的に進めます。切り替えと定着の要点は、次の4つにまとめます。
- 切り替え順：低リスクのサービスでビルドとテストを安定させた後、ステージング、本番へ広げる。
- 戻す準備：旧CIの保持と、判断者、停止手順、連絡先、復旧目標のRunbookへの記載。
- 運用標準：テンプレート、命名、Secrets申請、Runner増設、更新と障害対応の決まり。
- 効果の見直し：KPIを導入後の1か月、3か月、6か月で確かめる。
KPIには、デプロイ頻度、変更リードタイム、変更失敗率を使います。加えて、復旧時間とビルド待ち時間も含めます。最後に、再実行率と手動承認の滞留時間も加えます。
OWASPのCI/CD Security Cheat Sheetは、主なリスクを10項目に整理しています（出典: OWASP CI/CD Security Cheat Sheet、2026年8月確認）。項目には、フロー制御、ID・アクセス管理、依存関係悪用があります。
そのほか、汚染されたパイプライン実行、認証情報の衛生、設定不備が挙げられます。成果物の完全性やログ不足も、項目に含まれます。
この観点は、月次チェックリストに入れます。そのうえで、SBOM、依存関係スキャン、署名を段階的に整えます。
再現可能なビルドと脆弱性修正期限も、整備の対象にします。加えて、遅いテストや不安定な外部サービスも改善します。
Drone CIのシステムの費用相場とコストの内訳
Drone CIの費用には、ライセンス、設計・構築、実行基盤を含めます。さらに、Runner、DB、ログの費用がかかります。バックアップと監視の費用も、必要になります。
移行や保守も、費用の対象に含めます。ここで示す金額は、Droneの定価ではありません。
金額は、リサーチノートの人月単価と一般的な導入工数を、CI/CD基盤の構築に当てはめた推定です。実際の金額は、会社規模やリポジトリ数で変わります。さらに、Kubernetesや監査要件、24時間運用の有無にも左右されます。
規模別の初期費用と期間の目安
小規模PoCやOSSのセルフホストは、初期費用50万〜150万円程度、期間2〜6週間程度が目安です。一方で、中規模の本番導入は、初期費用150万〜500万円程度、期間2〜4か月程度が目安です。費用と期間の差は、規模ごとに組み込む構成の違いによるものです。区分ごとに何を含めるかは、下の箇条書きで確かめられます。
- 小規模：1〜5リポジトリ、Docker Runner、ビルド・テスト、通知、最低限のバックアップ。
- 中規模：10〜50リポジトリ、複数Runner、レジストリ、Secrets、監視、ステージング連携、権限設計。
- 大規模・複数部門：Kubernetes、SSO・RBAC、承認ゲート、監査ログ、DR、既存CI移行、24時間運用。
小規模のインフラ費は月1万〜10万円程度、保守は月5万〜20万円程度です。既存のクラウド基盤を使えるかどうかで、この額は変わります。
中規模のインフラ費は月5万〜30万円程度、保守は月15万〜50万円程度と仮置きします。大規模・複数部門の構成では、初期費用が500万〜1,500万円以上、期間が4〜9か月以上になる可能性があります。
公式価格は、別枠で確認します。Drone CI Essentialsは、年払いで月額300ドルと表示しています。開発者100人以上の場合は、ボリューム価格の問い合わせが必要です（出典: Drone CI Essentials公式料金ページ、2026年8月確認）。
Enterprise FAQには、月額299ドルからの入口価格、最大5,000ビルドの無料トライアル、年商100万ドル未満の組織向け条件があります（出典: Drone公式Enterprise FAQ、2026年8月確認）。
ページによって、表示や適用条件は異なります。そのため、円換算や契約期間だけで判断しないようにします。
見積書では、エディションと開発者数を確かめます。加えて、ビルド上限とサポート範囲も確かめます。
見落としやすいランニングコスト
OSSやCommunityでも、ソフトウェア以外に運用費がかかります。見積もりでは、主な費用と、その前提条件を分けて確かめます。
- 実行基盤：Server・RunnerのVMやコンテナ、DB、ストレージ、レジストリ。
- 運用環境：ログ、監視、バックアップ、通信費。
- 保守対応：脆弱性対応、更新、障害対応の担当者。
- 契約範囲：設定変更、一次対応、増設、Secrets更新、復旧訓練。
Runnerの同時実行数を増やすと待ち時間は減りますが、CPU・メモリ・ストレージ費と監視対象は増えます。
保守運用費は、初期構築費の年15〜25％が目安です。ただし、24時間365日の監視や厳格なSLAを含む固定価格ではありません。
後から本番承認や監査ログを追加すると、初期見積もりが1.3〜1.5倍に膨らむおそれがあります。そのため、非機能要件は先に決めておきます。
Drone CIのシステムの見積もりを取る際のポイント
見積もりでは、「Drone CIを導入したい」という要望を、対象範囲と性能、安全性、運用体制に分けます。価格だけで比べると、含まれる範囲が会社ごとに違い、比較できないためです。
たとえば、A社はPoCだけ、B社は本番監視まで、C社は移行や教育まで含む場合があります。各社には、同じ前提条件を渡します。
そのうえで、初期費用と月額費用を分けて提示してもらいます。オプション、除外事項、追加変更の単価も、別に示してもらいます。
RFPの対象範囲と受入条件
RFPには、要件を次の3つの分類に分けて書きます。
- 対象と性能：リポジトリ、移行対象、Git、言語、ビルド時間、同時実行数。
- 基盤と保存：Runner、実行環境、デプロイ先、レジストリ、ログ・成果物の保存期間。
- 統制と支援：環境分離、SSO・RBAC、Secrets、閉域網、バックアップ、監査、スキャン、SBOM、サポート時間。
環境は、開発・ステージング・本番に分けます。そのうえで、承認者とSecretsの保管先を明記します。ネットワークの制約や復旧目標時間も、同じRFPに書いておきます。
受入条件は、実際のリポジトリで試せるシナリオで書きます。画面説明や設定ファイルを納めるだけでは、運用開始後の品質は保証しきれません。
たとえば、Pull Requestから本番の資格情報を取り出せないこと、mainへのマージ後にステージングへ自動デプロイされることを確かめます。
本番は、承認後だけ実行されることを確かめます。加えて、stepログの追跡と、バックアップからの指定時間内の復元も確認します。
発注先の比較：Droneの直接経験と運用力
開発会社は、「CI/CDに対応できます」という説明だけでなく、経験で比べます。Droneの構築、Jenkinsなどからの移行、Docker・Kubernetesの設計経験を確かめます。
- セキュリティ：Secrets、SSO、監査ログの実装経験。
- 環境対応：閉域網やオンプレミスへの対応力。
- 運用と引き渡し：障害時の一次対応と、設計書・IaC・
.drone.ymlの引き渡し条件。
公開事例があれば、対象規模と担当範囲、成果の前提条件を尋ねます。公表された数字を、自社でも同じ効果が出る保証とは扱わないようにします。
提案を比べるときは、同じ表で確かめます。表に並べるのは、Droneの直接実績、Harness移行、Kubernetes・Runnerです。さらに、マルチクラウドや閉域網、権限とSecretsも加えます。
監視・バックアップ、教育と文書、保守料金とSLAも比べます。
最安値だけで選ばないよう、PoCで失敗ケースまで検証します。本番後にどこまでを誰が受け持つかを説明できる会社なら、追加費用や運用停止のリスクを抑えやすくなります。
ScienceSoftの事例では、7人の開発チームがDrone CIを使いました。そのパイプラインは、AWS・Azure・Alibaba Cloud・GCPに対応し、最大1日100コミットを処理したと説明されています。さらに、各stepは、AWS上のDockerイメージで分離したとのことです（出典: ScienceSoft公開事例、2026年8月確認）。
Platform Engineersの事例では、JenkinsからDrone CIへ移行し、KubernetesのNamespaceで環境を分離しました。そのうえで、月次インフラ費用の約70％削減と、移行時のダウンタイムなしを成果として掲げています（出典: Platform Engineers公開事例、2026年8月確認）。
いずれも個別案件の公表値で、自社で同じ効果が保証される数字ではありません。見積もりでは、対象規模と前提条件を照合します。
Drone CIのシステムについてよくある質問
費用や製品の将来性は、利用人数や構成、既存CIの有無によって変わります。そのため、自社の要件に置き換えて判断します。
Drone CIは無料で導入できますか？
Open Source Editionを使える場合も、費用はかかります。サーバー、Runner、DBの費用に加えて、ログや監視の費用も発生します。バックアップや保守にも、費用がかかります。
商用利用では、EnterpriseやHarness側の契約条件も確認します。そのうえで、小規模PoCで構築費と実行基盤費を分けて試算します。本番の保守体制も含めたTCOで判断します。
2026年時点でDrone CIを新規採用しても問題ありませんか？
現行のDroneを長く使うか、Harness Open SourceやHarness CIへ移行するかを含めて判断します。Harness公式は、Droneとの関係と移行方針を案内しています。
契約の前に、サポート対象のバージョンとライセンスを確認します。移行支援や、オンプレミス・セルフホストの可否も確かめます。また、設定はコード化し、製品固有の拡張に依存し過ぎない設計にします。
社内にDockerやKubernetesの担当者がいなくても導入できますか？
導入は、外部会社へ依頼できます。ただし、稼働後のRunner、Secrets、アップデートを誰が管理するかは、社内で決めます。失敗したビルドへの対応も、担当者を決めておきます。
Docker Runnerの小規模構成から始め、標準テンプレートとRunbookを引き継ぎ、定例レビューで担当者を育成する方法があります。Kubernetesや24時間運用が必要な場合は、継続保守も契約に含めます。
Jenkinsなどの既存CIから移行するときに何を確認しますか？
まず、パイプライン定義とプラグイン、Secretsを洗い出します。次に、成果物と履歴、Webhookを確認します。通知先とデプロイ先の依存関係も押さえます。
低リスクのリポジトリを選び、旧CIとDroneを並行稼働させます。そのうえで、ビルド結果と実行時間、イメージ内容を比べます。さらに、権限とログも確かめます。
移行完了の条件と旧CIの停止日を合意します。ロールバックの方法と、履歴を参照専用で残す期間も決めておきます。移行の完了後は、対象を段階的に増やします。
まとめ
Drone CIの導入は、要件整理、製品選定、設計・開発の順に進める基盤づくりです。さらに、テスト、稼働、定着まで含めた6フェーズで進めます。ServerやRunnerの構築は、その一部です。
OSSのライセンス料だけでなく、実行基盤やSecretsも見積もりに含めます。さらに、監視とバックアップも加えます。移行と保守まで含めたTCOで、全体を見積もります。
導入前に確認する最終チェックリスト
導入前には、対象リポジトリとKPI、DroneまたはHarnessのエディションを確認します。そのうえで、Runnerとネットワーク、環境別権限、Secretsと本番承認を確かめます。
ログ・成果物の保存期間や、バックアップと復旧の方法を決めます。脆弱性スキャン、旧CIからの移行範囲、稼働後の担当者も決めます。RFPと受入条件に記載します。
PoCでは、正常系だけでなく、失敗や再実行、復旧まで検証します。そうすると、発注後の認識違いを減らせます。
小さなPoCからの始め方
まずは1〜3リポジトリで試し、全社の本番デプロイは一度に移さないようにします。確かめるのは、Webhookの受け取り、ビルドとテスト、通知です。さらに、成果物保存と失敗時の再実行も見ます。
PoCの結果を踏まえて、本番の要件と費用を調整します。そのうえで、段階移行と定着運用へ進みます。開発者の負担を減らし、リリース品質を高めるための、現実的な進め方です。
▼全体ガイドの記事
・Drone CIのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。