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

Screwdriverの発注は、対象範囲を分けて整理し、PoCで適合性を確かめ、RFPと契約条件を整えてから本番構築へ移る流れです。

発注形態の選び方、要件整理と契約、費用相場、委託先の選び方を順に説明します。全体像は、Screwdriverのシステム開発の完全ガイドもご覧ください。

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

Screwdriverのシステムを発注する全体像

見積対象を3つの層に分けて把握できます。

Screwdriverは、OSSを入れるだけで発注が終わる仕組みではありません。

Screwdriver Guide「What is Screwdriver?」（2026年8月確認）では、Pipeline as Code、複数の実行エンジン、SCM連携を組み合わせたサービス群として説明されています。

Screwdriverは、Pull Requestから本番環境までの流れを定義する仕組みです。

発注対象を分けておくと、見積漏れと責任範囲の曖昧さを抑えられます。

発注範囲の切り分け：本体と周辺基盤

見積対象は、本体、連携・実行、周辺基盤の3つの層に分けて洗い出します。

本体：Screwdriver API、Web UI、Launcher、Store、Queueなどが連携して、サービス群を構成する部分
連携・実行：GitHubやGitLabなどのSCM、Pipeline定義、ビルド実行エンジン
周辺基盤：レジストリ、ログ・監視、Secret管理、バックアップ

公式AWS例は、KubernetesでAPIを動かし、PostgreSQLを使います。

本体の設定と、Kubernetes・DB・ネットワーク・レジストリの構築費は、分けて見積もります。

既存CIから移行する場合は、Pipeline数、プラグイン、ビルドイメージ、成果物・デプロイ先、Secretを洗い出します。

新規構築分は、RFPに分けて記載します。

複数チームの標準化が必要かどうかの判断

複数チームで標準化するのか、単一リポジトリ向けのマネージドCIで足りるのかを、まず見極めます。

標準化：複数リポジトリやチームのPipelineを共通化する場合に適します
設定管理：screwdriver.yamlをコードと同じ場所でレビュー・履歴管理できる点
実行環境：Kubernetes、Jenkins、Nomadをプラグインで使い分けられ、たとえばGoはKubernetes、iOSはJenkinsでビルドできます
小規模利用：単一リポジトリであれば、GitHub Actionsを短期間で導入できる可能性があります
導入判断：現状の指標と改善項目を決め、OSSを採用する理由や課題を共有する

現状指標には、リードタイム、デプロイ頻度、変更失敗率を記録します。さらに、復旧時間と手作業時間も記録します。

IPA調査は、国内企業のソフトウェア活用やOSS活用を対象としたもので、2026年2月9日時点で362件の回答を集計しました（出典：IPA「2025年度ソフトウェア動向調査」、2026年5月更新）。

ポイント

発注範囲は本体、連携・実行、周辺基盤に分けて見積もります。既存CIからの移行が必要か、複数チームの標準化が目的かで、段階導入の進め方を決めます。

Screwdriverの発注形態の選び方

小さな検証から既存環境の活用まで選択肢を見渡せます。

発注形態は、内製、クラウド・Kubernetes支援、ハイブリッドから選びます。

扱いやすいのは、小さなPoCで保守範囲と障害時の担当を見極めてから、本番構築・移行へ進む段階導入です。

小さく検証する場合の内製寄りPoC

社内にKubernetes、コンテナ、Git、セキュリティ運用の経験者がいれば、PoCを内製できます。その場合は、公式のローカル構成やSD-in-a-Boxを使い、1リポジトリの現行CIと比較します。

確認する流れ：Pull Requestのテスト、commit後のビルド
確かめる機能：成果物作成、後続Jobの起動、失敗Jobの再実行
把握する点：screwdriver.yaml、実行エンジン、ログ、Secretの安全な受け渡し

PoCで目指すのは、本番化よりも、設定や実行環境、ログ、Secretの扱いを把握することです。委託する場合も、対象は1リポジトリ、1実行エンジン、1デプロイ先に絞ります。

成果物には、構成図、設定ファイル、検証結果を含めます。さらに、未解決事項、本番費用の概算、社内で必要なスキル一覧も残します。ただし、PoCの内容がそのまま本番へ自動で移行できるとは限りません。

本番設計は別見積にするか、PoC契約に本番移行時の再利用条件を明記するかを決めます。

本番基盤まで任せる場合のクラウド導入支援

