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

Spinnakerの発注は、現状診断、PoC、標準化、本番化、段階展開、運用移管の順に進めます。

最初は1アプリ・1クラスタのPoCで配備と復旧を検証し、結果を見てから本番へ広げます。全体像はSpinnakerのシステム開発の完全ガイドもご覧ください。

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

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

本体の周辺に連携・環境・権限の準備も並びます。

Spinnakerは、CIのビルドツールというより、完成したコンテナやVMのイメージを複数環境へ安全に配備するCD基盤です。JenkinsやGitHub Actionsなどがビルドとテストを担い、Spinnakerは承認と昇格、段階的リリース、ロールバックを担います。そのため、発注対象はソフト単体ではなく、開発と運用のプロセスにつながる基盤になります。

発注対象の範囲：本体と連携先、稼働環境

発注範囲は、Spinnaker本体だけでなく、連携先や稼働環境まで含めて整理します。

構成要素：Deck、Gate、Orca、Clouddriver、Fiatなどのマイクロサービス。
連携先：クラウドAPI、レジストリ、永続ストレージ、Redis、CI、監視基盤。
クラスタ環境：ネットワーク、ノード、TLS、ドメイン、バックアップ。
認証・権限：SSO、実行できるアプリ、書き込み先のクラウドアカウント。

EKSやGKEに置く場合は、クラスタ環境の準備も必要になります。公式ガイドは、Kubernetesクラスタ、kubectl統合済みのKustomize、6コア以上、18GBメモリ、永続ストレージを要件として示しています（出典：Spinnaker公式「Install and Configure Spinnaker」、2026年6月更新）。

これは最低ラインです。そのため、本番で高可用性や多数のアカウントを扱う場合は、負荷試験に基づく余裕のあるサイジングを依頼します。

運用体制に合わせた発注形態の選び方

発注形態は、自社の運用体制と必要な支援範囲を基準に比べます。

OSS構築委託：自社Kubernetesでの構築と運用。
専門ベンダー委託：OpsMxなどへ設計、導入、保守を一括依頼。
クラウド基盤一括委託：EKSやGKEを含む基盤を専門会社へ委託。
マネージド型：マネージドまたはエンタープライズ版を採用。

KubernetesとSREの担当者がいる企業は、構築委託と内製運用を組み合わせやすいです。運用人員が少ない企業は、サポートやマネージドサービスを含めれば、障害時の責任分界を明確にできます。

配備先がKubernetes中心で、Gitを唯一の正として少数のアプリを管理するなら、Argo CDなどが合う場合もあります。

Spinnakerは、AWS・Azure・Google Cloud・オンプレミスをまたぐ環境で候補になります。

発注側は、VMも含む配備でBlue-Green、カナリア、承認、ロールバックを統一したい場合にも、Spinnakerを検討します。

選ぶときは、機能数よりも、リリースガバナンスと運用担当者数を基準にします。

ポイント

発注対象はSpinnaker本体だけでなく、連携先や稼働環境まで含めて考えます。運用人員が少ないなら、障害時の責任分界が明確な発注形態を優先して比べると判断しやすくなります。

発注前にRFPと要件を整理する方法

4分類が揃うと提案範囲を比べられます。

RFPに「Spinnakerを導入したい」とだけ伝えても、提案を比較できません。各社の提案を比べるには、RFPに対象アプリ数、クラウドアカウント数、クラスタ数、1日あたりのリリース回数を示すことが欠かせません。

許容停止時間、承認者、監査ログの保存期間、障害時の復旧目標も示します。

目的を業務の成果に置き換えておけば、過剰な構築を避けられます。

現状と導入目的の数値による棚卸し

まず、現在のCI/CDフローを工程、計測値、対象アプリの重要度に分けて洗い出します。

工程：コード変更、ビルド、テスト、イメージ登録、配備、承認、監視、ロールバック。
計測値：リードタイム、変更失敗率、ロールバック時間、手作業の工程数。
目標例：本番反映を半分にする、承認履歴を追跡可能にする。
PoC対象：停止時の影響が限定的な1〜3アプリ。

目標は「失敗時に10分以内で戻せる」のように、委託後に評価できる形で設定します。

決済や基幹系など失敗のコストが大きいシステムは、本番移行の後半へ回します。

全社一括では、標準化と例外の調整で計画が膨らみやすいため、段階導入をRFPに含めます。

RFPで機能要件と非機能要件を分ける書き方

