Spinnakerのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Spinnakerのシステム開発は、要件整理、方式選定、基盤設計、テスト、本番展開、定着の順に進みます。

段階的に導入することが、安全なリリース基盤の定着につながります。全体像は、Spinnakerのシステム開発の完全ガイドもご覧ください。

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

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

Spinnakerのシステム開発の全体像

Spinnakerは、完成したコンテナイメージやVMイメージを配備するCD基盤です。ソースコードをビルドする製品ではありません。

Jenkins、GitHub Actions、GitLab CIなどのCIが成果物を作り、Spinnakerが承認・検証・段階展開を挟んで昇格と配備を行います。この役割分担を先に決めておくと、導入の範囲がぶれにくくなります。

Spinnakerを導入する価値

リリースの再現性は、パイプラインの制御と、展開後の判断を組み合わせることで高まります。

• 進行制御：トリガー、ステージ、手動承認、Webhook、待機の組み合わせ。
• 展開戦略：Blue-Green（Red/Black）やカナリア分析による新旧バージョンの比較。
• 異常時対応：影響を抑えながら行う、展開の停止や切り戻しの判断。

Spinnakerを使うと、開発環境からステージング、本番へ進む条件を標準化できます。

効果が出やすいのは、AWSとGoogle Cloudをまたぐ環境や、複数のKubernetesクラスタを運用する環境です。VMとコンテナを同じ方針で管理する場合も、候補になります。

一方で、少数のKubernetesアプリをGitの変更だけで同期するなら、Argo CDのほうが小さく始めやすい場合もあります。どちらを選ぶかは、リリースの複雑さと運用人員で判断します。

Spinnakerの構成要素

Spinnakerは、複数のサービスを連携させて、配備と運用に必要な機能を分担する仕組みです。

• 管理・実行：Deckは管理画面、GateはAPIゲートウェイ、Orcaはパイプライン実行。
• 連携：ClouddriverはクラウドやKubernetes、EchoとIgorはイベントやCIとの連携。
• 分析・権限：RoscoによるPackerのイメージ作成、Kayentaによるメトリクス分析、Fiatによる権限管理。

Kayentaは、PrometheusやDatadogなどのメトリクスを使います。また、Fiatは、ユーザーやグループ、アカウント、アプリケーション単位の権限を管理します。

構築の対象には、Spinnakerのコンテナのほかに、Kubernetesや永続ストレージ、Redisがあります。さらに、クラウドAPIやIAM、レジストリも含まれます。監視・認証基盤と秘密情報管理も、構築の対象です。

公式の2026年インストール資料は、対応Kubernetesクラスタ、kubectlとKustomize、少なくとも6コア・18GBメモリを前提としています（出典: Spinnaker公式「Install and Configure Spinnaker」、2026年）。そのため、「OSSなので無料」という説明を見積もりの比較材料とするのは不十分です。

Spinnakerのシステム開発の進め方

Spinnaker導入は、全社の本番パイプラインから始めず、6つのフェーズで進めます。最初に要件整理を行い、次に運用モデルを選定します。そのうえで、基盤と標準パイプラインを設計開発します。

導入の計画にテスト、稼働、定着までを含めておくと、導入後に使われない仕組みになるリスクを下げられます。

フェーズ1：要件整理による対象範囲と成功条件の決定

対象範囲と成功条件は、現在のリリース状況と目指す業務をもとに具体化します。

• 規模：対象アプリ数、環境数、クラウドアカウント数の確認。
• 現状指標：1日あたりのリリース数、リードタイム、変更失敗率、平均復旧時間の把握。
• 業務条件：許容停止時間と、本番承認者の分担。

業務上の要望は、たとえば「開発・運用チームで承認者を分ける」「複数クラウドの同一サービスを同じ手順で昇格する」といった目的に言い換えます。

要件チェックリストには、CIの成果物の形式とレジストリを記載します。配備先がKubernetesかVMかも明記し、環境間の昇格条件もここに含めます。

要件定義では、ロールバックの方法とカナリアの指標を決めます。認証では、SSOと多要素認証を、ログでは承認・監査ログの保持期間を決めます。秘密情報の保管先も、この段階で定めておきます。

PoCの成功条件は、測定できる形にしておきます。たとえば、同じ成果物を開発から本番へ昇格し、失敗時に定めた時間内で切り戻せる状態を条件にします。

