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

CircleCIの発注は、現状を調べ、要件と検収条件を決め、契約形態と委託先を選ぶ順に進めます。この順に進めると、運用できるCI/CD基盤につながります。

発注形態からRFP、契約、費用、委託先の選び方まで、見出しごとに説明します。全体像はCircleCIのシステム開発の完全ガイドもご覧ください。

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

CircleCIのシステムを発注・外注する前に知っておきたい全体像

CircleCIの発注範囲を、導入・基盤整備・移行確認・引き継ぎの4領域で示した図。
設定作業から運用の引き継ぎまで、依頼内容を分けて確認できます。

CircleCIの発注範囲は、初期設定から開発プロセス全体の再設計まで選べます。ただし、範囲が曖昧なままだと、本番承認や失敗時の復旧が決まらず、追加費用が生じることがあります。

CircleCIが自動化する範囲

CircleCIは、ソースコードの変更を起点に、ビルド、テスト、成果物の作成、デプロイを自動化するCI/CD基盤です。

ECサイトや業務システムそのものを作る製品ではありません。

GitHubやBitbucketへのpushやPull Requestを受けると、CircleCIは定義済みの処理を実行します。その処理は、主に次の要素で定義されます。

  • job:個々の処理をまとめる単位
  • workflow:jobの順序や条件を管理する単位
  • 設定ファイル:.circleci/config.ymlに処理内容を記述
  • 実行例:Pull Request時にlintと単体テストを行い、マージ後にDockerイメージを作成してstagingへ配布

EC事業では、画面、商品・在庫・受注API、管理画面を複数のリポジトリで管理する場合があります。また、モバイルアプリも複数のリポジトリで管理することがあります。

複数のリポジトリを管理する場合は、共通テストや環境変数を標準化し、承認ルールと通知先も揃えます。

発注時は、「CircleCIを導入したい」と伝えるだけでなく、どの変更を、どの環境で、どの条件ならリリースできるかまで伝えます。

設定作業から運用設計までの発注範囲

外注する範囲は、初期設定から運用の引き継ぎまで選べます。作業は、次のように分けて整理します。

  • 導入:調査、方針設計、CircleCI設定、Dockerや実行環境の整備
  • 基盤整備:テスト自動化、デプロイ、権限設定
  • 移行確認:JenkinsやGitHub Actionsから移す場合、ジョブ時間、失敗率、キャッシュ、認証方式、成果物の保管場所
  • 引き継ぎ:文書、構成図、権限一覧、障害・変更手順、月次利用料の確認方法

本番環境では、stagingまでを自動化して、productionには承認者を置く方法があります。また、失敗時の復旧方法や、実行ログと承認履歴の保存方法も決めておきます。

納品物には、設定ファイルも含めます。

CircleCIの発注形態の選び方

発注形態は、内製と外注に大きく分けられます。

外注には、部分委託のほか、一括請負や準委任の伴走型があります。

選ぶときは、社内の経験、既存システムの複雑さ、リリース頻度を見ます。さらに、セキュリティ要件と、導入後の運用担当も確認します。

価格だけで決めると、内製できない範囲が残ったり、外注先への依存が続いたりします。そのため、将来の運用体制も含めて選びます。

内製で進める場合が向いている企業

アプリ開発とインフラ運用の担当者がいて、テストコードやデプロイ手順も整っている企業は、内製を基本にできます。

  • 外部相談:必要な部分だけ相談すると、費用を抑えながら、設定の意図を社内に残せます
  • 外部レビュー:最初の設計やセキュリティレビューだけを外注する方法もあります
  • パイロット:代表的な1〜2サービスで社内担当者が設定変更と障害対応を経験してから広げると、外部依存を抑えたまま品質を保てます

全リポジトリを一度に対象にすると、YAML設計や権限、Docker、クラウド認証、障害の切り分けがまとめて必要になり、時間がかかります。

部分委託で設定・移行・レビューを切り出す方法

社内に開発チームはあるものの、CircleCIの設計や既存CIの移行経験が不足している場合は、部分委託が候補になります。このとき、外部会社に依頼する作業と、社内に残す役割を分けます。

  • 外部会社:現状分析、共通テンプレート、初期パイプライン、セキュリティ設定、レビュー、勉強会
  • 社内:日々のアプリ改修、テスト内容、リリース承認
  • 責任分界:導入会社は設定と構成書、社内はテスト内容とリリース判断を担う形などを明記