要件と成果物を分けて示すと、各社の提案範囲と納品後の引き継ぎを比べやすくなります。

機能：成果物受取、開発・ステージング・本番への昇格、手動承認、Webhook、Blue-Green、カナリア、ロールバック。
連携：複数アカウント、テンプレート、CI、レジストリ、監視製品。
非機能：認証、Fiat RBAC、TLS、ネットワーク分離、可用性、バックアップ、監査、秘密情報管理。
納品物：Kustomizeマニフェスト、IaC、パイプライン定義、設定一覧、BOM、Runbook、テスト、教育資料、ソースと設定。

CIはJenkinsやGitHub Actions、レジストリはECRやArtifact Registryなど、採用する製品を明記します。

監視も、PrometheusやDatadogなどの中から指定します。

Spinnakerはビルドを代替しないので、どこまでを担当するかを定めておきます。

障害時の対応時間、脆弱性の修正期限、更新方針も要件に含めます。また、納品物を受け取っておけば、ベンダー依存のリスクを下げられます。

自社にSpinnakerが向いているかの事前判定

Spinnakerが向いているかは、配備環境とリリース制御に必要な機能で判断します。一方で、単一クラウドで少数のアプリなら、小さなCDツールやクラウド標準機能で足りる場合もあります。

適性を検討：複数クラウド・クラスタ、VMとコンテナの混在。
適性を検討：高度な昇格制御、手動承認、カナリア、監査要件。
代替案も検討：単一クラウドの少数アプリをGit同期できれば十分な場合。

RFPでは不採用となる案も比べておくと、目的に対して製品が過大になるのを防げます。

ポイント

RFPには、対象の規模と機能・非機能の要件を分けて書きます。そのうえで、Spinnakerが目的に対して過大でないかを、不採用案と並べて判断します。

Spinnakerの発注・外注を進める手順

発注は、現状診断から運用移管まで、段階ごとに区切って進めます。まず現状を診断し、PoCで検証したうえで、標準化と本番化を進めます。そのあと段階展開へ広げ、最後に運用移管へ移ります。各段階の完了条件と次へ進む判断は、契約書や計画に定めておきます。検証が終わらないまま本番環境へ進むと、問題に気づくのが遅れます。

最初の1アプリ・1クラスタによるPoC

PoCでは、配備から復旧までを通しで検証し、運用が成り立つ条件を確かめます。

配備：CIのイメージを取得し、開発からステージングへ昇格する。
復旧：承認後に配備し、意図的な失敗からロールバックする。
権限・履歴：再実行、権限外操作の拒否、実行履歴を確認する。
手動復旧：障害時に手動で復旧できることを確かめる。

カナリア分析は、エラー率、レイテンシー、CPU使用率などの成功指標を決めてから加えます。指標が曖昧だと、止めるべきリリースを通してしまったり、正常なリリースを止めてしまったりすることがあります。

OpsMxは「30日での継続的デリバリーのオンボーディング」を提示しています（出典：OpsMx「CD Design and Implementation」）。この内容は、要件監査、パイロット、導入、連携、教育、初回登録を含む支援例で、一般的な納期の保証ではありません。

RFPの工程を分解するときの参考として扱います。

標準パイプラインとセキュリティの設計

設定の再現性と権限管理を、標準化とセキュリティの両面から設計します。

再現性：JSON、YAML、Kustomize、Infrastructure as Codeで管理する。
標準化：テンプレート、命名規則、責任者をGitで管理する。
納品：個別用と複数アプリ向けのパイプラインを分ける。
権限：最小権限、環境分離、TLS、秘密情報、Webhook制限。

UIだけで設定すると、環境の差分や担当者の退職があったときに、再構築できなくなるおそれがあります。

Fiatは、アカウントやアプリ単位でREAD、WRITE、EXECUTEを付与する認可サービスです（出典：Spinnaker公式「Authorization (RBAC)」、2026年4月更新）。初期状態では無効で、権限を定義していないリソースはオープンになります。SSOを入れただけで安全と判断しないでください。

段階展開と運用移管の納品条件

本番展開は段階的に進め、運用移管に必要な手順と情報を納品条件に含めます。

段階展開：重要度の低いサービスから、5〜20アプリ程度で手順を固める。
効果測定：頻度、リードタイム、失敗率、平均復旧時間、ロールバック時間。
Runbook：構成、変更、障害、バックアップ、証明書、脆弱性、更新。
移管情報：アカウント追加とパイプライン改修の手順。

