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

Argo CDのシステム開発は、要件整理から定着までを6つのフェーズに分けて、順に進めます。各段階の終了条件を決めながら進めると、変更の再現性と復旧のしやすさにつながります。

全体像は、下の完全ガイドの記事もご覧ください。

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

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

Argo CDのシステム開発の全体像

Argo CDのシステムは、Gitリポジトリ、CIとイメージレジストリ、Argo CD、Kubernetesクラスタを組み合わせた基盤です。監視・通知や認証、秘密情報の管理も、構成の一部として含めて考えます。

設計の中心は、Git上の望ましい状態とクラスタで動いている状態を比べ、差分を検知して同期する流れです。

Argo CDが管理する範囲と管理しない範囲

Argo CDが担うのは、Git上のマニフェストやHelm、Kustomizeから生成したKubernetesリソースを反映するところまでです。ソースコードのビルドやデータベースの業務設計は、Argo CDの担当には含まれません。

また、クラスタのノード障害や平文Secretの管理も、Argo CDが自動で解決する対象ではありません。CIは、テスト、イメージのビルド、脆弱性スキャンを担います。署名とレジストリ登録もCIの役割です。

発注前には、どこまでを誰が受け持つかを一枚の図にまとめます。図では、変更が承認されてから各環境へ届く経路と、緊急時の操作の扱いを示します。

• 通常時：Pull Request後にCIがテストとSBOMを生成し、承認後に環境マニフェストを更新してステージングへ同期する。
• 本番反映：運用承認を得てから、本番へ同期する流れ。
• 緊急時：kubectlの利用者、権限、記録方法、事後レビューの取り決め。

業務システムに向くケースと向かないケース

Argo CDが合うかどうかは、構成管理の方法と、期待する業務成果から判断します。

• 導入しやすい条件：コンテナ化済み、または移行計画があり、構成をコードとGitで管理できること。
• 効果を期待できる状況：環境差分や手作業のリリースが増えた、監査証跡を残したい、複数クラスタへ同じアプリを展開したい。
• 先に必要な作業：単一の古いサーバーへ手作業で配置している場合は、コンテナ化、ネットワーク、データ移行、可用性設計を先に行う。
• 導入範囲の判断：変更の再現性、承認の透明性、復旧時間の短縮を小さな対象で測れない場合は、導入範囲を広げない。

Argo CDのシステム開発の進め方

移行は、全社の全クラスタを対象にする前に、1つのサービスをMVP（Minimum Viable Product）として検証するところから始めます。受入条件を満たしたあとで、対象を少しずつ増やすのが安全です。

要件整理から定着までを6つのフェーズに分け、段階ごとに終了条件を決めておきます。そうしておけば、設定作業だけが先に進み、運用設計が残る事態を防げます。

フェーズ1：要件整理による目的と現状の把握

最初の要件整理では、対象と現行の運用を把握して、導入の条件をそろえておきます。

• 対象と体制：対象業務、アプリケーション数、環境数、クラスタ数、リリース頻度、停止許容時間、利用者、承認者を一覧にする。
• 現行のリリース経路：現状の工程と、そこに含まれる手作業を洗い出す。
• 導入条件：Gitの扱いから復旧担当まで、設計の前提になる項目を決める。

工程は、コードの変更からデプロイまでの流れに加えて、動作確認と障害時の戻し方まで、時系列で書き出します。

そのうえで、手作業のkubectlや環境ごとの設定コピーを確かめます。承認を口頭やチャットだけで済ませている箇所も、ここで明らかにします。

確認項目は、Gitを変更の正本にできるかと、本番同期を自動と手動のどちらにするかです。RTO・RPOと監査ログの保存年数も、ここで固めます。Secretの保管庫、CIの担当範囲、クラスタ障害時の復旧担当者も、決めておきます。

Kubernetesへそのまま移行できない既存システムは、コンテナ化や基盤刷新を含む別の工程として見積もります。

フェーズ2：Argo CDと周辺構成の選定

構成は、どこまでを自社で運用するかと、環境の条件に合わせて比べます。