設定変更の申請者とレビュー者、承認者を決めるほか、障害時の一次窓口も決めておきます。というのも、役割が曖昧なままだと、問題が起きたときに対応者を判断できないからです。

一括請負や伴走型で任せる場合の注意点

複数リポジトリや環境を短期間で整える場合、また夜間リリースや既存CIの移行、監査要件を含む場合は、一括請負や準委任が候補になります。そのうえで、契約形態ごとの注意点を踏まえて完成条件を決めます。

  • 一括請負:成果物と納期を固定しやすい一方、契約後の要件追加には変更管理が必要
  • 準委任:調査しながら設計を深める案件に向くが、投入時間と役割を管理しないと費用が膨らむ
  • 完成条件:対象リポジトリの90%でテスト実行、productionデプロイ時の承認、失敗時に直前の成果物へ戻せること
  • 成果物:設定ファイル、テスト結果、構成図、運用手順、引き継ぎ記録

完成条件は、上記のように確認できる条件に変換して書きます。「CircleCIが使えること」のままでは、完成を確認できません。

ポイント

内製か外注かは、社内の開発と運用の担当者がどこまで受け持てるかで決めます。価格だけで選ぶと、内製できない範囲や外注先への依存が残るため、将来の運用体制まで含めて判断します。

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

RFPの要件整理項目として、移行対象・テストデータ・外部送信・委託先管理を並べた図。
データの扱いと委託先の管理も見積条件に含められます。

RFPでは、製品名を先に決めず、達成したい開発・運用上の成果と制約を示します。CircleCIがすでに決まっている場合でも、代替案や構成上の注意点を提案してもらうと、不要な高機能化を避けられます。

見積もりを比べるときは、必要な情報を揃えておきます。そうすると、価格差の理由を読み取れます。

現状把握で整理する項目

対象環境を把握するため、リポジトリ数や利用言語、フレームワーク、テストの有無を整理します。

実行状況は、1日あたりの実行回数と平均ジョブ時間、ピーク時の同時実行数を記録します。

連携先には、GitHubなどのVCSやDockerレジストリを記載します。デプロイ先にはAWS・Azure・Google Cloud・Kubernetesなどがあり、通知先にはSlackなどがあります。

  • 移行対象:JenkinsやGitHub Actionsのうち、移行する処理と継続利用する処理
  • テストデータ:注文、在庫、決済、配送、会員情報を扱うデータの所在
  • 外部送信:artifactの公開範囲と保持期間、外部SaaSへ送る情報
  • 委託先管理:安全管理措置、アクセス権限、再委託、事故時の報告期限

RFPには、本番データをfixtureやログへそのまま入れない条件も記載します。個人データを含む場合は、委託先の管理方法を確認します。

目標パイプラインと成功指標を定義する方法

パイプラインは、build、lint、単体テストから始めて、必要な工程へ段階的に広げます。失敗時の影響が大きい注文処理や在庫引当から回帰テストを整えると、効果を測りやすくなります。

  • テスト工程:結合テスト、脆弱性スキャン
  • リリース工程:stagingデプロイ、本番承認、productionデプロイ
  • 復旧工程:失敗時のロールバック
  • 品質指標:デプロイ頻度、変更リードタイム、失敗したデプロイの割合、復旧時間
  • 実行指標:テスト成功率、平均パイプライン時間、クレジット消費量

CircleCIは実行環境ごとにクレジット/分が異なります。そのため、不要な実行の削減、キャッシュの適正化、並列化による待ち時間の短縮を分けて評価します。

セキュリティとガバナンスの要件

secretは設定ファイルやコマンドラインへ直書きせず、Context、クラウド側のIAM、短期間だけ有効なOIDC認証などを使って、最小権限で扱います。

AIで生成したコードを含む場合は、テストに加えてSAST・SCAを行い、依存関係も固定します。

  • レビュー対象:forkからの実行、外部Orbs、Dockerイメージ、依存パッケージ
  • 生成コード:テスト、SAST・SCA、依存関係の固定、コードレビュー
  • 承認と追跡:コードレビューと承認、成果物の来歴確認を組み込む

CircleCIは、通信暗号化や環境変数の保護、監査ログなどを提供します。ただし、VCS権限やsecret設定まで自動で安全になるわけではありません。

