Screwdriverのシステム開発の完全ガイド

Screwdriverは、リポジトリへの変更を起点にJobを実行し、作ったものを次の環境へ届ける継続的デリバリー基盤です。PipelineをコードとしてYAMLに書き、実行基盤と運用体制を整えると、複数チームの手順をそろえられます。

主要機能、構成の選び方、導入の進め方、費用の目安を説明します。

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

Screwdriverの概要

Screwdriverは、リポジトリへの変更をきっかけにJobを動かし、成果物を次の環境へ届ける継続的デリバリー基盤です。公式ガイドでは、Pipeline as Codeや複数の実行エンジン、Pull Requestから本番までの流れが中核とされています。

ERPや販売管理システムとの役割の違い

Screwdriverが管理するのは、ソースコードをどの環境へ、どの順番で、どのテストを通して届けるかです。顧客情報や受注、在庫などを扱う業務システムとは、役割が違います。

つまり、「Screwdriverで業務システムを作る」とは、業務システムの開発・テスト・リリースを支える基盤を構築することを指します。

向いているケース：複数チームのデリバリー標準化

複数のリポジトリや開発チームがあり、テストからリリース、ロールバックまでの手順をそろえたい組織が該当します。

各リポジトリの screwdriver.yaml をコードレビューの対象にできます。その結果、画面の設定を担当者だけが変えている状態から、履歴に基づく運用へ移れます。

単一リポジトリで数個のテストを早く動かすことが目的なら、運用管理の少ないマネージドCI/CDが候補になります。

ポイント

Screwdriverは、業務システムの開発とリリースを支える基盤です。複数のリポジトリや開発チームの手順をそろえたいかを、まず判断の基準にします。

全体像と主要機能

複数のサービスを組み合わせて全体を構成します。

Screwdriverは、一つの実行ファイルだけでは完結せず、API、Web UI、データストア、Queueを組み合わせて成り立っています。Launcher、Build Cluster、Artifact Storeも構成要素です。

各サービスが連携してコードの変更をJobの実行へ変換するため、構築時には、それぞれの役割と障害時の確認先を決めておく必要があります。

SCMからJob実行までの流れ

CommitやPull Request、Tagなどの操作をきっかけに、SCMからのWebhookがScrewdriver APIへ届きます。APIは対象のPipelineを特定し、実行エンジンへJobを投入します。

Launcherは指定された環境でコードを取得し、screwdriver.yaml に書かれたコマンドを実行します。完了した結果はAPIに通知され、後続のJobが依存していれば、次のJobへ進みます。

この流れは、公式のOverall Architectureにも示されています。

YAMLとWorkflowによる処理のコード化

screwdriver.yaml には、Job名やSteps、イメージを定義します。依存関係やSecret、トリガーなども、同じファイルに書きます。さらに、Workflowを使うと、イベントごとに処理を分けられます。

Pull Request：~pr でのテスト実行。
Commit：~commit でのビルド。
Tag・Release：~tag、~release で本番候補のArtifactを作成します。

requires を使うと、Jobの順序や並列実行を表せます。処理の内容がYAMLの差分として残るため、複雑な処理も変更の履歴で追えます。

Artifact・ログ・テンプレートの共通化

コンテナイメージやパッケージ、テストレポートなどはArtifactとして保存され、後続のJobや環境で使えます。ログやテスト結果も残しておけば、失敗原因の調査と監査の負担を減らせます。

複数のリポジトリで処理をそろえたい場合は、Pipeline TemplateやExternal Configが選択肢になります。

YAMLを一つに大きくまとめると変更の影響が見えにくくなるため、まずはチーム単位のテンプレートから始めるのが安全です。

構成の種類と技術選択肢

検証の始めやすさと本番運用の責任範囲が選択の目安です。

構成を選ぶときは、本体だけでなく、Jobの実行場所、Artifactの保存先、運用担当までを含めて考える必要があります。小規模な検証ならDocker、本番で同時実行数や可用性を求めるならKubernetesなどが候補になります。

Docker中心の小規模構成

1チームで数個のリポジトリを扱い、同時実行数も少ないなら、Dockerを実行環境にする構成が候補になります。構築要素が少ないため、PoCを早く始められます。

ホスト障害時にどう再実行するか、リソース上限をどこに置くかを先に決めておきます。Job分離、ログ保持、チーム間の優先順位も、導入前に定めておく必要があります。

