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

Spinnakerのシステム開発を発注するなら、OSSをインストールするだけではなく、Kubernetes・クラウドIAM・認証・監視・運用移管まで含む継続的デリバリー基盤として委託範囲を定義することが重要です。

この記事では、Spinnakerのシステムを外注・委託する際の発注形態の選び方、RFPと要件の整理、契約形態、2026年時点の費用相場、委託先の選定方法、見積書の比較ポイントまで、発注担当者が社内稟議と相見積もりに進めるための手順を解説します。なお、ここでいうSpinnakerはNetflix発のオープンソース継続的デリバリー（CD）プラットフォームであり、ニューロモーフィックコンピューターの「SpiNNaker」や企業名とは別の技術です。

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

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

Spinnakerは、アプリケーションをビルドするCIツールというより、完成したコンテナイメージやVMイメージを複数の環境へ安全に配備するCD基盤です。JenkinsやGitHub Actionsなどがビルド・テストを担当し、Spinnakerが承認、昇格、段階的リリース、ロールバックを担当する分担が基本となります。したがって発注対象は単体ソフトウェアではなく、既存の開発・運用プロセスに接続されたプラットフォームです。

SpinnakerはDeck、Gate、Orca、Clouddriver、Fiatなど複数のマイクロサービスで構成され、クラウドAPI、コンテナレジストリ、永続ストレージ、Redis、CI、監視基盤と連携します。たとえばEKSやGKEへ配置する場合は、Spinnaker用クラスタのネットワーク、ノード、TLS、ドメイン、バックアップまで準備が必要です。認証をSSOへ接続するだけでなく、誰がどのアプリケーションを実行できるか、どのクラウドアカウントへ書き込めるかも設計対象となります。

Spinnaker公式のインストールガイドでは、Kubernetesクラスタ、kubectlに統合されたKustomize、少なくとも6コア・18GBメモリ、永続ストレージが要件として示されています（出典: Spinnaker公式「Install and Configure Spinnaker」、2026年6月更新）。この条件は最低ラインであり、本番環境で高可用性や多数のアカウントを扱う場合は、負荷試験をもとに余裕を持ったサイジングを依頼する必要があります。

発注形態は、OSS版を自社Kubernetesで運用する構築委託、OpsMxなどのSpinnaker専門ベンダーへ設計・導入・保守をまとめて依頼する形態、EKSやGKEを含むクラウド基盤を専門会社へ一括委託する形態、そしてマネージドまたはエンタープライズ版を採用する形態に大きく分けられます。既にKubernetesとSREの担当者がいる企業は構築委託と内製運用の組み合わせが検討しやすく、運用人員が少ない企業はサポート契約やマネージドサービスを含めた方が、障害時の責任分界を明確にしやすいです。

配備先がKubernetes中心で、Gitを唯一の正として少数のアプリケーションを管理するだけなら、Argo CDなど別のCD製品の方が運用負荷を抑えられる場合もあります。一方、AWS・Azure・Google Cloud・オンプレミスをまたぎ、VMも含めてBlue-Greenやカナリア、承認、ロールバックを統一したい場合は、Spinnakerの検討価値が高まります。機能数ではなく、リリースガバナンスと運用担当者数で選ぶことが大切です。

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

RFPでは「Spinnakerを導入したい」と書くだけでは提案の比較ができません。対象アプリケーション数、クラウドアカウント数、クラスタ数、1日あたりのリリース回数、許容停止時間、承認者、監査ログの保存期間、障害時の復旧目標を先に示し、委託先が同じ前提で提案できる状態を作ります。目的を技術名から業務上の成果へ置き換えることが、過剰な構築を防ぐ最初のポイントです。

最初に、現在のCI/CDフローを「コード変更」「ビルド」「テスト」「イメージ登録」「デプロイ」「承認」「監視」「ロールバック」に分けます。そのうえで、リリースのリードタイム、変更失敗率、ロールバックに要する時間、手作業の工程数を記録します。目標は「デプロイを自動化する」ではなく、「本番反映までの時間を半分にする」「承認履歴を追跡可能にする」「失敗時に10分以内で戻せる」など、委託後に検証できる表現にすると評価しやすいです。