製品機能と発注者・委託先の運用責任をRFPで分けておくと、提案内容を比べられます(出典: CircleCI公式Security overview・Audit logs、2026年8月確認)。

ポイント

RFPには、製品名より達成したい成果と制約を先に書き、移行対象や委託先管理まで示します。前提を揃えた見積もりは、価格差の理由を比べやすくなります。

CircleCIの外注における請負契約と準委任契約の使い分け

契約形態は、完成させる対象と要件の確かさで選びます。対象と検収条件を固定できる小規模な導入なら請負、調査しながら要件を決める複雑な移行なら準委任が候補になります。

法務上の判断は、個別の契約によって異なります。技術面では、成果物を納める契約と、専門人材の稼働を依頼する契約を区別します。

請負契約で固定する項目

請負契約では、完成物と検収に関する項目を具体的に書き出します。

  • 対象と納品:リポジトリ、環境、処理、テスト範囲、承認、デプロイ先、文書、検収日
  • 作業範囲の例:1〜3リポジトリでbuildと単体テストを実行し、stagingへのデプロイと構成書を納品
  • テスト範囲:テストコードがない場合、テスト自動化か既存テストの実行設定かを区別
  • 検収:secret権限、productionの承認、ログ確認、ロールバックを確認
  • 契約上の権利:Orbsや外部イメージのライセンス、著作権、成果物の利用権、終了後のアカウントとデータ

これらの条件は、契約書でも確認します。

準委任契約で管理する項目

準委任契約では、稼働条件と運用分担を明確にしておきます。

  • 稼働条件:月の稼働時間、役割、定例会の回数、調査・レビュー範囲、問い合わせ時間、成果物の有無
  • 月次報告:変更したjob、作業時間、課題、次月予定、クレジット消費量
  • 運用保守:障害の一次切り分け、CircleCI・クラウドの障害確認、設定変更、緊急ロールバック、事故連絡
  • 対応条件:24時間対応の要否、復旧目標時間、サービス料金と支援料金の請求区分

時間請求だけだと費用を予測しにくいため、月次報告で作業状況を把握します。

導入会社がCircleCI利用料を立て替える契約では、サービス料金と支援料金を分けて請求できるかを確認します。

委託時は、情報共有、再委託、データ管理の条件を確認します。

  • NDA:ソースコード、構成図、脆弱性情報、テストデータの共有時期と対象情報
  • 再委託:海外拠点やオフショアを含む場合の事前承認、作業場所、アクセス経路、端末管理、ログ保管、終了時の返却・消去
  • 個人データ:個人情報保護委員会の安全管理措置や委託先管理に沿い、社内の法務・情報システム部門と合意
  • 実行環境:CircleCI Cloud、self-hosted runner、CircleCI Serverごとのデータの流れと責任分界

self-hosted runnerは、自社マシンやKubernetesでジョブを実行でき、プライベートネットワークやIAM権限も使えます。

実行ホストの権限管理やOS更新は、利用企業側の責任になります(出典: CircleCI公式Self-hosted runner overview、2026年8月確認)。

ポイント

請負と準委任のどちらが合うかは、納品物と検収条件をどこまで固定できるかで判断します。固定できる小規模な導入は請負、要件を調べながら決める複雑な移行は準委任が候補になります。

CircleCIのシステム発注・外注費用の相場

導入規模別の初期費用の推定レンジを、小規模・中規模・大規模で比較した横棒図。
規模が大きくなるにつれて、見積もりの幅も広がります。

CircleCIの費用は、公式利用料と、導入会社の設計・設定・移行・運用費に分けて考えます。一つの月額にまとめてしまうと、利用量の増加と作業範囲の増加を区別できなくなります。

見積書では、初期費用とCircleCI利用料、クラウド費用を分けてもらいます。さらに、保守費と追加作業費も、別の項目として示してもらいます。

CircleCI公式利用料のクレジット制

プラン料金は、月額だけでなくクレジット量と、実行環境ごとの消費量も合わせて確認します。

  • Free:月額0ドル、最大6,000ビルド分、アクティブユーザー5名、30並行実行
  • Performance:月額15ドルから、30,000クレジット、アクティブユーザー5名
  • 追加クレジット:25,000単位で15ドル
  • Scale・Server:Scaleは年契約のカスタム料金、CircleCI Serverは個別見積もり