• 自己運用のOSS版：クラウドやオンプレミスをまたぐ自由度がある一方で、可用性、更新、認証、クラスタ間接続、バックアップを自社で担う。
• マネージド構成：運用負担を減らしやすい。対応クラウド、認証方式、機能、データの所在、課金単位を確かめる。
• 構成管理方式：環境差分が単純ならKustomize、再利用パラメータやチャートが多いならHelmを候補にする。
• 複数クラスタへの展開：同じ型のアプリを複数クラスタへ展開する場合は、ApplicationSetを検討する。

ApplicationSetは、テンプレートから複数のApplicationを生成する仕組みで、公式ドキュメントも生成機能のセキュリティへの注意を示しています。

商用サポート付きの構成としては、マネージドKubernetesとArgo CDの組み合わせや、OpenShift GitOpsなどが候補に挙がります。

ApplicationSetの生成権限が広いと、意図しない環境へ展開できてしまいます。そのため、AppProjectとRBACも設計します。

フェーズ3：GitOpsの設計と開発

GitOpsの設計では、変更がどの経路を通るかを、権限や秘密情報の扱いと合わせて一続きで決めます。

• リポジトリと環境：Gitの分け方、ブランチとPRの承認、環境別設定、Application、namespace、接続を設計する。
• 同期ポリシー：環境のリスクに応じて、自動同期にするか、承認後の手動同期にするかを決める。
• Secretとイメージ：平文のSecretはGitに置かず、保管方法を選ぶ。イメージはタグに頼らず、ダイジェストで固定する。
• CIの受入条件：脆弱性スキャン、署名、SBOM、承認済みレジストリの利用を含め、SBOMの作成者、受け渡し方法、脆弱性通知期限をRFPに記す。
• 受け取る資料：構成図、リポジトリ構成図、権限一覧、環境別マニフェスト、Secret・CI/CD連携設計、監視設計、バックアップ・復旧手順の初版。

ApplicationSetやAppProjectを含めた命名規則も決め、Applicationと対応させます。

pruneを有効にすると、Gitから削除したリソースはクラスタからも消えます。そのため、対象範囲と例外を先に確かめておきます。

Secretの方式は、External SecretsやVaultを含む候補から比べます。クラウドのSecret ManagerやSOPSも候補になります。

経済産業省は2025年9月、SBOM共有に関する国際ガイダンスへの共同署名を公表しました。特に、規制対象のデータや委託先が含まれる場合は、SBOMの要件をRFPに記しておきます。

Gitからクラスタまで届く経路全体を、受け取る資料で確かめます。

フェーズ4：同期・障害・権限のテスト

正常に同期する場合に加えて、障害や権限の例外も試験します。

• 障害の再現：Git差分、同期失敗、クラスタ側の手動変更、脆弱性検出、Secret取得失敗、権限不足、ネットワーク断、Argo CD自体の障害を試す。
• 同期の受入確認：承認前後に本番へ反映されないこと、指定外のnamespaceへ展開できないこと、OutOfSyncの検知、ロールバックを確かめる。
• 測定する受入条件：同期時間、同時に処理するApplication数、失敗通知時間、復旧時間、監査ログの内容、バックアップ復元時間を定める。
• 権限の検証：担当者ごとの実アカウントで権限を試し、admin権限を全員には配らない。

RBACでは、Applicationのほかに、ログ閲覧、exec、ApplicationSetなどの権限を分けられます。そこで、開発者、承認者、運用者、監査担当者それぞれの操作を試します。

フェーズ5：段階的な稼働と切り戻しの準備

まずは影響の小さい対象から稼働させ、業務上の受入条件と切り戻し手順を確かめます。

• 小規模から稼働：影響の小さいアプリを本番へ移し、低リスク業務で同期、通知、ロールバック、運用連絡を確かめる。
• 重要業務の切り替え：同期方式を選び、DBスキーマとアプリの切り替え順を検証する。
• 業務シナリオの確認：同期成功だけで判断せず、ヘルスチェックに加えて業務トランザクションを確かめる。
• 切り戻し手順：Gitのマニフェストとデータベースの戻し手順を分け、緊急のkubectl変更をGitに反映するか元に戻すかを決める。
• 稼働判定：未解決障害、監視の欠落、未訓練の復旧手順、権限例外、ベンダー連絡方法を確かめ、技術面と業務面を分けて判断する。