例外の多いサービスは次の段階へ回し、受け入れの負担を管理します。また、導入の前後で、同じ定義にもとづいて測定します。

公式案内では、Halyardは非推奨で、Kustomizeネイティブ構成への移行が示されています（出典：Spinnaker公式「Install and Configure Spinnaker」、2026年6月更新）。

古い記事を前提にせず、採用するバージョンと更新方法を発注側と開発会社で合意します。

ポイント

次の段階へ進むかどうかは、契約書や計画に定めた完了条件で判断します。PoCで検証が終わっていない段階は、本番へ進めないのが目安です。

Spinnakerの外注で選ぶ契約形態と責任分界

既存環境との接続に不確実性がある案件では、要件の確定度に応じて契約を分けます。すべてを固定価格にすると、IAMや監視の前提の差分が追加費用や遅延につながるおそれがあります。

たとえば、PoCと本番構築で契約と受け入れ条件を分けることを検討します。

探索と伴走に向く準委任契約

準委任は探索や伴走に向いています。ただし、作業と社内判断の責任は分けて定めます。

支払い：協議しながら進め、専門人材や作業時間に対価を支払う。
対象作業：PoC、移行計画、運用設計、内製チームへの教育。
契約内容：月次範囲、会議体、課題管理、成果物、稼働上限、報告方法。
社内判断：クラウド、本番停止の許容、承認者を発注側が決める。

作業は、既存のKubernetes、IAM、CI、監視を確認しながら進められます。

準委任は、成果物の完成を一方的に保証する契約ではありません。また、決裁者と判断期限を社内で確保し、検討の長期化を避けます。

範囲と受け入れ条件を固めた請負契約

請負は、範囲と受け入れ条件を確定できる本番構築で使います。

対象：指定版、認証連携、標準パイプライン、テスト、運用資料。
受け入れ：配備、権限外実行の拒否、指定時間内の復旧、ログ確認。
追加変更：前提、アプリ、アカウント、認証方式、監視指標。
契約の組み合わせ：PoCは準委任、本番は請負、運用は保守契約。

追加の変更に備えて、変更手順と単価表、納期への影響、追加発注の承認者を契約前に確認しておきます。

契約書の運用責任と引き渡し範囲

契約では、運用責任、SLA、知的財産、終了時の引き継ぎ範囲を明確にします。24時間対応が必要な場合は、受付時間と初動時間も定めます。

責任分界：RACIのようにクラウド、Kubernetes、変更、承認、一次対応を整理。
SLA：受付・初動、復旧目標、重大度、連絡、計画停止、脆弱性期限。
権利・情報：OSS修正の著作権・利用権、プラグイン、カスタムステージ、パイプライン定義、IaC、第三者ライセンス。
終了時：秘密情報返却、再委託先、成果物・運用の引き継ぎ。

「保守あり」と書かれていても、更新や障害時の設定変更が含まれるかは分かりません。そのため、作業範囲を定めておきます。

HarnessはArmoryの知的財産と技術を取得しました（出典：Harness、2024年5月）。発表名は「Harness Acquires Armory Assets」です。

Armory Continuous Delivery Self-Hostedの支援継続と、Harness Platformへの移行機会についても説明しています。

既存製品を使う場合は、サポート主体と移行ロードマップを契約で確認します。

ポイント

要件が確定していない範囲は準委任、範囲と受け入れ条件が固まった本番構築は請負で分けて考えると判断しやすくなります。

Spinnakerのシステム開発費用と相場

規模が上がるごとに費用レンジも高くなります。

SpinnakerはApache License 2.0が中心のOSSで、ライセンス料は基本的に無料です。ただし、構築、クラウド基盤、セキュリティには費用がかかります。さらに、パイプライン設計、監視、教育、更新、障害対応も費用の対象です。

以下に示す金額は、公式の一律価格ではなく、公式最低要件や公開支援範囲、一般的な開発人月単価からの2025〜2026年の予算推定です。環境と対象範囲によって変わります。

初期費用の目安、PoCは300万〜800万円

初期費用の目安は、対象範囲と環境の規模に応じて段階的に変わります。