価格は税別で、為替や契約条件によって円換算額が変わります(出典: CircleCI公式料金ページ、2026年8月確認)。また、クレジット消費量は実行環境や機能によって異なります。

公式Price Listの2026年7月21日更新情報では、x86 DockerのSmallは5クレジット/分、Mediumは10クレジット/分です。この単価で単純計算すると、30,000クレジットはSmall約6,000分、Medium約3,000分に相当します。

実際の消費量は、Docker Layer Caching、ネットワーク、ストレージ、並列実行などの条件によって変わります。

導入・移行・開発費の推定レンジ

CircleCIは、日本の導入支援費を一律には公開していません。そのため、次の推定レンジは、類似するCI/CD・DevOps基盤の導入案件から整理したものです。

  • 小規模:1〜3リポジトリ、Docker build・単体テスト、基本的なsecret設定。30万〜100万円程度、1〜3週間が目安
  • 中規模:複数リポジトリ、staging・production、AWS等へのデプロイ、承認・通知、既存CI移行。100万〜300万円程度、1〜2か月が推定目安
  • 大規模:数十〜数百リポジトリ。300万〜1,000万円以上、2〜6か月となる可能性

大規模は、SSO、監査、ネットワーク分離、self-hosted runnerやCircleCI Server、高可用性を含む想定です。

テストコードやデプロイ先が未整備なら、小規模でも追加作業が生じます。各レンジは作業範囲と体制で変わるため、見積もりの前提と合わせて見ます。

運用保守費と総保有コストの見積もり

運用保守費と総保有コストは、対応範囲や実行環境を分けて見積もります。

  • 基本的な保守:設定変更、失敗調査、runner・イメージ更新、脆弱性対応、クレジット最適化、問い合わせ対応は月10万〜50万円程度を仮置きするケース
  • 広い支援範囲:24時間対応、大規模な内製化支援、複数クラウド、Server保守を含むと月50万〜200万円程度まで上がる可能性
  • 総額:初期費用、12か月分の利用料、runner・レジストリ・ストレージ費、保守費、追加テスト自動化費を合算
  • Cloud:インフラ管理の負担を減らしやすい一方、実行量が増えるとクレジットも増えます
  • self-hosted runner:実行環境を制御しやすい一方、自社のVM、Kubernetes、OS、ネットワーク、監視の運用費が必要です

保守費は、サポート時間、対象リポジトリ数、SLAで変わる推定値です。

ポイント

費用は、公式利用料と導入会社の作業費、運用保守費を分けて、12か月の総額で比べます。初期費用の推定レンジだけで判断せず、テスト自動化や既存CI移行の有無を前提として揃えます。

CircleCIの委託先選定と見積比較で確認すべきポイント

委託先には、CircleCIの設定だけでなく、業務システムへの理解が必要です。加えて、テストやクラウドの経験、セキュリティや運用設計への理解も求められます。

探すのは、CircleCIを開発する会社というより、CircleCIで自社のリリースプロセスを整える会社です。機能説明が詳しくても、障害対応や引き継ぎが不十分な場合は、慎重に評価します。

実績の見方:社名より対象環境と成果

CircleCIを使ったことがあるかだけでなく、対象環境と成果を同じ観点で確認します。

  • 対象環境:リポジトリ数、言語・フレームワーク、デプロイ先
  • 移行・テスト:Jenkinsからの移行、注文・在庫・決済の回帰テスト
  • 導入成果:失敗率やリリース時間がどう変わったか
  • 公開事例が少ない場合:匿名化した構成図、RFP回答、納品書の目次、運用手順の見本

クラスメソッドはCircleCIとのパートナー契約を公表し、AWSなどのクラウド、DevOps、SaaS導入を支援しています。SI&Cも2025年9月にResellerパートナーシップを公表しました。

これらは候補を探す際の参考になります。ただし、パートナーであることだけで、自社案件との適合性が証明されるわけではありません(出典: クラスメソッド公式発表、SI&C公式発表、2025年)。

見積書の比べ方:作業量と前提条件の揃え方