フェーズ2：選定によるOSS運用と支援サービスの比較

自社で運用を担うか、支援を受けるかによって、設定の自由度と保守の責任範囲が変わります。

• 自社運用：設定や拡張の自由度が高く、保守は自社の担当になる。
• 支援サービス：導入を早めやすく、契約範囲とOSSとの互換性の確認が必要。
• 引き渡し：設定やIaC、解約時の移管条件の取り決め。

自社で運用する場合は、アップグレード、障害・脆弱性対応、クラウドAPIの変更への追随まで、自社が責任を負います。

比較表では、複数クラウドやVM・Kubernetesへの対応、Blue-Greenとカナリアの展開方式を並べます。承認・監査の仕組みや、RBAC、CI連携の対応も、同じ表で比べます。

運用の負荷や料金体系、内製化の支援も比べます。少数のKubernetesをGit中心で運用する場合は、Argo CDなども候補になります。

Spinnakerを検討する価値が高まるのは、多数のアカウントをまたぐ複雑な昇格や、複数のデプロイ戦略を統一したい場合です。

フェーズ3：設計開発による基盤と標準パイプラインの構築

Spinnaker基盤では、Kubernetes上の実行環境と接続先を一体で設計します。

• 基盤：Kubernetesクラスタ、名前空間、ノード、永続ストレージ、Redis、バックアップ。
• 接続：ネットワーク境界、DeckとGateの公開範囲、Ingress、ロードバランサ、TLS証明書。
• 環境分離：開発・検証・本番を同一クラスタに置くか、別クラスタにするか。

管理者の経路も、設計の対象になります。同一クラスタの場合は、名前空間で分けるだけで十分か、影響の広がりを考えて分けるかを判断します。

設定とパイプラインは、可能な限りGitで管理します。そのためには、命名規則、マニフェストの配置、パラメーターを先に定めておく必要があります。

承認者とロールバック条件も、命名規則とあわせて決めておきます。そうすれば、UIでの手作業だけに頼らずに済みます。

Spinnakerの2026年の公式リリースでは、Halyardが非推奨となり、Kustomizeが標準の導入方法として文書化される方針が示されています（出典: Spinnaker Release 2026.2.0、2026年）。そのため、新規案件では古いHalyard記事を設計書へそのまま転記せず、現在のKustomizeベースの手順で再現性を確認します。

認証と認可は、設計の初期から組み込みます。Fiatでは、アプリにREAD、WRITE、EXECUTEを、クラウドアカウントにREAD、WRITEを設定できます。

実行者にはアプリのEXECUTEを、本番アカウントを変更するサービスアカウントには必要なWRITEだけを付与します。

Fiatは、初期状態では無効になっています。一方で、公式資料も認証設定を強く推奨しています。そこで、PoCでも本番を想定した権限の境界を試します（出典: Spinnaker公式「Authorization (RBAC)」、2026年）。

フェーズ4：テストによる正常系と失敗時の動作の検証

本番に投入する前に、成果物の昇格の経路と、異常時に復旧できるかを確かめます。

• 正常系：成果物取得、マニフェスト検証、開発からステージングへの昇格、本番承認。
• 失敗系：タイムアウト、Webhook・クラウドAPI・通知の失敗、権限不足。
• 展開戦略：Blue-Greenの切り替え・旧環境保持、カナリアの指標・判定しきい値。

デプロイ後のヘルスチェックも、テストの対象にします。各条件は、テストケースに記載しておきます。

障害訓練では、ロールバックで利用者への影響を止められるかを検証します。特にDBのスキーマを変更した場合は、アプリだけを戻しても復旧できません。

後方互換性のある変更、バックアップ、手動復旧の順序も、あらかじめ決めておきます。

監査ログには、実行者や配備先アカウントが残るかを確認します。パイプラインと成果物の記録も対象で、保存期間と閲覧権限も受入条件に含めます。

フェーズ5：稼働による本番サービスへの段階的な拡大

まずは、重要度の低いアプリ1つを限定チームで運用し、対象拡大の判断に使う指標を記録します。

• 実行状況：パイプラインの実行時間と成功率。
• 運用状況：承認待ち時間とロールバック時間。
• 品質：デプロイ後の障害数。

問題がなければ、同じテンプレートで対象を増やします。一括で切り替えず段階的に進めると、テンプレートの不足や権限ミスを早く直せます。