検証用の構成をそのまま本番に広げないため、Kubernetesなどへ移る条件を事前に定めます。

Kubernetesを使う本番標準構成

本番では、APIやUIの基盤と、Buildを実行するClusterやNamespaceを分けて設計すると効果的です。公式ガイドには、Kubernetes上にScrewdriver Clusterを構築する手順もあります。

データストアとSecretを組み合わせ、SCM連携やコンテナ実行も加えます。スケールや権限分離は管理しやすくなります。一方で、Kubernetesの更新やネットワークの運用責任が増えます。費用、監視、バックアップも、運用の範囲として含める必要があります。

複数Executorを使うハイブリッド構成

ScrewdriverはExecutorを差し替えられます。公式の貢献先では、Docker、Kubernetes、Jenkinsなどの実装が整理されています。Nomadも、その一つとして挙げられています。

Jobの性質に応じて、実行先を分けることもできます。たとえば、通常のサーバーサイドのBuildはKubernetesで行い、特定のOSや専用環境が必要な処理は別のExecutorに任せられます。

Executorごとの違い：イメージ、権限、キャッシュ、ネットワーク、失敗時の挙動を比べる。
選び方：種類を増やす前に標準のExecutorを一つ決め、例外だけを追加します。

ポイント

検証の始めやすさを重視するならDocker中心、本番で同時実行数や可用性を求めるならKubernetesが候補です。複数のExecutorは、標準を一つ決めてから例外だけを足します。

導入・開発の進め方（6段階）

Screwdriverの導入は、インストールの後に、既存手順の見直しや検証、移行の作業が続きます。既存の手順を洗い出し、PoCで効果とリスクを確かめたうえで、標準化して段階的に移行します。

特に、全社のPipelineを一度に切り替えると、失敗の原因が基盤、YAML、アプリケーション、権限のどこにあるかを見分けにくくなります。そのため、対象を絞って検証します。

▶ 詳細はこちら：Screwdriverのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

1. 現状診断と対象範囲の決定

まず、リポジトリ数や言語、Build時間を含む現状の構成を一覧にします。また、テストの種類やデプロイ先、既存のCI/CDも一覧に含めます。手動承認の有無、Secretの扱い、Artifactの保管場所も、あわせて書き出します。

開発者の困りごとも記録します。実行時間や環境の差分、失敗の再現性に加えて、権限申請の遅さも対象です。

導入効果と比べるための基準として、デプロイ頻度と、変更から本番までのリードタイムを測っておきます。さらに、変更失敗率と障害からの復旧時間も押さえます。これらはDORA系の代表的な指標です。

2. 低リスクな1サービスでのPoC

まずは、重要度が低く、テスト手順が安定している1サービスを選びます。そのうえで、Pull Requestでの単体テストから、Commit後のBuild、Artifactの保存、後続Jobへの受け渡しまでを試します。

Jobの再実行やログ閲覧、Artifactの取得も確認します。また、異なる権限の利用者が操作する場合も、同じように確かめます。合格条件は、画面表示だけでなく、既存手順より速いか、失敗原因を追えるか、担当者が変更できるかで決めます。

3. YAML・イメージ・権限の標準化

PoCで使った設定を、ほかのサービスでも再利用できる標準に整えます。Job名やStage名、Buildイメージ、Artifactの命名を、テンプレートにまとめます。さらに、Secretのキーやログ保持期間、失敗通知、手動承認の条件も、標準に組み込みます。

標準化で開発者の自由をすべて奪う必要はありません。アプリ固有の処理を認める拡張点を設けられ、標準から外れる理由を記録しておけば、保守性と実用性を両立できます。

4〜6. 本番設計・段階移行・運用定着

本番移行では、設計から段階的な切り替え、運用定着までを順に進めます。

本番設計：API/UI、Store、Queue、Executor、Build用Cluster、レジストリそれぞれの責任を決めます。
運用基盤：監視、Secret管理、バックアップの担当範囲を明確にします。
段階移行：1チームから1部門へ移し、旧CI/CDと成功率や実行時間を比べます。運用工数とクラウド費用も、同じ条件で確認します。
運用定着：コードレビューや依存更新、脆弱性スキャンを定例の作業にします。ロールバック訓練や月次のKPI確認も含めます。

テンプレートやExecutorは、更新を担当する人と、更新する周期を決めておきます。運用責任が曖昧なままだと、導入後数か月で基盤が古くなるおそれがあります。