あわせて、アプリケーションの種類と重要度も一覧化します。まずは停止しても影響が限定的な1〜3アプリをPoC対象とし、決済や基幹系のように失敗コストが大きいシステムは本番移行の後半へ回します。対象を全社一括にすると、パイプラインの標準化と個別例外の調整だけで計画が膨らむため、段階的なオンボーディングをRFPの前提に入れることが現実的です。

機能要件には、CIからの成果物受け取り、開発・ステージング・本番への昇格、手動承認、Webhook、Blue-Green、カナリア分析、ロールバック、複数アカウントへのデプロイ、パイプラインテンプレートを記載します。CIはJenkinsやGitHub Actionsを使うのか、レジストリはECRやArtifact Registryなのか、監視はPrometheusやDatadogなのかも指定します。Spinnakerはビルドを代替するものではないため、どこまでをSpinnakerの責任にするかを明文化することが重要です。

非機能要件には、認証方式、Fiat RBAC、TLS、ネットワーク分離、可用性、バックアップ、監査ログ、秘密情報管理、脆弱性修正期限、アップグレード方針、障害時の対応時間を入れます。RFPの成果物として、Kustomizeマニフェスト、IaC、パイプライン定義、設定一覧、BOM、運用Runbook、テスト結果、教育資料、ソースと設定の引き渡しを求めると、納品後にベンダーへ依存し続けるリスクを下げられます。

Spinnakerのシステムが向くのは、複数クラウド、複数Kubernetesクラスタ、VMとコンテナの混在、高度な昇格制御、手動承認、カナリア、監査要件がある企業です。逆に、単一クラウドの少数アプリで、Gitの変更をそのままKubernetesへ同期できれば十分な場合は、より小さなCDツールやクラウド標準機能が適する可能性があります。RFPにはSpinnakerを採用しない案も含めて比較するよう依頼すると、目的に対して製品が過大になることを防げます。

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

Spinnakerの開発委託は、現状診断、PoC、標準化、本番化、段階展開、運用移管の順に進めると失敗を抑えやすいです。各段階の完了条件と次段階へ進む判断を契約書やプロジェクト計画に置き、検証できないまま本番環境へ進まないことが大切です。

PoCでは、CIで作ったイメージをレジストリから取得し、開発環境からステージング環境へ昇格させ、承認後にデプロイし、意図的な失敗からロールバックできるところまでを一連のシナリオで確認します。カナリア分析は、成功条件となるエラー率、レイテンシー、CPU使用率などの指標が決まってから追加します。指標が曖昧なまま自動判定を入れると、停止すべきリリースを通したり、正常なリリースを止めたりするためです。

PoCの完了条件には、パイプラインの再実行、権限のないユーザーによる操作拒否、ログからの実行履歴確認、障害時の手動復旧も含めます。OpsMxは自社サービスで「30日での継続的デリバリーのオンボーディング」を提示し、要件監査、パイロット、インストール、連携、教育、初回アプリの登録などを範囲に挙げています（出典: OpsMx「CD Design and Implementation」）。これは一般的な納期の保証ではなく、ベンダーが提示する支援例として、RFPの工程を分解する参考にします。

PoCで確認した内容を、JSONやYAML、Kustomize、Infrastructure as Codeで再現可能な形にします。UIから手作業で設定しただけでは、環境差分や担当者の退職で再構築できなくなるため、パイプラインテンプレート、命名規則、アプリケーションとアカウントの責任者をGitで管理します。委託先には、個別案件用のパイプラインと、複数アプリで再利用するテンプレートを分けて納品してもらいます。

認証と認可は別々に設計します。Spinnaker公式では、Fiatはユーザーやロールにアカウント・アプリケーション単位のREAD、WRITE、EXECUTEを付与する認可マイクロサービスですが、初期状態では無効で、権限を定義しないリソースがオープンになる仕様が説明されています（出典: Spinnaker公式「Authorization (RBAC)」、2026年4月更新）。SSOを入れたから安全と判断せず、クラウドIAMの最小権限、環境分離、TLS、秘密情報の保管、Webhookの送信元制限までRFPへ入れます。

本番化では、重要度の低いサービスからオンボーディングし、リリース頻度、リードタイム、変更失敗率、平均復旧時間、ロールバック時間を測ります。全社展開を一度に完了させるのではなく、5〜20アプリ程度を扱う小規模本番環境で運用手順を固め、例外が多いサービスを次の波へ回す方が、発注側の受け入れ負担を管理しやすいです。数字は導入前にも計測し、導入後と同じ定義で比較します。