方式の候補には、PreSync・PostSync hookとSync waveがあります。Blue-GreenやCanaryも候補に入ります。

フェーズ6：運用とチームへの定着

稼働後は、監視、更新、評価、教育を定常業務として組み込んでおきます。

• 日常運用：OutOfSyncやDegradedの検知、通知の一次受け、Gitレビュー、更新、脆弱性対応、復元、障害訓練を組み込む。
• 互換性の管理：対応製品と認証基盤を一覧にし、検証したあとで本番を更新する。
• 評価指標：リリースリードタイム、失敗デプロイ率、復旧時間、手動kubectl件数、未レビュー変更数、脆弱性修正期限、復元テスト実施率を追う。
• 担当者教育：開発者にはGitの変更方法、運用者には同期失敗と切り戻し、管理者には費用と権限の見方を伝える。
• 定着の終了条件：Runbookや設計書を納品した時点で終えず、担当者が一人で定型作業を実施できることを確かめる。

対応の対象は、Kubernetes、Helm、Kustomizeです。OpenShift、Gitホスティング、認証基盤も対象に含まれます。各バージョンの対応状況を確かめ、検証環境で更新をリハーサルしてから本番へ進めます。

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

自己運用版のArgo CDはオープンソースのため、ソフトウェアのライセンス料は原則かかりません。ただし、実際の予算には、基盤や運用に必要な費用が加わります。

基盤の費用には、Kubernetesやノード、ロードバランサ、Gitホスティング、レジストリが含まれます。ログ・監視、バックアップ、SSOも、費用の対象です。設計、検証、教育、保守も対象になります。

ここで示す金額は、業務システムへのGitOps導入費の推定で、Argo CD単体の定価ではありません。

規模別の初期費用と期間の目安

初期費用と期間は、対象の規模や構成によって異なります。

• PoC・検証：100万〜300万円、1〜2か月が目安。
• 小規模本番：300万〜800万円、2〜4か月程度。
• 中規模基盤：800万〜1,800万円、4〜8か月程度が目安。
• エンタープライズ：1,800万〜5,000万円以上、8〜18か月以上の場合がある。

PoCでは、1クラスタと1〜5個程度のApplicationを対象に、Git連携と手動同期、簡易監視を検証します。構成管理はHelmかKustomizeを使います。

小規模本番は、1〜2クラスタ、10〜30アプリを想定します。対象には、SSO・RBAC、Secret連携、バックアップのほか、CI/CD接続と運用手順も入ります。

中規模基盤は、3〜10クラスタ、30〜100アプリを想定します。ApplicationSetや高可用性を含み、複数アカウント、監査・通知、段階リリースも対象になります。

エンタープライズの推定には、ハイブリッド環境や10クラスタ以上、100アプリ以上の規模が含まれる場合があります。DR、厳格な承認、24時間運用移管が加わることもあります。

金額と期間は、クラスタ数や既存Kubernetesの有無で変わります。可用性やSLA、移行対象の状態も、変動の要因です。

ランニング費と公開料金の分け方

ランニング費は、クラウド基盤費、運用体制、公開サービスの料金を分けて見積もります。

• 自己運用の基盤費：小規模は月10万〜50万円程度、中規模は月50万〜150万円程度が予算の起点。クラウド利用量と運用体制からの推定である。
• 運用と保守：運用体制やサービス水準も見積もりに含める。
• 保守の対象：更新、脆弱性対応、GitOpsリポジトリの変更、障害訓練が含まれるかを確かめる。
• AWSの公開料金例：100 Applicationを730時間運用した例のArgo CD部分は月131.40ドル。
• 総保有コスト：為替や契約条件、基盤費も含めて費用を比較する。

運用代行、SLA、複数リージョン、24時間監視を含めると、月100万〜300万円以上になる場合があります。

業務アプリケーションの実行にかかるコンピュート費は、別に計上します。保守費は、初期開発費の年15〜25％を予算枠とします。