クラスタ構築を担う人員が足りない場合は、本番環境と運用支援を依頼します。

配置先：AWS、Azure、GCP、オンプレミスのいずれか
基盤：ネットワーク、KubernetesまたはVM、DB、認証、レジストリを含む
運用：ログ、監視、バックアップ、脆弱性対応も依頼範囲に含める
障害訓練：API停止、Queue滞留、Pod起動失敗、データストア復旧を扱う
保守条件：営業時間、一次回答、重大障害連絡、定期保守通知の取り決め

公式のKubernetes構成では、Kubernetes、GitHub、PostgreSQLが前提です。さらに、各種Secretも前提に入ります（出典：Screwdriver Guide「Setting Up a Screwdriver Cluster on AWS using Kubernetes」、2026年8月確認）。

本体の設定だけでは本番作業が残るため、運用手順と障害対応訓練も依頼に含めます。一次切り分けから復旧・再発防止までの手順を残します。そのうえで、24時間対応が必要かどうかに応じて保守時間を定めます。

既存Jenkinsや実行環境を活かすハイブリッド型

既存のExecutorを活かしながら、ScrewdriverをPipelineの管理とデリバリーの共通基盤にできます。

活用条件：Jenkins実行ファームや社内ビルドサーバーがあること
連携上の差：認証、ログ、成果物の保存先、失敗時の再実行方法の違い
責任分界：Screwdriver、既存CI、境界で起きた障害のそれぞれの担当をRFPに記載する
担当例：Pipelineテンプレートと権限はScrewdriver側が受け持つ
既存側の例：ビルドノードのパッチやiOS署名環境の担当

プロジェクトごとにExecutorを選べます。

境界の責任を明確にしておくと、複数社への重複した問い合わせを避けられます。

ポイント

発注形態は、小さなPoCで保守範囲と障害時の担当を見極めてから決めます。既存のJenkinsや実行環境を活かせるかどうかで、ハイブリッド型が合うかも判断します。

RFPと要件整理で決めておく項目

要件を工程ごとに確認する見取り図です。

RFPでは製品名だけでなく、対象リポジトリ、実行頻度、デプロイ先を伝えます。さらに、承認方法も書きます。

RFPには、現状、目的、対象範囲を分けて記載します。非機能要件、納品物、日程も、それぞれ項目を立てて書きます。見積条件と質問事項も、別の項目にします。

現状と目的の数字と対象範囲の書き方

現状欄には、リポジトリ数、主要言語、ビルド時間を記載します。さらに、デプロイ頻度、対象環境、利用中のCIも書きます。最後に、年間障害件数、手作業の工程、現在の担当者も記載します。

たとえば、50リポジトリのPRテスト、mainマージ後のステージング反映、本番承認を標準化します。

目的には、デプロイ頻度だけでなく、運用上の成果も含めます。

Secret保護：本番SecretをPull Requestに公開しないこと
成果物管理：同じArtifactを環境をまたいで昇格させる
復旧：障害時に前回の成功版へ戻せること

目標値は導入前に測れる範囲で設定し、現状のリードタイムや変更失敗率と比べます。

Pipelineの一連の流れで整理する機能要件

SCMから本番反映までの要件は、次の観点で受託側に示します。

起動条件：SCMの種類と認証、Webhook、PR・commit・tag・releaseの扱い
Job制御：依存関係、並列実行、再実行、手動承認
成果物と配備：Artifactの保存・昇格、デプロイ先、ロールバック
運用機能：通知、API、テンプレート、yamlのレビュー担当
権限：本番Jobを起動できるブランチを定める

Pipeline数とJob数は、分けて記載します。10リポジトリでも、各リポジトリにテスト・ビルド・ステージング・本番・脆弱性スキャン・通知のJobがあれば、設計と試験の対象は大きくなります。

共通処理をテンプレート化するか個別に定義するかを決めます。また、更新を既存のPipelineに反映する方法も決めておきます。

発注前に明文化する非機能要件とセキュリティ

性能や可用性、保存の条件を、RFPに明記します。さらに、Secretと委託先管理の条件も含めます。

性能・保存：同時実行数、待ち時間、ログ・Artifact保持期間
復旧・監視：バックアップ頻度、復旧目標、監視対象、保守時間
基盤条件：可用性、ネットワーク制限、保存地域、Namespace、ノード・Pod上限
Secret管理：本番・検証・PR用の値を分けたうえで、登録・更新・削除の権限を決めておく
委託先管理：アクセス、再委託、国外保管、監査、事故報告、返却・消去