ポイント

全社を一度に切り替えず、現状の洗い出しと1サービスのPoCから始めます。標準化してから本番へ広げると、失敗の原因を切り分けやすくなります。

費用相場とコストの内訳

導入範囲が広がるほど初期費用の目安も大きくなります。

ScrewdriverはOSSとして利用できます。ただし、ライセンス費用が無料でも、システム全体では費用が発生します。

ここで示す金額は、2025〜2026年のDevOps・Kubernetes導入事例と一般的な工数をもとにした予算仮説です。

見積もりは、Pipeline数や同時実行数によって変わります。また、可用性、既存CI/CDからの移行量、監視・保守の範囲でも変わります。

▶ 詳細はこちら：Screwdriverのシステム開発の見積相場や費用/コスト/値段について

導入範囲別の初期費用と期間

初期費用は、導入範囲によって幅があります。PoCの0〜100万円から、全社・高信頼基盤の1,500万円以上までが目安です。期間も、1〜4週間から6〜12か月以上までと幅があります。

検証・PoC：0〜100万円、1〜4週間が目安です。
小規模チーム：300〜600万円、1〜2か月程度です。
本番標準基盤：600〜1,200万円、2〜4か月程度です。
全社・高信頼基盤：1,500万円以上、6〜12か月以上を見込む場合があります。

たとえば、既存の開発者がDocker環境を用意し、1リポジトリで基本のPipelineを試す場合は、外部への支出を抑えて、社内の工数を中心に進められます。

小規模導入の範囲には、SCM連携や複数Jobが含まれます。加えて、Secret、ログ、基本監視、運用手順も入ります。

本番標準では、複数チームでの利用やテンプレート、Build Clusterの分離を扱います。権限設計や障害訓練も含まれます。

これらは、公開されているDevOps導入相場をもとにした推定で、Screwdriverの公式価格ではありません（出典：NotebookLMリサーチノート、2026年）。

初期費用の内訳（基盤・移行・セキュリティ）

見積書では、本体設定や実行基盤の設計・構築、SCM認証連携を分けて書きます。既存Pipelineの移行、テンプレート作成、Artifact管理、Secret設計も、別々の項目にします。

監視・バックアップ、ドキュメント、教育も項目に含めます。Kubernetesでは、クラスタそのものに加えて、ノードやストレージ、レジストリの設定が必要になります。ログやメトリクス、バックアップの設定も欠かせません。

移行工数は、Pipelineが10本か100本かだけでなく、1本ごとの例外処理の数によっても変わります。そのため、見積もりにはPipeline数と複雑度の両方を示します。

ランニング費の変動要因（実行量と保守範囲）

ランニング費は、実行量や保守範囲によって変わります。主な費用の内容と、見積もりの際の注意点も、あわせて示します。

基盤・実行費：クラウドやサーバーの固定費、Buildの実行時間、コンテナレジストリです。
保管・保守費：ログ・メトリクス保存、バックアップ、脆弱性対応、問い合わせ・障害対応です。
小規模：月5〜30万円程度を仮置きできます。
中規模以上：月30〜150万円以上を仮置きできます。

金額は、同時実行数やログ保持期間によって増減する推定値です。Kubernetesを本番で使う場合は、Build時間が短くても、管理系のコンポーネントが常時稼働します。

ランニング費は、12か月分の運用費と担当者の月間工数まで含めて比べます（出典：Screwdriver公式Kubernetesガイド、2026年確認）。

ポイント

費用は導入範囲によって幅があるため、PoCか本番かを先に決めてから見積もりを比べます。ライセンス費が無料でも、移行費とランニング費は別に発生します。

既存のCI/CDツールとの違い

単一リポジトリのCIを早く始めたいならマネージド型が扱いやすく、複数のチームや環境をそろえたい場合はScrewdriverが候補になります。

選ぶ際は優劣だけでなく、自社でどこまで運用責任を持つかと、Pipelineの共通化をどれだけ重視するかで決まります。

マネージドCI/CDとの違い

マネージドCI/CDは、実行環境の準備やサービスの更新、認証連携の一部を任せられます。そのため、少数のリポジトリであれば、短期間で成果を出しやすくなります。

独自の基盤や複数のデプロイ先を細かく統一したい場合は、制約が出ることがあります。既存の権限モデルや社内ネットワークに合わせる場合も、制約になることがあります。