PoC：既存Kubernetes、1クラウド、1〜3アプリ、基本パイプラインと開発環境で300万〜800万円。
小規模本番：EKS・GKEのクラスタ、SSO・RBAC、ステージング・本番、監視、5〜20アプリで800万〜1,500万円。
中規模：複数クラウド・クラスタ、カナリア、監査ログ、テンプレート、移行・教育で1,500万〜3,000万円。
大規模条件：複数地域、多数アカウント、厳格なSLA、ITSM・監視連携、内製支援。
大規模費用：上記を含む場合、3,000万〜5,000万円以上の可能性。

ここに示す金額は公開定価ではなく、発注範囲に基づくレンジです。見積の差が大きいときは、単価だけでなく、基盤、移行、運用設計、保守の含有範囲をあわせて照合します。

クラウドと保守の費用の別枠での見積もり

クラウドの実費と委託先の運用費は、構築費とは分けて見積もります。

EKS標準サポート版：1クラスタ・1時間0.10米ドル。
EKS延長サポート版：1クラスタ・1時間0.60米ドル。
GKEクラスタ管理：1クラスタ・1時間0.10米ドル。
GKE無料枠：請求アカウントあたり月74.40米ドル相当。

EKS料金は、AWS公式の2026年確認値です（出典：AWS「Amazon EKS pricing」）。730時間なら、標準サポート版は約73米ドル、延長サポート版は約438米ドルです。

また、制御プレーン以外にも、EC2、EBS、ロードバランサーは別料金です。さらに、IPv4、通信、ログ、レジストリも別料金になります。

GKE料金と無料枠は、Google Cloudの2026年確認値です（出典：Google Cloud「Google Kubernetes Engine pricing」）。

冗長化、ワーカーノード、監視、ログ、ストレージ、アプリの資源を含めた月額は、構成と為替によって変わります。

保守費の対応範囲と人員

保守費は、金額の前提と含まれる作業、対応時間をあわせて比べます。

対象作業：更新、脆弱性・障害対応、改修、クラウドAPI変更、教育。
費用増の条件：24時間対応、複数クラスタ、厳格なSLA、専任、マネージド。
比較内容：月の対応時間、定例、アラート、証明書、休日、アプリ追加。

初期費用の年15〜25%という数字は、市場一律の価格ではなく、必要な運用人月から考えた推定です。

「運用一式」「監視一式」といった見積は、作業内容や障害後の再発防止まで分解してもらいます。

初期費用を抑えて、運用や追加アプリを別請求にする提案もあります。そのため、3年間の総保有コストで比べます。

ポイント

初期費用、クラウド実費、保守費は分けて見積もり、3年間の総額で比べて判断します。金額はレンジなので、単価だけで決めないことも大切です。

委託先の選定と見積比較のポイント

委託先は製品名だけでなく、クラウド、Kubernetes、IAM、可観測性、SRE、契約後の運用体制から評価します。

Spinnaker専門会社と、EKS・GKE・Kubernetes基盤に強い会社では、得意な領域が異なります。そのため、RFPに合わせて候補を分け、各社へ同じ質問をします。

公開実績と担当者の経験の切り分け

公開情報と、提案を担う担当者本人の実務経験を分けて確かめます。

技術実績：バージョン、クラウド、Kubernetes規模、アプリ数。
実装経験：カナリア、ロールバック、Fiat RBAC。
運用経験：障害対応、運用移管。
事例説明：匿名化した構成図、課題、期間、KPI、担当範囲。

OpsMxは、カスタム開発、セキュリティ、コンプライアンス、移行、教育、マネージド運用を公開しています。また、MeteorOpsは、SpinnakerとKubernetes、AWS、Google Cloud、Azureなどのコンサルティングを掲げています。

クラウドやKubernetesの専門会社に対しても、Spinnaker固有の担当実績を確認します。

工程・人員・前提条件をそろえた見積比較

見積の工程と前提をそろえ、作業範囲と3年間の負担を比べます。

工程：要件定義、診断、PoC、設計、構築、実装、テスト、移行、教育、保守。
費用条件：役割、稼働月数、時間、納品物、発注側作業、除外事項、追加単価。
差が出る範囲：アプリ・アカウント・環境数、認証、監視・カナリア、パイプライン移行、文書・教育、休日対応。
一式の内訳：作業、完了条件、回数、追加時の単価。

要件定義を無料とする会社と、設計費を計上する会社とでは、工程に抜けがないかを照合します。そのうえで、最安値よりも、3年間の社内工数と外部費用を合わせて選びます。

セキュリティとベンダーロックインの評価