ログやArtifactへの出力と、漏えい時のローテーションは、RFPと受入試験に含めます。また、全社基盤では、テナント間の影響と、クラスタ障害時の代替手段も確認します。

Secretは暗号化して保存されますが、Jobには環境変数で渡されます（出典：Screwdriver Guide「Build Secrets」、2026年8月確認）。

PR Jobへの公開を許可するallowInPRは、既定値がfalseです。

コード、YAML、IaCに個人情報や機密情報があれば、委託先のアクセス範囲を決めます。ログ、Artifact、手順書に含まれる場合も、対象に入れます。

個人データを委託する場合は、委託先の選定、契約、取扱状況の把握を通じた監督が示されています（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年8月確認）。こうしたセキュリティ要件は、RFPと契約に反映します。

ポイント

RFPには、現状の数字や対象範囲、機能要件、非機能要件を、発注前に書ける範囲まで具体化します。書けない項目は質問事項に回し、各社の見積前提をそろえます。

契約形態と納品物の設計

上流の要件整理は準委任、成果物が明確な構築は請負、稼働後は月次準委任か保守契約に分けて考えます。

要件整理・構築・運用ごとの契約の分け方

工程ごとに、契約と成果物、運用条件を分けて定めておきます。

要件整理・準委任：稼働時間に加え、調査報告、構成案、RFP、リスク一覧、PoC計画、要件定義書を指定
構築・請負：テスト、Artifact、ステージング、本番承認、ロールバックを受入条件にする
運用・保守：障害、更新、脆弱性、証明書、Secret、ログ容量を対象にするか決める
継続運用：テンプレート変更、クラウド費レビュー、作業上限、月次報告、定例会を定める
追加・緊急対応：追加単価と緊急時の扱いを契約に記載する

実際の契約条件は案件ごとに異なるため、法務・専門家の確認を受けて決定します。

納品物と権利・引き継ぎ範囲の明確化

構築物の引き継ぎに必要な資料と、権利・データの条件は、契約で定めます。

構成資料：構成図、ネットワーク図、アカウント・権限一覧
設定・運用：screwdriver.yamlのテンプレート、Infrastructure as Code、環境変数一覧、Secret登録手順
保管・復旧：Artifact保存方針、監視設定、バックアップ・復旧手順
検証・教育：テスト結果、運用マニュアル、教育資料
Secret：値そのものは渡さず、登録・更新方法を引き継ぐ

ソースや設定、カスタムプラグインの所有権を確認します。さらに、文書、ログ、Artifactの所有権も確認します。また、OSS・第三者ライセンス、再委託、契約終了時のデータ返却・削除も定めます。

Screwdriver本体に利用料がなくても、支援会社の知財やクラウド料金は別です（出典：Screwdriver Guide「Support」、2026年8月確認）。このため、全体の費用と権利範囲も分けて確認します。

実際のPipelineと障害時の動作による受入条件

正常時と障害時の両方を実際に動かし、次の受入条件を確認します。

デリバリー：指定リポジトリでのPRテスト、ビルド、Artifact、ステージング、本番承認
復旧：失敗Jobの再実行、前回成功版へのロールバック
権限：Guest、Collaborator、AdminのPipeline・ログ・Artifact・Secretへのアクセス
障害想定：Webhook未達、Queue遅延、ノード不足、イメージ取得失敗、DB接続障害
運用対応：Artifact保存失敗、Secret期限切れ、監視通知不達の検知から再発防止まで

各ケースでは、一次対応と復旧の担当を定めます。さらに、委託先への連絡、再実行、利用者への報告も担当を決めます。

受入条件を数値と操作手順で書いておくと、請負契約の検収判断がぶれにくくなります。

Screwdriverのシステム発注費用相場と内訳

Screwdriverの公式ライセンス価格や国内標準導入価格は公開されていません。ここからの金額は、公開されているDevOps・Kubernetes事例と構築範囲をもとにした、2026年時点の予算仮説です。

金額は、クラウド費やPipeline移行、アプリ改修で変わります。さらに、24時間監視の有無でも変わるため、個別に見積を取ります。

PoCの費用の仮置き：0万〜100万円程度

範囲を絞ったPoCは、社内工数が中心であれば、現金支出を抑えられます。