運用移管では、バージョンとコンポーネントの一覧、変更方法、障害対応、バックアップとリストア、証明書更新、脆弱性対応、アップグレード、アカウント追加、パイプライン改修をRunbookに残します。Spinnaker公式の現行案内ではHalyardは非推奨で、Kustomizeネイティブな構成への移行が案内されています（出典: Spinnaker公式「Install and Configure Spinnaker」、2026年6月更新）。古い記事を前提にした納品ではなく、採用バージョンと更新方法を合意しておくことが重要です。

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

Spinnakerのように既存環境との不確実な接続が多い案件では、要件の確定度に応じて契約を分ける考え方が有効です。最初からすべてを固定価格に押し込むと、クラウドIAMや監視の前提差分が追加費用や納期遅延になりやすいため、PoCと本番構築で契約と受け入れ条件を分ける方法を検討します。

準委任契約は、発注側と委託先が協議しながら作業を進め、稼働した専門人材や作業時間に対して対価を支払う形態です。既存のKubernetes、IAM、CI、監視の状態を確認しながら設計するPoC、移行計画、運用設計、内製チームへの教育に向いています。成果物の完成を一方的に保証する契約ではないため、月次の作業範囲、会議体、課題管理、成果物、稼働上限、報告方法を明記します。

準委任で注意したいのは、作業を任せることと、社内の意思決定を任せることは違う点です。どのクラウドを採用するか、本番停止を許容するか、誰が承認者になるかは発注側が決めます。委託先の提案を受けつつ、決裁者と判断期限を社内で確保しておくと、技術検討だけが長期化する事態を避けられます。

請負契約は、合意した仕事を完成させ、成果物を引き渡すことを目的とする形態です。Spinnakerの本番環境について、指定バージョンの構築、認証連携、標準パイプライン、テスト、運用資料の納品など、範囲と受け入れ条件を固定できる場合に向きます。受け入れ条件には「デプロイできる」だけでなく、権限のないロールでは実行できないこと、失敗時に指定時間内でロールバックできること、ログが確認できることまで含めます。

請負で追加費用が発生しやすいのは、前提条件の変更、対象アプリの増加、クラウドアカウント追加、認証方式の変更、監視指標の追加です。変更管理の手順と単価表、納期への影響、追加発注の承認者を契約前に確認します。PoCは準委任、本番構築は請負、運用は保守契約という組み合わせも、リスクを分ける方法として検討できます。

契約前には、クラウドアカウントの所有者、Kubernetesの管理者、Spinnakerの設定変更者、パイプラインの承認者、障害一次対応者をRACIのように整理します。24時間対応が必要なら、受付時間、初動時間、復旧目標、重大度、エスカレーション、計画停止、脆弱性修正期限をSLAへ入れます。「保守あり」という一言では、アップグレードや障害時の設定変更が含まれるか判断できないためです。

また、OSS本体への修正、プラグイン、カスタムステージ、パイプライン定義、IaCの著作権と利用権、第三者ライセンス、秘密情報の返却、再委託先、ベンダー終了時の引き継ぎ条件を確認します。Armoryについては、Harnessが2024年に主要な知的財産と技術を取得し、Armory Continuous Delivery Self-Hostedの支援継続とHarness Platformへの移行機会を説明しています（出典: Harness「Harness Acquires Armory Assets」、2024年5月）。既存製品を選ぶ場合は、現在の製品名だけでなく、サポート主体と移行ロードマップを契約書で確認します。

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

SpinnakerはApache License 2.0を中心としたOSSのため、ライセンス料だけを見れば無料です。ただし、構築、クラウド基盤、セキュリティ、パイプライン設計、監視、教育、アップグレード、障害対応には費用がかかります。以下の金額は公式の一律価格ではなく、リサーチノートで整理した公式最低要件、公開されている支援範囲、一般的なシステム開発の人月単価を組み合わせた2025〜2026年時点の発注予算の推定です。実見積では環境と対象範囲によって変動します。

既存Kubernetes、1クラウド、1〜3アプリ、基本パイプライン、開発環境までに絞るPoCなら、初期費用は300万〜800万円程度を予算の仮置きにします。EKSやGKEなどのクラスタ準備、SSOやRBAC、ステージング・本番、監視、5〜20アプリのオンボーディングまで含める本番小規模では800万〜1,500万円程度が目安です。これらは公開されたSpinnakerの定価ではなく、発注範囲から算出したレンジです。