Screwdriverは自社環境に合わせられます。その代わり、更新や脆弱性対応の責任を、自社か委託先が持つことになります。可用性と障害対応も、運用の範囲に入ります。

JenkinsやGitHub Actionsなどとの違い

主な違いは、拡張性、リポジトリとの一体性、Pipelineの共通化です。

Jenkins：PluginとExecutorで拡張できる一方、設定や依存関係が複雑になりやすいです。
GitHub Actions：該当サービス中心のチームが導入しやすく、実行環境の準備を減らせます。
Screwdriver：横断Pipeline、外部Executor、複数環境への継続的デリバリーを一つの運用モデルで扱えます。

比べるときは、共通化する処理と既存ツールに残す処理を分けて考えます。

Argo CDなどのデプロイ専用ツールとの違い

用途に応じて使い分けられるほか、併用する構成も考えられます。

Argo CD：宣言的な設定を基準に、Kubernetesなどへのデプロイを担います。
Screwdriverの実行：Pull Requestでテストし、Commit後にBuildします。
ScrewdriverのPipeline：Artifact作成、承認、デプロイまでを一続きに設計します。
併用：ScrewdriverでテストとArtifact作成を行い、最終同期を別の仕組みに任せられます。

「Build」「成果物（Artifact）」「デプロイ」「環境同期」に分けて比べると、必要以上の移行を避けられます。

ポイント

単一リポジトリの簡易CIならマネージド型、複数のチームや環境をそろえたいならScrewdriverが候補です。Jenkinsとの違いは拡張性にあり、Argo CDとは役割を分けて併用する形もあります。

セキュリティと運用の注意点

CI/CD基盤は、ソースコードや認証情報、Artifactを扱います。さらに、本番環境への接続権限も扱うため、機能だけでなく、誰が何を実行できるかを設計する必要があります。

ScrewdriverはGitの権限モデルと連動し、Guest、Collaborator、Adminの役割を分けられます。

導入時には、権限やSecret、ログを一つのセキュリティ設計として確認します。Artifactやネットワークも、同じ設計の中で扱います。

SecretとPull Requestの分離

設定や権限を誤ると、本番用のSecretが意図しない変更から使われるおそれがあります。そのため、Secretの扱いを先に決めておきます。

保管と受け渡し：Secretは暗号化され、許可されたJobに環境変数として渡されます。
Pull Requestの設定：変更された screwdriver.yaml によってSecretの扱いが変わる可能性があります。
初期値：allowInPR はfalseです。
通常の運用：PRで機密情報を使わず、テスト用ダミー値と本番用Secretを分けます。
例外時：対象のリポジトリやJob、利用者、ログ出力、変更承認を記録します（出典：Screwdriver公式Secretsガイド、2026年確認）。

ありがちな失敗と対策

よくある失敗として、YAMLが巨大になり、変更の影響を追えなくなることがあります。Buildイメージの種類が増えると、再現性を失うことがあります。さらに、ログを長く残すと、費用や漏えいのリスクも高まります。

設定：共通処理をテンプレート化し、サービス固有設定を薄く保ちます。
イメージ：バージョンを固定し、定期的に更新します。
データと復旧：ログの保持期間を決め、Artifactに機密情報を含めず、再実行とロールバックを訓練します。

DORA系KPIによる効果測定

導入効果は、Job成功率に加えて、デプロイ頻度やCommitから本番までのリードタイムで測ります。変更失敗率と復旧時間も、併せて追います。さらに、運用負荷や費用も対象に含めます。

手動承認の回数や、失敗Jobの再実行時間も対象です。また、Pipeline変更までの時間や、Buildあたりのインフラ費用も見ます。導入前後の4週間を比べ、速度と変更失敗率を確かめます。

速度だけをKPIにすると、テストを省く動機になり得ます。そのため、安全性と品質の指標も併記します。

開発会社/ベンダーの選び方

Screwdriver専門の公式認定会社は、多くは公開されていません。

知名度よりも、まずは直接の経験を見ます。そのうえで、Kubernetesやコンテナ、DevSecOpsの経験も確かめます。また、OSS保守やCI/CD移行、クラウドやオンプレミスの運用も評価の対象です。

直接の実績が少なくても、必要な構成を検証し、設計の根拠と保守体制を説明できるかを確かめます。

構成単位での技術実績の確認