稼働の判定では、夜間や休日の対応体制も確認します。通知先、一次切り分け、手動停止をRunbookにまとめます。緊急権限とバックアップ復旧も、同じRunbookに含めます。

Spinnakerの公式リリース2026.2.0では、Gate向けに失効可能なAPIトークンが追加されました（出典: Spinnaker Release 2026.2.0、2026年）。

この機能を有効にするかどうかは、自社の認証方針に合わせて決めます。そのうえで、有効期限と保管の仕方、トークンを洗い出す方法も決めておきます。

フェーズ6：定着による利用部門と運用の仕組みの整備

開発者が安全にパイプラインを使えるように、標準テンプレートと申請・承認ルールを用意します。運用に関する情報は、ポータルや社内文書にまとめます。

掲載するのは、パラメーターの説明、失敗時の確認手順、問い合わせ先です。新規アプリのオンボーディングは、30分や1時間の作業単位に分けておきます。

特定の担当者しか設定できない状態は、解消しておきます。定着の度合いは、次の指標で定期的に確認します。

• 開発指標：リリース頻度、変更リードタイム、変更失敗率、平均復旧時間。
• 運用指標：ロールバック時間、手作業ステップ数。
• 記録：導入前後の数値の比較と、監査に必要な記録の確認。

確認するのは、速さに加えて、失敗が増えていないかと、監査に必要な記録が残っているかです。運用移管の成果物は、構成図やBOM、バージョンです。Kustomizeマニフェストも、そこに含めます。

運用移管では、IaCやプラグイン一覧、秘密情報の参照方法を引き継ぎます。さらに、アップグレード計画と脆弱性修正期限、SLA、教育記録も対象です。

Spinnakerのシステム開発にかかる費用相場

Spinnakerは、Apache License 2.0のOSSが中心で、一般的なパッケージライセンス料はかかりません。そのため、予算は導入作業とクラウド利用料を合算して考えます。

導入作業の費用には、要件定義、Kubernetes・Spinnaker設計、パイプライン実装が含まれます。セキュリティやテスト、教育も、導入作業の費用に入ります。保守とクラウド利用料は、ランニングコストとして別に見積もります。

ここに示す数字は、公開されている価格表ではありません。公式の最低構成要件、支援会社の導入期間、一般的な業務システムの人月単価をもとにした、2025〜2026年時点の発注予算の推定です。

初期費用の見込み幅

初期費用の見積もり幅は、対象の環境と導入する機能の違いによって変わります。

• PoC：既存Kubernetes、1クラウド、1〜3アプリ、基本パイプライン、開発環境のみなら300万〜800万円程度。
• 本番小規模：認証、RBAC、ステージング・本番、監視、5〜20アプリの導入を含め800万〜1,500万円程度。
• 中規模：複数クラウド・クラスタ、カナリア、監査、教育、移行を含め1,500万〜3,000万円程度。
• エンタープライズ：多数アカウント、多地域、厳格なSLA、既存ITSM・監視連携、内製化支援まで含め3,000万〜5,000万円以上の可能性。

既存のKubernetesとSSOが整っていれば、基盤作業を減らせます。監視、Secrets Manager、IaCも整っている場合は、さらに作業を減らせます。

一方で、アカウント数が多い場合や、アプリごとに方式が違う場合は、設計と移行の工数が増えます。古いCIからの移行やVMの対象化も、工数を増やす要因です。

OpsMxは、オープンソースのSpinnakerのオンボーディングを30日で実現するサービスを公開しています（出典: OpsMx「Continuous Delivery Design and Implementation」）。ただし、これは標準化された導入プロセスの紹介で、すべての日本企業で本番の費用や期間を保証するものではありません。

ランニングコストの内訳

継続運用の予算は、クラウド基盤、周辺サービス、保守運用に分けて把握します。

• クラウド基盤：クラスタ、ワーカーノード、ストレージ、ロードバランサ。
• 周辺サービス：監視・ログ、レジストリ、通信、バックアップ。
• 保守運用：アップグレード、障害・脆弱性対応、改修、教育。

AWS EKSのクラスタ管理料金は、標準サポート中は1クラスタあたり1時間0.10米ドル、延長サポート中は0.60米ドルです（出典: AWS「Amazon EKS Pricing」、2026年確認）。

これはクラスタの管理料金に限られ、EC2などのノードやEBSは別料金です。IPv4やロードバランサ、ログも、別料金になります。