見積書は、作業量と前提条件を揃えて比べます。費目と対象範囲を並べて確認します。

  • 費目:現状調査、設計、設定、テスト、移行、文書、教育、保守
  • 対象条件:リポジトリ、job、workflow、環境、テストケース、同時実行、レビュー回数。範囲が不明な見積もりは追加費用が生じやすい
  • 支援内容:運用手順や内製化支援を含む場合、単価が高くても総額で有利なことがある
  • 構成案:同じRFPで最低限の構成と将来拡張を含む構成の2案を求める
  • 比較軸:初期費用、月額、運用負担、セキュリティ、拡張性

比較対象には、Cloud、self-hosted runner、CircleCI Server、Jenkins、GitHub Actionsがあります。

判断は、機能の多さよりも、必要なリリース品質を継続して保てるかで行います。

発注後のトラブルを防ぐ確認ポイント

発注時には、作業範囲や費用の行き違いを防ぎ、権限や納品物も確認しておきます。

  • テスト範囲:自動化を依頼しても、テストコードの作成が含まれない場合がある
  • 権限:委託先がproduction権限を保持したままになっていないか
  • 費用:Cloud利用料が見積もりの外になっていないか
  • 納品物:設定ファイルに加え、運用手順が含まれるか
  • 分担:発注者の準備物、委託先の準備物、第三者サービスへの支払いを分ける

新機能や料金体系が変わったときの扱いも、あらかじめ決めておきます。2026年時点では、AI開発支援、OCIコンテナ署名、OIDC認証、テスト高速化などが公式ブログで発信されています。

新機能は、すぐには採用せず、変更管理、検証環境、ロールバック、担当者レビューを経てから本番に反映する手順を定めます。

ポイント

委託先は、社名より自社に近い対象環境や移行・テストの実績で選びます。見積もりは作業量と前提条件を揃えて比べ、リリース品質を継続して保てるかを基準にします。

CircleCIのシステム発注・外注でよくある質問

CircleCIの外注では、製品料金、導入作業、運用責任を分けて確認します。発注前によくある疑問に、順に答えます。

CircleCIの導入費用と月額料金は別に考えるべきですか?

はい。CircleCIの料金は、プラン、クレジット、実行環境、追加機能によって変わります。一方で、導入費は、調査、設計、設定、移行、教育、保守の作業量で決まります。

見積書で利用料、クラウド費用、初期導入費、月次保守費、追加作業費を分けておくと、利用量が増えた場合の影響も確認できます。

既存のJenkinsやGitHub ActionsからCircleCIへ移行できますか?

移行は可能ですが、設定ファイルの書き換えだけで完了するとは限りません。なかでも、ジョブの依存関係と実行環境、secretは優先して確認します。そのほか、旧CIが担っていた処理が移行先でも同じように動くかを、項目ごとに確かめます。

  • キャッシュ
  • 成果物
  • 通知
  • 承認
  • デプロイ権限

代表的なサービスで並行稼働し、成功率、実行時間、復旧手順を確認してから、対象を段階的に広げます。

CircleCIの外注先は何を基準に選べばよいですか?

自社に近いリポジトリ構成やクラウド、テスト、セキュリティ、運用体制の経験を確認します。あわせて、担当者の経験や構成図、移行実績、障害対応、引き継ぎについても尋ねます。

再委託、SLA、見積もりの前提も確認します。資格や会社規模は参考程度にとどめ、課題を理解した提案と検収条件を重視します。

まとめ

CircleCIの発注は、設定作業ではなく、開発からリリースまでの仕組みを整える案件として考えます。社内体制と要件に応じて、内製や部分委託、一括請負、準委任の中から選びます。

RFPでは、リポジトリや実行回数、テスト、デプロイ先を具体化します。あわせて、権限やデータ、監査、ロールバックも具体的に書きます。

費用比較の観点:初期費用だけでなく総額で見る

費用は、公式クレジット料金、導入・移行費、クラウドやrunner費、保守費を分けて、12か月の総額で比べます。

初期費用の推定レンジは、小規模で30万〜100万円、中規模で100万〜300万円、大規模で300万〜1,000万円以上です。テスト自動化や既存CI移行、監査、ネットワーク分離の有無で変わるため、見積もりの根拠と前提を確認して選びます。

小さなパイロットと検収条件

全社のリポジトリを一度に移行せず、代表サービスでbuild、テスト、staging、本番承認、ロールバックを検証します。

その結果をもとにRFPを提示し、同じ前提で複数社の提案と見積もりを比べます。そのうえで、品質指標とクレジット消費を月次で見直せる状態にしておきます。

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

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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