検証範囲：Dockerなどで、1リポジトリ、1種類の環境、サンプルPipelineを動かす
確認内容：基本的なログ確認まで
外部委託費：0万〜100万円程度を仮置き
期間：1〜4週間程度を起点とする
見積条件：ヒアリング、シナリオ、成功条件、結果報告、本番課題の整理を確認する

この金額は公式価格ではなく、対象を限定した検証作業の推定です。なお、冗長化や全件移行まで含めると、目的がぼやけ、短期間の費用比較が難しくなります。

小規模本番の費用比較レンジ：300万〜600万円程度

構築範囲に応じて、次の仮説を比較の目安として使います。

小規模本番：300万〜600万円程度。クラウドまたは既存Kubernetes、SCM、数個のPipeline、Secretを想定
標準基盤：600万〜1,200万円程度。旧CI移行に加え、複数チーム用テンプレート、Build Cluster分離、Artifact、権限設計を含む
参考価格：Kubernetes構築・設定代行は税抜2,772,000円の公開例がある

小規模構築には、ログや基本監視、運用手順も含みます。この金額は、類似のDevOps事例からの推定で、Screwdriverの定価ではありません。

公開例は、要件定義、設計構築、マニフェストを含みます。さらに、CI/CD設定も含まれます。一方で、クラウド費・テスト・監視・アプリ作業は別です（出典：株式会社アールワークス「Kubernetesを導入して、アプリデプロイやインフラ運用を自動化したい」、2026年8月確認）。

このため、本体、実行基盤、Pipeline移行、監視・保守は分けて見て、一つの金額だけで判断しないようにします。

全社基盤の費用：1,500万円以上となる可能性

高信頼性や移行規模、運用条件に応じて、初期費とランニング費を見積もります。

全社基盤：1,500万円以上、6〜12か月以上となる可能性があります
想定範囲：複数クラスタ・リージョン、大量移行、監査ログ、DR、SLA、24時間対応、内製研修
主な工数：全社標準化、権限・承認、Pipelineの洗い出し、移行試験、運用引き継ぎ
小規模の月額：ノード、ビルド時間、レジストリ、ログ、バックアップ、保守を含め月5万〜30万円程度を仮置き
中規模以上の月額：月30万〜150万円以上を仮置き。初期費用の15〜25％を年間保守の目安とする考え方もあります

月額は、同時実行数やログ保持期間、ビルド負荷で変わります。さらに、監視時間帯によっても変わります。

年間保守率は一般的な業務システムの参考値なので、契約内容に応じて確認します。

ポイント

費用は、PoC、小規模本番、全社基盤のどこを対象にするかで大きく変わります。金額は公式価格ではないので、同じ条件で個別見積を取り、本体・実行基盤・移行・保守を分けて比べます。

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

公式の認定会社が公開されているとは限らないため、直接の実績と隣接技術の実装力を分けて評価します。事例が少ない場合でも、その点は隠さず示してもらいます。そのうえで、担当範囲やExecutorの経験、OSSの更新や脆弱性対応も確認します。

直接実績と隣接技術の経験の切り分け

担当者の経験は、Screwdriverの直接実績と周辺技術の運用力に分けて確認します。

直接実績：バージョン、規模、SCM、Executor、データストア、Pipeline数
運用実績：期間、担当範囲、障害対応、保守体制
公開できない事例：匿名の構成図、課題、受入条件を確認する
隣接技術：Kubernetes、Docker、Jenkins、SCM連携、TerraformなどのIaC
運用管理：Secret、ログ・監視、DevSecOps、OSSライセンス管理

「対応できます」という説明からは、サービス群への理解度を判断しにくいです。Screwdriverの経験が浅くても、周辺技術の本番経験があれば候補になります。ただし、固有の設定や制約はPoCで確かめ、提案書では推測と確認済みの事項を分けて書いてもらいます。

作業項目と前提条件の粒度をそろえた見積書の比較

各社の作業項目と見積の前提は、同じ粒度にそろえて比べます。

作業項目：要件整理、基本設計、クラスタ、本体、SCM、Executor、Pipeline移行
運用項目：Secret、監視、バックアップ、テスト、教育、保守
規模・条件：リポジトリ、Pipeline、Job、実行環境、環境、保持期間、同時実行数
費用条件：クラウド・ライセンス、交通費、税、追加単価
比較方法：前提差は基本・オプション案に分け、納期や保守も含めて判断する