技術実績は、構成の部品ごとに具体的に質問します。Executor、SCM、データストアへの対応を聞き、Artifact Storeについても確かめます。Secret管理や監視の方法、バックアップやネットワークへの対応も、同じく確認します。

Kubernetes対応の説明では、Build用Namespaceの分離や同時実行数の上限を確かめます。Job再実行やノード障害、イメージの脆弱性対応についても確認します。可能であれば、匿名化したYAMLや構成図、障害対応の手順も見せてもらいます。

見積・契約・引き渡し範囲の明確化

見積と契約では、作業範囲や月額保守を明確にします。納品物と、契約終了時の引き渡しも決めておきます。

作業範囲：要件定義からPipeline移行、教育、運用引き継ぎまでを分けて示し、対象外も明記します。
月額保守：本体・Executor・Kubernetesの更新や脆弱性対応が含まれるかを確かめます。一次受付や夜間対応、クラウド費用も対象に入るか見ます。
納品物：ソースやYAML、IaC、構成図が対象です。権限一覧、ログ方針、運用とバックアップ・復旧の手順も対象に含めます。
契約終了：データ消去と引き渡しを定め、将来の移行時にロックインが起きにくい形にします。

▶ 詳細はこちら：Screwdriverのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Screwdriverのシステム開発の発注/外注/依頼/委託方法について

よくある質問（FAQ）

導入の判断で質問されやすいのは、費用、既存環境との連携、セキュリティです。構成は、リポジトリ数や言語、デプロイ先を確認し、社内規程と運用体制に合わせて決めます。

Screwdriverは無料で使えますか？

OSSとして利用できるため、ライセンス料を抑えて始められます。ただし、サーバーやKubernetes、Build実行の基盤には費用がかかります。ストレージやログ、監視、バックアップにも費用が発生し、更新や障害対応も費用の対象になります。

無料かどうかだけでなく、必要な運用範囲を含めた総保有コストで判断します。

既存のSCMやCI/CDと連携できますか？

連携できます。SCMからのWebhookを受け取り、リポジトリ内の screwdriver.yaml を読み込んで実行します。複数のSCMやExecutorを組み合わせることもできます。

既存のJenkinsなどは、一度にすべて置き換えなくても構いません。Screwdriverを入口や共通Pipelineにして、一部を既存Executorに任せる段階移行も可能です。

対応可否は、利用中のSCMや認証方式を、PoCで確かめます。ネットワークや対象JobのOS要件も確認します。

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

初期設定では、allowInPR がfalseになっています。Pull RequestからSecretを使えないため、標準の状態では本番Secretを渡さない設計にできます。ただし、設定や権限を誤るとリスクは残ります。

PR用の非機密の値と本番Secretは分け、例外は必要な場合に限って承認します。あわせて、アクセスの記録と定期的な見直しも行います。

2026年時点で採用する前に何を確認すべきですか？

公式ドキュメントで対応機能を確かめるほか、ブログやリリースの更新状況、Executorの保守状態、脆弱性対応の窓口も確認します。

2025年4月の公式ブログでは、Secret管理UI、APIトークン管理、Pull Requestの不整合検知などが案内されています。ただし、採用時の最新版で使えるかは、改めて確認が必要です。

導入前には小さなPipelineを動かし、更新や障害時の復旧手順まで検証します。

まとめ

Screwdriverは、コード変更をテスト、Build、Artifact作成、デプロイへつなぐ継続的デリバリー基盤です。業務アプリとは役割が違います。

Pipelineは screwdriver.yaml に定義し、SCMイベントやJobの依存関係を扱います。Executor、Secret、権限、Artifactの昇格も、コードと運用ルールでそろえられます。

この記事の要点

採用時は、複数チームのPipelineを標準化するか、Executorや実行基盤を要件に合わせるか、Pipelineをコードレビューするかを確認します。

単一サービスの簡易CIだけが目的なら、運用負担の小さい選択肢と比べることもできます。

次に確認する項目

まずは現状を診断し、1サービスのPoCから始めます。そのうえで、テンプレートと権限を標準化します。Docker、Kubernetes、既存のExecutorは要件に応じて使い分け、本番へ段階的に広げます。

費用は、OSSライセンスだけでなく、実行基盤や移行まで含めて見積もります。Secret、監視、バックアップ、保守の範囲も、費用の検討に加えます。さらに、複数チームで使う場合は、速度とあわせて、変更失敗率や復旧時間もKPIにします。

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