GKEも、1クラスタあたり1時間0.10米ドルです。延長サポート期間には追加料金がかかります（出典: Google Cloud「Google Kubernetes Engine pricing」、2026年確認）。

無料枠やリージョン、StandardとAutopilotの違いによっても料金は異なります。このため、クラウド料金は見積書で分けておきます。

リサーチノートに基づく予算の仮説では、最低要件に近い非本番構成は月10万〜30万円です。本番の冗長化、監視、複数環境を含める場合は、月30万〜100万円程度です。

予算の仮説は、ノード数、ログや通信量、為替、リージョンによって変動します。

保守運用費は、初期費用の年15〜25％程度を仮に置くと、継続費用を見通しやすくなります。対象とする作業の範囲によって、金額は変わります。

範囲には、アップグレードや脆弱性・障害対応、パイプラインの改修が入ります。クラウドAPIの変更や教育も、範囲に含まれます。

24時間対応や専任体制では、月額50万〜200万円程度を仮の予算の幅にできます。公開された定価がないサービスも多いため、対応時間やSLA、改修とアップグレードの回数を示したうえで見積もりを取ります。

Spinnakerの見積もりを取る際のポイント

「環境構築一式」の見積もりでは、各社の金額を比べにくくなります。そこで、作業を分けて依頼し、納品される成果物を確認します。

まずは、対象のアプリとアカウント、クラスタを分けます。そのうえで、デプロイ方式や認証、監視、移行を個別に扱います。テストや教育、保守も、別の項目として分けておきます。

前提を1枚にまとめておくと、金額差の理由を説明しやすくなります。

要件と前提条件の明確化の範囲

見積もりの条件をそろえるため、構成、利用、運用の前提を依頼時点で明記します。

• 構成：クラウド・リージョン、Kubernetesクラスタ数、環境数、アプリ数。
• 連携と利用：月間リリース数、CI、レジストリ、配備対象、利用者・グループ、SSO方式。
• 運用要件：監査ログ、秘密情報、監視メトリクス、可用性、バックアップ、障害対応時間。

分からない項目は「未確定」と記し、調査や要件定義の作業として見積もってもらいます。

依頼する成果物は、構成図、要件定義書、Kustomizeマニフェストです。パイプラインテンプレート、権限一覧、IAMポリシーも、そこに含めます。

監視ダッシュボードやテスト仕様書、Runbookも指定します。教育資料と運用移管計画に加え、ソースコードと設定の納品方法も確認します。

画面上で作るだけの提案と、Git管理・レビュー・再デプロイを含む提案では、初期費用が異なります。

発注先の実績による比較

提案会社は、Spinnakerの本番経験と、周辺基盤を扱う力の両面から見極めます。

• Spinnaker：利用バージョン、Kustomize移行、Fiat RBAC、カナリア分析。
• 基盤：対象クラウド、Kubernetes運用、クラウドIAM。
• 連携・運用：CI・ITSM連携、障害対応の実績。

Spinnaker専業の支援会社のほかに、基盤を扱う会社も候補になります。たとえば、EKS、GKE、Azure Kubernetes Serviceを扱う会社や、ネットワーク、監視、セキュリティを扱う会社です。

ただし、Kubernetesに強いことと、Spinnakerの本番運用の実績は別のものです。このため、質問も対象範囲ごとに分けます。

相見積もりでは、同じPoC範囲を各社に示します。初期構築とアプリ導入、移行を分けてもらい、教育、保守、クラウド費用も分けてもらいます。

成功事例では、検証できるKPIを確認します。たとえば、対象アプリ数やリリース時間、障害率が該当します。導入日と契約範囲も、確認の対象です。

OSSのソースコードとIaC、パイプラインの所有者を確認します。プラグイン設定を含め、支援が終わったときに自社へ引き渡せるかどうかは、契約前に決めておきます。

セキュリティと運用リスクの見積もり

リスクの見積もりでは、公開経路と実行権限を起点に、情報保護から監査までを定義します。

• 接続：Deck・Gateの外部公開を避け、TLSとネットワーク分離を行う。
• 権限：クラウドサービスアカウントへの最小権限の付与。
• Fiat：利用者、グループ、サービスアカウント単位でのREAD、WRITE、EXECUTEの確認。

Fiatを設定せず本番へ進むと、想定より多くの利用者が閲覧・変更・実行できる可能性があります。