AWSのEKS Capability for Argo CDは、基本料金とApplication数に応じた時間課金です。

上記の例では、基本料金が21.90ドル、Application利用料が109.50ドルです。

1ドル150円で仮置きすると約2万円ですが、為替やリージョン、契約条件によって変わります（出典：AWS「Amazon EKS Pricing」、2026年確認）。

EKSクラスタやノードのほか、EBS、ロードバランサ、ログも別料金です。OSS版が無料であることと、基盤や人件費を含む総保有コストは、分けて比べます。

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

ツールのインストール費だけで比べると、案件の実態を見誤ります。費用は、クラスタ、Application、環境といった単位に分けて見ます。利用者やリポジトリも、分解の単位になります。

認証やSecret、監視の費用に加えて、移行、教育、保守の費用も確かめます。そのうえで、固定費と追加費用を分けます。「環境構築」「CI/CD連携」のように作業名だけが並ぶ見積もりには、受入条件と受け取る資料を補ってもらいます。

見積もり前にそろえる情報

複数社が同じ条件で見積もれるように、対象の環境と既存の資料をそろえておきます。

• 対象と利用環境：アプリケーション数、クラスタ数、環境数、1週間または1か月のリリース回数、Git・CI・レジストリの製品を共有する。
• 運用と要件：Kubernetesの運用者、認証基盤、監視・チケット、Secret保管先、オンプレミス接続、データ機密度、RTO・RPOを伝える。
• 既存資料：マニフェスト、Helmチャート、Dockerfile、ネットワーク図、障害記録を渡して、調査の工数を抑える。依頼文では、PoCと本番移行を分けて書く。
• 完了条件と契約：PoCと本番の完了条件を分け、追加単価、設計条件、引継ぎ方法を記す。

PoCでは、1クラスタと3アプリを使い、同期、ドリフト検知、ロールバックを確かめます。本番では、SSO・RBACやSecret連携を完了条件に含め、監査ログ、バックアップ復元、更新手順も加えます。

一括契約の場合でも、Application数やクラスタ数が増えたときの単価を明記します。追加設計の条件と、作業の引継ぎ方法も書いておきます。

発注先の技術力と担当範囲

発注先が、必要な技術領域と運用の責任を一貫して担えるかを確かめます。

• 対応範囲：Kubernetes設計、クラウド・オンプレミス接続、CI/CD、認証、Secret、監視、バックアップ、コンテナ化、運用移管を確かめる。
• 実績の再現性：公開実績が自社と同じクラスタ数、データ規制、可用性、リリース頻度とは限らない。実績の有無と、案件での設計・運用能力を分けて評価する。
• 役割分担：SI、マネージドサービス、エンタープライズ基盤、商用プラットフォームを比べ、自社に残す自由度と外部へ任せる運用を照合する。

AWSは2025年12月の公式ブログで、EKS Capability for Argo CDの運用負担をAWS側へ寄せる構成を説明しています。その対象には、スケーリングや更新、クラスタ間通信などが含まれます。

OpenShift GitOpsはArgo CDを基盤とし、OpenShiftとの統合とエンタープライズサポートを提供します。

出典は、2025年に公開されたAWSの公式ブログ「Deep dive: Streamlining GitOps with Amazon EKS capability for Argo CD」です。

もう一つの出典は、Red Hatの「OpenShift GitOps」で、2026年に確認しました。

契約と運用リスクの見積もりへの組み込み

契約では、保守の対象と、事故が起きたときの責任分担を具体的に定めます。

• 保守範囲：更新、脆弱性パッチ、障害時の一次対応、復元、監視調整、Gitリポジトリの整理、アプリやクラスタの追加を確かめる。
• 対応条件：24時間365日対応なら、対応時間、目標復旧時間、重大度、エスカレーション、代替連絡先を契約書に記す。
• 納品と委託：設計書、IaC、マニフェスト、Runbook、監視設定、ソースコードの納品、再委託、データ保管場所、アクセス期限、ログ保存期間を確かめる。
• セキュリティ責任：インシデント報告、OSSライセンス、SBOMの作成・受渡し、脆弱性通知期限、パッチ適用責任を定める。