複数クラウドや複数クラスタ、カナリア、監査ログ、テンプレート、移行、教育まで含む中規模案件は1,500万〜3,000万円程度、複数地域、多数アカウント、厳格なSLA、既存ITSMや監視との連携、内製化支援を含むエンタープライズ案件は3,000万〜5,000万円以上になる可能性があります。想定範囲に対して金額が大きく違う場合は、単価の差よりも、クラウド基盤、アプリ移行、運用設計、保守がどちらの見積に含まれるかを確認します。

クラウド料金はSpinnakerの構築費とは別に計上します。Amazon EKSのクラスタ料金は標準サポート版で1クラスタあたり1時間0.10米ドル、延長サポート版で0.60米ドルです（出典: AWS「Amazon EKS pricing」、2026年確認）。730時間で単純計算すると約73米ドルまたは約438米ドルですが、これは制御プレーンの料金だけであり、EC2、EBS、ロードバランサー、IPv4、通信、ログ、レジストリは別料金です。

GKEもクラスタ管理料金が1クラスタあたり1時間0.10米ドルで、無料枠として請求アカウントあたり月74.40米ドル相当のクレジットが示されています（出典: Google Cloud「Google Kubernetes Engine pricing」、2026年確認）。本番の冗長化、Spinnakerのワーカーノード、監視、ログ、ストレージ、対象アプリのリソースを含めた日本円の月額は構成と為替で大きく変わるため、見積書ではクラウド請求の実費と委託先の運用費を分けて提示してもらいます。

保守運用費は、初期費用の年15〜25%程度を予算仮説に置く方法がありますが、これは市場一律の価格ではなく、アップグレード、脆弱性対応、障害対応、パイプライン改修、クラウドAPI変更、教育などに必要な運用人月から考える推定です。24時間対応、複数クラスタ、厳格なSLA、専任担当、マネージドサービスを含めるほど高くなるため、年額だけで判断せず、月あたりの対応時間と含まれる作業を比較します。

見積書に「運用一式」「監視一式」としか書かれていない場合は、定例、アラート対応、証明書更新、バージョンアップ、休日対応、障害後の再発防止、アプリ追加のそれぞれを分解してもらいます。初期費用を低く見せ、運用や追加アプリを別請求にする提案もあるため、3年間の総保有コストで比較することが安全です。

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

委託先は、Spinnakerという製品名だけでなく、クラウド、Kubernetes、IAM、可観測性、SRE、契約後の運用体制を横断して評価します。Spinnaker専業または直接支援を掲げる会社と、EKS・GKE・Kubernetes基盤に強い会社は得意領域が異なるため、RFPの要件に合わせて候補を分け、同じ質問で確認します。

候補会社には、Spinnakerのバージョン、対応したクラウドプロバイダー、Kubernetesの規模、アプリ数、カナリアやロールバックの実装、Fiat RBAC、障害対応、運用移管の実績を確認します。公開ページに書かれている支援範囲と、提案担当者が実際に設計・運用した経験は別です。事例名を開示できない場合でも、匿名化した構成図、課題、期間、KPI、担当範囲を説明できるかを見ます。

OpsMxはカスタム開発、セキュリティ、コンプライアンス、移行、トレーニング、マネージド運用などSpinnakerに直接関係する支援範囲を公開しています。MeteorOpsはSpinnakerとKubernetes、AWS、Google Cloud、Azureなどのコンサルティングを掲げています。一方、AWSやGoogle Cloudのパートナー、Kubernetes専門会社を選ぶ場合は、基盤の実績だけでなくSpinnaker固有の担当実績があるかを追加で確認します。

相見積もりでは、要件定義、現状診断、PoC、設計、構築、パイプライン実装、セキュリティ、テスト、移行、教育、保守を行に分けてもらいます。金額だけでなく、担当者の役割、稼働月数、作業時間、納品物、発注側の前提作業、除外事項、追加単価を同じ形式で並べます。要件定義を無料にしている会社と、設計費を別に計上する会社を比べる際も、工程の抜けを見つけやすくなります。

特に差が出るのは、アプリのオンボーディング数、クラウドアカウントの数、環境数、認証連携、監視とカナリア、既存パイプラインからの移行、ドキュメントと教育、休日対応です。「一式」が多い見積は、少なくとも作業内容、完了条件、含まれる回数、追加時の単価へ分解してもらいます。最安値ではなく、3年間で必要な社内工数と外部費用を合わせて選ぶことが重要です。