一式見積では、移行や監視が別請求になる可能性があります。そのため、社内の分担や納品物、契約期間も含めた総保有コストで判断します。

提案時に確認する5つの質問

提案時は、実績とExecutorについて質問します。さらに、Secretや移行、引き継ぎについても聞きます。

実績：直接実績と担当者の実装範囲
Executor：対象に合わせた選択理由
Secret：PRでの本番値保護と漏えい時のローテーション
移行：既存CI、並行期間、失敗時の切り戻し
引き継ぎ：契約終了後の納品、教育、自社運用

回答に構成図やyaml例、テスト計画があるかを確認します。さらに、障害対応フローや月次報告例も見ます。また、不明点を提案時に質問する会社は、発注後も前提を管理しやすい傾向があります。

現状確認をせずに固定額と短納期を出してくる場合は、追加費用と責任分界を慎重に見ます。

ポイント

委託先は、直接実績と隣接技術の経験を分けて評価します。見積は、作業項目と前提条件をそろえて比べ、提案時の質問にどう答えるかも見ます。

よくある質問（FAQ）

発注前に混同しやすい疑問に答えます。対象は、OSS利用料や導入費、クラウド費、保守費、委託先実績などです。

Screwdriverは無料で導入できますか？

Screwdriver本体はOSSですが、無料で本番運用できるとは限りません。KubernetesやVM、DB、ビルドノードに加え、レジストリ、ログ、監視、バックアップにも費用がかかります。

構築、移行、保守にも費用が発生します。そのため、ライセンス費と全体運用費を分けて予算化します。

Screwdriverを使える開発会社はどのように探しますか？

候補会社は、実績と提案内容を具体的な成果物で比べます。

経験：直接実績、Kubernetes、CI/CD、DevSecOps、OSS運用
周辺実績：Secret管理、Jenkins移行
PoC提案：公式文書に基づく検証を複数社で比べる
体制：担当者の実装経験、保守、引き継ぎ範囲
確認材料：口頭回答でなく、サンプルPipelineと受入条件

Pull RequestでSecretが漏れる心配はありませんか？

PR JobでSecretの公開を許可するallowInPRの既定値はfalseです。ただし、運用面の対策も必要です。

PR用の値：本番Secretではなく非機密値か一時認証情報を使う
アクセス：Secretの登録権限を確認する
漏えい防止：環境変数・ログへの出力やArtifact混入を確認する
事故対応：失効・再発行を受入試験と運用手順に含める

既存JenkinsやGitHub Actionsから移行できますか？

移行できる可能性はありますが、対象機能と小規模な並行稼働を確認しながら進めます。

事前確認：構文、実行環境、権限、Secret、Artifact、通知、承認、デプロイ方式
試行範囲：依存の少ない1チームまたは数リポジトリ
並行稼働の評価：成功率、待ち時間、運用負荷、切り戻し方法

まとめ

発注時は、OSS本体に加えて、SCMやPipeline、Executorを要件に含めます。さらに、実行基盤やSecret、Artifactも要件として整理します。また、監視・バックアップ・移行・保守も含め、継続的デリバリー基盤として設計します。

複数チームの標準化が目的であれば、内製PoCで適合性を確かめてから、クラウド支援またはハイブリッド型で本番化する段階導入が現実的です。

発注前に確認する項目

発注前に、RFPと見積の対象・条件をそろえておきます。

対象：リポジトリ、Pipeline、Job、SCM、Executor、環境、同時実行数
運用・統制：Artifact・ログ保持、Secret、権限、監査
契約条件：移行、受入、納品物、保守時間
見積比較：構築、移行、テスト、教育、クラウド費、監視、保守を分ける

前提条件と追加費用の扱いが各社で同じかどうかを確かめてから、比べます。

最初の一歩：小さなPoCと同条件の相見積もり

全社移行を先に決めず、PoCから相見積もりまで段階的に進めます。

重要度の低い1サービスでPoCを行う。
PRテスト、Artifact作成、ステージング反映、承認、ロールバックを検証する。
結果と現状KPIをRFPに反映し、直接・隣接実績を持つ複数社へ同条件で依頼する。
費用だけでなく、運用引き継ぎと障害復旧体制を確かめて発注する。

自社で運用を引き継ぎ、障害時に復旧できる体制があると、長期的な成功につながります。

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

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