広い権限は、誤同期や情報閲覧の範囲を広げます。価格に加えて、事故時に誰がどの記録をもとに対応するかも比べます。

よくある質問（FAQ）

導入の前には、既存システムとの適合性、費用、運用体制についての質問が集まりがちです。「OSSだから無料」「導入すれば自動で安全」という理解は、基盤費用や、誰が何を担うかを見落とす原因になります。

既存のVMやオンプレミス業務システムでもArgo CDを導入できますか？

導入はできますが、Argo CDが直接VMへファイルを配置するわけではありません。そのため、対象アプリをコンテナ化し、Kubernetesで実行できる状態にする工程が必要です。

既存資産の移行やデータベース、ネットワーク、可用性、監視の要件が大きい場合は、Argo CDの導入費と基盤移行費を分けて見積もります。

Argo CDはOSSなのでシステム開発費も無料ですか？

無料ではありません。自己運用版のライセンス料は原則不要です。

ただし、ライセンス料がかからなくても、基盤と運用の費用は残ります。内訳は、基盤、運用、マネージドサービスの利用、比べ方の順に整理できます。

• 基盤：Kubernetesやノード、ログ、バックアップ、認証が対象。
• 運用：設計、テスト、教育、保守が費用になる。
• マネージドサービス：AWSなどでは、CapabilityやApplicationの利用料に加えて、クラウド基盤費が発生する。
• 比べ方：初期費と月額費を分けて、Application数、クラスタ数、SLAを前提に比べる。

JenkinsやGitHub ActionsなどのCIはArgo CDに置き換わりますか？

原則として置き換えるのではなく、役割を分けて考えます。CIは、テストやイメージのビルド、脆弱性スキャンを担います。署名とレジストリ登録もCIの役割です。

Argo CDは、Gitで承認されたマニフェストをKubernetesへ同期する役目を担います。CIから本番へkubectlする経路を残す場合は、緊急時の例外として、権限、監査、事後レビューを定めます。

Argo CDのシステム開発は何か月かかりますか？

PoCは1〜2か月、小規模本番は2〜4か月、中規模の複数クラスタ基盤は4〜8か月が目安です。

既存VMのコンテナ化やオンプレミス接続、DR、厳格な監査、24時間の運用移管を含めると、8〜18か月以上になる可能性があります。

期間は、設定の量よりも、対象アプリや運用要件の整理、テスト、教育に左右されます。

まとめ

進め方で押さえるべき要点

Argo CDのシステム開発は、Argo CDを入れるだけの作業ではありません。

GitやCI、Kubernetesを、認証、Secret、監視、承認、障害復旧とつなげて、一つの運用に組み立てる取り組みです。

要件整理では、対象業務とリリース経路を明らかにします。クラスタ、Application、停止許容時間、責任者を整理し、目的に合う構成を選びます。

発注前に確認する最終ポイント

発注前には、進行手順と費用の前提、検証条件を一緒に確かめます。

• 進め方：要件整理、選定、設計開発、テスト、段階稼働、定着の6フェーズで進める。
• 費用の目安：PoC100万〜300万円、小規模300万〜800万円、中規模800万〜1,800万円、エンタープライズ1,800万〜5,000万円以上。
• 総保有コスト：無料のOSSだけで判断せず、基盤、開発、運用人件費、更新、セキュリティ、教育を含めて比べる。
• 本番展開：最初から全社展開を目指さず、1サービスで同期、ドリフト検知、権限、ロールバック、復元を試す。受入条件を満たしてから範囲を広げる。
• 運用の備え：PR承認、Argo CDのRBAC、Secret、SBOM、脆弱性対応、Runbook、教育の準備。

費用は、クラスタ数やApplication数、既存基盤の条件で補正します。可用性、監査、保守範囲も、補正の材料になります。

GitのPR承認ルールと、Kubernetesの最小権限を、具体的に決めておきます。

これらがそろうと、導入の効果を業務の継続性と説明可能性へつなげやすくなります。

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

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