本番変更の権限と、外部委託終了後の移行可能性を両面で確認します。

アクセス制御：Fiat RBAC、クラウドIAM、秘密情報の参照方法、TLS、ネットワーク境界、監査ログ。
成果物保護：署名付き成果物、コンテナスキャン、SBOM、脆弱性修正期限、ブレークグラス手順。
ログ：外部送信時に個人情報やトークンが混ざらない設計。
移行性：設定・IaC・ソースの管理、返却、他社移管、データ移行。

独自プラグインは、OSS更新との互換性と、サポート終了時の代替策を確認します。引き渡し条件を定めておけば、内製化や委託先の変更という選択肢を残せます。

よくある質問（FAQ）

発注担当者から出やすい質問を、ライセンス料、期間、代替製品、委託先の順に答えます。

SpinnakerはOSSなので発注費用は無料ですか？

OSSライセンス料は基本的に無料ですが、構築、Kubernetes、クラウドリソースには費用がかかります。さらに、認証、監視、保守、教育も費用の対象です。

PoCは数十万〜数百万円規模で済む場合もあります。一方で、本番RBAC、冗長化、運用引き継ぎを含める場合は、本文の数百万円から数千万円の予算を、範囲に応じて検討します。

Spinnakerの構築を外注すると何か月かかりますか？

期間は規模別の目安を示したうえで、社内手続きなどの前提条件もあわせて確認します。

PoC：既存Kubernetes、1クラウド、少数アプリで1〜2か月。
小規模本番：2〜4か月。
中規模の複数環境：4〜6か月。
エンタープライズ：6〜12か月以上。

上記の期間は、対象範囲から算出した計画値で、公式納期ではありません。認証審査、ネットワーク申請、アプリ改修、社内承認によって期間は変わるため、RFPには発注側の作業と依存関係を明記します。

Argo CDとSpinnakerはどちらを選べばよいですか？

Argo CDとSpinnakerのどちらが合うかは、自社の配備環境と求める統制の範囲で決まります。

Argo CDを検討：Kubernetes中心でGitの状態同期が主目的。
Spinnakerを比較：複数クラウド、VM混在、Blue-Green、カナリアが必要。
追加の判断軸：複雑な承認・昇格、複数アカウントの統制。

RFPで両案の提案を求め、運用人員、移行費、監査要件、将来の拡張性を含めて判断します。

Spinnakerの委託先は何社に見積を依頼すべきですか？

候補は3〜5社程度に絞り、同じRFPと質問票で提案を比較します。

候補領域：Spinnaker直接支援、クラウド・Kubernetes基盤、運用・マネージドサービス。
共通質問：バージョン、体制、実績、作業範囲、SLA、引き渡し条件。

候補が多すぎると評価工数が膨らむため、技術要件を満たす会社だけを二次選考へ進めます。

まとめ

発注範囲は、OSSの導入だけでなく、CD基盤の設計、セキュリティ、クラウド運用、アプリ登録、保守まで含みます。まず現状を数値で把握し、1アプリ・1クラスタのPoCで価値と運用負荷を確かめてから本番へ進みます。

発注前にRFPへ書く項目

RFPには、対象と機能、セキュリティ、運用、納品条件をまとめて書きます。

対象・連携：アプリ、環境、クラウドアカウント、CI、レジストリ。
機能：承認、監査、Blue-Green、カナリア、ロールバック。
安全性：認証、Fiat RBAC、IAM、TLS、秘密情報。
運用・納品：監視、バックアップ、採用版、テスト、移行、教育、運用SLA、成果物の引き渡し。

見積は工程ごとに分けて、金額のレンジと前提を比べます。要件定義、PoC、設計では、どこまでを対象にするかを確かめます。構築、テスト、移行、保守は、それぞれの金額と作業内容を分けてもらいます。

導入可否の診断とPoCの相談という始め方

導入可否を診断し、小さなPoCから始めると、費用と運用負荷を確認しやすくなります。

PoC：300万〜800万円程度。
小規模本番：800万〜1,500万円程度。
中規模：1,500万〜3,000万円程度。
比較条件：クラウド費、保守、社内工数を含む3年間の総額。

金額は公式定価ではなく、構築範囲と運用要件に基づく推定です。

実績と責任分界を確認し、Argo CDなどの代替案も含めて相談します。そのうえで、自社の課題に対してSpinnakerが過大でないかを検討すると、納得できる発注につながります。

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

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