パイプラインは本番環境を変更できるため、設定ミスがそのまま重大な障害や情報漏えいにつながります。FiatのRBAC、クラウドIAM、秘密情報の参照方法、TLS、ネットワーク境界、監査ログ、署名付き成果物、コンテナスキャン、SBOM、脆弱性修正期限、ブレークグラス手順を評価項目に入れます。外部サービスやWebhookへ送るログに、個人情報やトークンが混入しない設計も確認します。

さらに、設定ファイルやIaCを発注側のリポジトリで管理できるか、ソースとパイプラインを返却してもらえるか、別会社へ移管できるかを確認します。特定ベンダーの独自プラグインに依存する場合は、OSS本体の更新と互換性、サポート終了時の代替策、撤退時のデータ移行方法を見積の前提に含めます。発注時に引き渡し条件を定めることで、将来の内製化や委託先変更の選択肢を残せます。

よくある質問（FAQ）

最後に、Spinnakerのシステム開発を発注する際に担当者からよく寄せられる質問へ回答します。ライセンス料、期間、代替製品、委託先の選び方は、社内稟議でも確認されやすい論点です。

SpinnakerのOSSライセンス料は基本的に無料ですが、構築、Kubernetes、クラウドリソース、認証、監視、保守、教育の費用は発生します。PoCだけなら数十万〜数百万円規模の作業で済む場合もありますが、本番のRBAC・冗長化・運用引き継ぎを含める場合は、記事で示した数百万円から数千万円の発注予算を範囲に応じて検討します。

既存Kubernetes、1クラウド、少数アプリのPoCは1〜2か月、本番小規模は2〜4か月、中規模の複数環境は4〜6か月、エンタープライズは6〜12か月以上を期間の目安にします。これは対象範囲から算出した一般的な計画値であり、公式の納期ではありません。認証審査、ネットワーク申請、アプリ側の改修、社内承認が遅れると期間も変わるため、RFPでは発注側の作業と依存関係も明記します。

Kubernetes中心でGitの状態を同期することが主目的なら、Argo CDの方が構成と運用を小さくできる可能性があります。複数クラウド、VMとコンテナの混在、Blue-Greenやカナリア、複雑な承認・昇格、複数アカウントのリリースガバナンスが必要ならSpinnakerを比較します。RFPでは両製品の提案を求め、運用人員、移行コスト、監査要件、将来の拡張性まで含めて判断します。

候補を3〜5社程度に絞り、同じRFPと質問票で比較すると、価格だけでなく提案の解像度を確認しやすいです。Spinnaker直接支援、クラウド・Kubernetes基盤、運用・マネージドサービスの候補を混ぜ、各社にバージョン、担当体制、公開実績、作業範囲、SLA、引き渡し条件を回答してもらいます。候補数が多すぎると提案評価の工数が膨らむため、技術要件を満たす会社だけを二次選考へ進めます。

まとめ

Spinnakerのシステム開発を発注するときは、OSSの導入作業ではなく、CD基盤の設計・セキュリティ・クラウド運用・アプリのオンボーディング・保守までを一つのサービスとして捉えます。最初に現状のリリース課題を数値化し、1アプリ・1クラスタのPoCで価値と運用負荷を検証してから、本番化と段階展開へ進めます。

RFPには、対象アプリ・環境・クラウドアカウント、CIとレジストリ、承認と監査、Blue-Green・カナリア・ロールバック、認証・Fiat RBAC・IAM、TLS・秘密情報、監視・バックアップ、採用バージョン、テスト、移行、教育、運用SLA、成果物の引き渡しを記載します。見積は要件定義、PoC、設計、構築、テスト、移行、保守を分け、金額のレンジと前提条件が比較できる形で依頼します。

費用はPoCで300万〜800万円、本番小規模で800万〜1,500万円、中規模で1,500万〜3,000万円程度を仮説に置けますが、公式定価ではなく、構築範囲と運用要件に基づく推定です。クラウド料金、保守、社内工数まで含めて3年間の総額を比較し、実績と責任分界を確認できる委託先へ相談してください。Spinnakerが自社の課題に対して過大でないか、Argo CDなどの代替案も含めて検討することが、納得できる発注につながります。

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

会社紹介

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

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

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