秘密情報や個人情報は、パイプライン定義やログに混入する可能性があります。Webhookや成果物も、経路として注意が必要です。

RFPには、Secrets ManagerやVaultの参照と、ログのマスキングを含めます。署名付き成果物や、依存ライブラリ・コンテナのスキャンも含めます。

SBOMと脆弱性の修正期限も記載します。監査ログの保存期間と、緊急時のブレークグラス手順も、あわせて記載します。

金融や医療などでは、顧客との契約や業界ガイドラインを確認します。そのうえで、委託先の管理、クラウドの所在地、越境移転の要件も押さえます。

よくある質問

費用、既存ツールとの関係、運用体制に関する質問を並べています。自社のアプリ数やクラウド構成に当てはめ、PoCと本番導入を分けて検討してください。

SpinnakerはOSSなので無料で導入できますか？

ライセンス料が基本的に無料でも、本番運用まで無料になるわけではありません。基盤や保守、教育などの費用が必要です。

費用には、基盤の構成要素と、運用に関わる作業の両方が含まれます。基盤では、Kubernetesやノード、ストレージ、Redisが対象です。運用では、監視やログ、保守、アップグレード、教育が対象になり、ネットワークや認証も含まれます。

検証環境は、小さく始められます。一方で、本番ではRBAC、冗長化、監査、障害対応まで含めた別の見積もりが必要です。

SpinnakerとArgo CDやJenkinsはどのように使い分けますか？

選定では、CIとCDの役割、配備対象、GitOpsの運用範囲を基準にします。

• CI：Jenkins、GitHub Actions、GitLab CIが、ビルド、テスト、成果物作成を担います。
• Spinnaker：複数環境への昇格や承認、Blue-Greenやカナリア、ロールバックを担い、CIと組み合わせるCD。
• Argo CD：KubernetesとGitOpsを中心に、宣言的な状態同期を小さく始めたい場合の選択肢。

複数クラウドやVM、複雑な承認・展開戦略を横断する場合は、Spinnakerを候補に比べます。少数のKubernetesクラスタをGitを正として運用する場合は、Argo CDを検討します。

Spinnakerの導入にはどのくらいの期間が必要ですか？

Spinnakerの導入期間は、PoCか本番かに加え、対象アプリ数や基盤、移行対象の規模によって変わります。

• PoC：既存Kubernetesで1クラウド、1〜3アプリなら1〜2か月。
• 本番小規模：認証、RBAC、監視、複数環境を含めると2〜4か月。
• 中規模：複数クラウドや移行、教育まで含めると4〜6か月。
• エンタープライズ：6〜12か月以上。基盤の成熟度、承認・監査要件、クラウドアカウント数、移行対象のばらつきで変動します。

PoCと全社展開の期間は、同じ数字で約束しないことが大切です。

まとめ

Spinnaker開発は、成果物を安全に昇格させるリリース基盤を業務へ定着させるプロジェクトです。要件整理では、アプリ、クラウド、頻度を明確にします。SLO、承認、監査についても、同じ段階で明確にします。

選定では、Argo CDなども含めて必要性を判断します。設計では、Kubernetesと認証、RBACを扱います。IAMやSecrets、監視、バックアップも、設計の対象です。

6フェーズでの小さな開始と段階的な拡大

進め方は6つのフェーズで、要件整理、選定、設計開発、テスト、稼働、定着の順に進みます。まずは1アプリ・1クラスタで、成果物の取得からロールバックまでを検証します。

次に、標準テンプレートと権限を用意して対象を増やします。導入前後では、リードタイムや変更失敗率、平均復旧時間を比べます。さらに、ロールバック時間と監査ログの完全性も確かめます。

見積もり前の自社チェックリスト

見積もりの前提をそろえるため、発注前に環境、デリバリー、運用の条件を整理します。

• 環境：クラウド、クラスタ、対象アプリ、環境数。
• デリバリー：CI、レジストリ、認証、RBAC。
• 運用：監視、秘密情報、監査。
• 費用と運用：初期費用とランニングコストを分けた、移行・教育・保守の前提。

この前提をもとに相見積もりを取ります。そのうえで、バージョンとKustomize移行の実績、OSS設定やIaCの引き渡し範囲を確認します。

障害時にどこまでを誰が受け持つかを確認しておくと、導入後の追加費用と属人化を抑えやすくなります。

▼全体ガイドの記事
・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を創業。