Crossplaneとは？Kubernetesを制御基盤にするクラウドインフラ管理ツールの仕組みと採用判断を実装者目線で解説【2026年版】

Crossplaneは、KubernetesのAPIを拡張し、クラウドのインフラをKubernetesのカスタムリソース（CRD）として宣言的に管理するためのオープンソースの制御基盤です。AWSやGoogle Cloud、Azureのデータベースやネットワークを、kubectl applyで作るリソースとして扱えるようにする点に核心があります。この記事では、Provider・Managed Resource・Composition・XRといった構造、Kubernetesの制御ループを使ってドリフトを自動修正する仕組み、Terraformとの実行モデルの違い、そして自社のチームがCrossplaneを採用すべき条件と見送るべき場面までを、実装者の目線で整理します。2025年11月にCNCFのGraduated（卒業）プロジェクトへ昇格し、v2系で大きく設計が変わった最新の位置づけも踏まえた内容です。

まとめ：クラウドインフラをKubernetes流に宣言管理するCrossplaneの位置づけ

Crossplaneの核心は「クラウドインフラの構築を、Kubernetesの制御ループにそのまま乗せる」点にあります。Terraformのようにコマンドで都度applyするのではなく、Providerと呼ばれる拡張がクラウドAPIを操作し、コントローラが宣言した状態を常時保ち続ける構造です。手動でデータベースの設定を変えられても、宣言と食い違えば自動で元へ戻します。

結論を先に示します。すでにKubernetesを本番運用していて、社内の開発チームに「セルフサービスでインフラを払い出す窓口（内製プラットフォーム）」を用意したいチームには、Crossplaneが噛み合う技術です。逆に、Kubernetesを持たない小規模チームや、単発のインフラ構築を手早く済ませたい場合はTerraformのほうが向きます。Crossplaneはインフラの払い出しを担い、アプリのデプロイはArgoCDと組み合わせる構成が実務では定番です。以下で仕組みと判断基準を掘り下げます。

CrossplaneがKubernetesをコントロールプレーンに変える仕組み

Crossplaneは、Kubernetesクラスタ自体を「クラウドインフラの操作盤（コントロールプレーン）」に作り替えるソフトウェアです。クラスタにインストールすると、外部のクラウドリソースをKubernetesのオブジェクトとして表現するためのCRDが追加され、以降はKubernetesのAPI越しにインフラを操作します。外部のCLIやステートファイルを持たず、クラスタ内のコントローラが実体を管理する点が、従来のIaCツールとの構造上の違いです。

Crossplaneの4層構造｜Provider・MR・Composition・XR

Crossplaneの構成要素は、大きく4つの層で理解できます。ProviderはAWS・GCP・Azureなど各クラウドのAPIを操作する拡張機能で、必要なクラウドの分だけインストールします。Managed Resource（MR）は、RDSインスタンスやS3バケットのようなクラウド上の個々の資源を1対1で表すリソースです。Compositionは複数のMRを束ねて「1つの意味のある単位」に組み立てる設計図で、Composite Resource（XR）はその設計図から生まれる合成リソースにあたります。

この層構造の利点は、抽象化の粒度を自社で決められる点です。たとえば「本番用データベース」という1つのXRを定義し、その裏で実際にはRDS本体・サブネットグループ・パラメータグループ・セキュリティグループを一括で払い出す、といった社内向けの部品を作れます。開発者はクラウドの詳細を知らずに、抽象化されたXRを1つ書くだけで済みます。

継続的リコンサイルでインフラのドリフトを自動修正する制御ループ

Crossplaneの動作の肝は、Kubernetesのリコンサイルループ（調整ループ）をインフラ管理に転用している点です。コントローラは宣言された状態と実際のクラウドの状態を常時突き合わせ、差分があれば宣言側へ寄せ続けます。誰かがクラウドのコンソールで手動設定を変えても、Crossplaneがその変更（ドリフト）を検知し、宣言した仕様へ自動的に戻します。

ここが運用上の分かれ目です。Terraformはterraform applyを実行した瞬間だけ状態を合わせ、次のapplyまでの手動変更は放置されます。Crossplaneは既定で常時監視し続けるため、「気づかないうちに本番設定が書き換わっていた」という事故を構造的に防ぎやすい設計です。一方で、常時制御が働くぶん、意図した手動変更まで巻き戻すことがあり、変更経路をGit経由に統一する運用設計が前提になります。

Crossplaneを構成する主要な部品とv2で変わった設計

Crossplaneを実装で扱うには、リソースの種類と役割を押さえる必要があります。中核の6つを整理し、そのうえで2025年に登場したv2で何が変わったかを見ていきます。バージョンや仕様は更新されるため、導入時点で公式ドキュメントの最新版を確認してください。

Crossplaneの主要リソース6種と各リソースの役割の対応

実装で登場する主なリソースは次のとおりです。どれがクラウド実体に対応し、どれが抽象化の道具かを分けて捉えると構造が見えます。

実務では、プラットフォーム担当がXRD（CompositeResourceDefinition）とCompositionで社内向けの部品を用意し、アプリ開発者は完成したXRを書くだけ、という分業が基本形です。Composition Functionは、単純なフィールドの対応付けでは表現しきれない条件分岐や繰り返しを、プログラムのパイプラインとして書けるようにする部品で、v2では合成ロジックの標準的な書き方に位置づけられています。

Crossplane v2で変わった点｜名前空間化・任意リソース合成・Claims廃止

2025年に登場したCrossplane v2は、設計思想を「インフラ専用」から「アプリの制御基盤」へ広げた版です。主な変更は3点あります。第一に、XRとMRが名前空間（Namespace）付きになりました。これにより、チームやテナントごとにアクセス権を分けるマルチテナント構成が組みやすくなっています。

第二に、Compositionが任意のKubernetesリソースを合成できるようになりました。従来はCrossplane由来のリソースしか束ねられませんでしたが、v2ではRDSのようなMRとDeploymentのような素のKubernetesリソースを1つのXRにまとめられます。インフラとアプリを同じ単位で払い出せる設計です。第三に、v1では必要だったClaimという中間の抽象が廃止され、XRを直接使う流れに単純化されました。さらに、必要なMRだけを有効化するアクティベーションの仕組みで、大量のCRD導入によるクラスタの負荷も抑えられます。

CrossplaneとTerraform・ArgoCDの役割の違い

Crossplaneの位置づけは、比較対象を並べると明確になります。特にTerraformとの違いを実行モデルで捉えると、どちらを選ぶかの判断がつきます。ArgoCDとは競合ではなく組み合わせる関係です。

Terraformとの違い｜都度applyの実行モデルと継続制御の実行モデル

TerraformとCrossplaneは、同じ宣言的IaCでも動作の前提が異なります。TerraformはCLIツールであり、planで差分を確認しapplyを実行した時点だけ状態を合わせます。対してCrossplaneはクラスタ内で常時動くコントローラで、宣言状態を保ち続ける動作です。この違いは、ドリフトの扱いと運用体制に直結します。

Terraform自体はコントロールプレーンではなく、各クラウドの操作盤を叩くCLIです。Kubernetesを運用しておらず単発でインフラを組みたいなら、HCP Terraform（旧Terraform Cloud）の機能と料金の解説で扱うようなTerraform系の選択肢のほうが素直に噛み合います。両者は排他ではなく、既存のTerraform資産を残しつつ継続制御が要る部分だけCrossplaneへ寄せる併用も現実的です。

ArgoCDとの棲み分け｜インフラのCrossplaneとアプリCDのArgoCD

ArgoCDはGitOpsによる継続的デリバリー（CD）のツールで、Gitに書いたマニフェストをクラスタへ反映させる役割を担います。CrossplaneはそのマニフェストでクラウドインフラのXRを宣言する側です。両者は補完関係にあり、「ArgoCDがGitの状態をクラスタへ同期し、Crossplaneがそのインフラ宣言を受けてクラウド資源を払い出す」という分業が定番構成になります。GitOpsによるCDの仕組みはArgoCDとGitOpsによるKubernetes継続的デリバリーの解説で補完できます。Crossplaneをこの構成に組み込むと、アプリもインフラも同じGitフローで管理でき、変更経路を一本化できる構成です。

Crossplaneを採用すべき条件と、導入を見送るべきチームの見極め

ここが実装者にとっての本題です。Crossplaneは万能なインフラ管理ツールではありません。噛み合うチームと過剰になるチームがはっきり分かれます。条件を付けて判断を言い切ります。

Crossplaneが噛み合い利点がよく効くチームに共通する条件

次の条件が揃うほどCrossplaneの利点が効きます。

• すでにKubernetesを本番運用しており、クラスタの運用体制と権限管理が固まっている
• 複数の開発チームに、インフラをセルフサービスで払い出す社内プラットフォームを提供したい
• クラウド設定のドリフトを常時是正し、変更経路をGit経由に統一したい

この場合、XRDとCompositionで自社独自のインフラAPIを定義し、開発者にはクラウドの詳細を隠した窓口を渡せます。こうした内製プラットフォームづくりの文脈はPlatform Engineeringとは何かと導入の進め方の解説で全体像を押さえられます。Crossplaneはその実装手段の1つという位置づけです。

Crossplaneを見送るべきチームと導入が過剰投資になる場面

一方で、次のケースではCrossplaneは過剰投資になります。導入しないほうが健全です。

第一に、Kubernetesを運用していないチームです。インフラ管理のためだけにクラスタを立て、その運用まで抱えるのは本末転倒で、この場合はTerraformで足ります。第二に、インフラの構築が単発・少数で、継続的な是正やセルフサービス化の必要がないケースです。制御ループの常時稼働と抽象化部品の整備というコストに見合いません。第三に、5〜10名規模でプラットフォーム専任を置けないチームです。XRDやCompositionの設計・保守を担う人手がないと、抽象化がかえって負債になります。

Crossplaneを支えるのは、Kubernetesクラスタ本体と、その下のクラウドインフラの設計・運用です。ここが不安定だと払い出す資源も安定しません。自社での構築や運用に不安がある場合は、AWS・Google Cloud・Azureでのインフラ構築・移行・運用支援のように、クラウド基盤の設計から一貫して相談できる体制を組んでおくと、Crossplaneを載せる土台を含めて安定します。プロジェクトはNike・SAP・IBM・NASA Science Cloudなど70社以上の公開採用実績があり、CNCFの卒業プロジェクトとして成熟度は高い水準にあります。

Crossplaneの導入・運用でよくある質問と実装者目線からの回答

Crossplaneの導入検討でよく挙がる疑問に、実装者の観点で簡潔に答えます。

CrossplaneとTerraformはどちらを選ぶべきですか？

Kubernetesを本番運用していて、インフラを継続的に是正・セルフサービス化したいならCrossplane、単発や広範なインフラ構築が主目的でKubernetes前提を置きたくないならTerraformが無難です。Crossplaneは常時制御ループでドリフトを自動修正する一方、クラスタの運用が前提になります。既存のTerraform資産を残したまま、継続制御が要る領域だけCrossplaneに寄せる併用も選べます。

Crossplaneを使うにはKubernetesが必須ですか？

必須です。CrossplaneはKubernetesのAPIを拡張し、クラスタ内のコントローラでインフラを管理する構造のため、動作基盤としてKubernetesクラスタが要ります。逆にKubernetesを運用していない環境でCrossplaneのためだけにクラスタを立てるのは、運用負担が過剰になりがちです。その場合はTerraformなどKubernetes非依存のツールが向きます。

Crossplaneの学習で最初に押さえるべき概念は何ですか？

Provider・Managed Resource・Composition・XRの4つの関係です。Providerがクラウドを操作し、Managed Resourceが個々の資源を表し、Compositionがそれらを束ね、XRが払い出しの実体になる、という流れをつかむと全体が見えます。そのうえで、自社APIの型を決めるXRDを理解すれば、独自の抽象化を組み始められます。

Crossplane v2では何が変わりましたか？

主な変更は、XRとManaged Resourceの名前空間対応、任意のKubernetesリソースを合成できる拡張、そしてv1にあったClaimという中間抽象の廃止です。v2はインフラ専用から「アプリの制御基盤」へ用途を広げた版で、インフラとDeploymentのようなアプリ資源を1つのXRにまとめて払い出せます。バージョンは更新が続くため、導入時に公式の最新版で仕様を確認してください。

Crossplaneはドリフトを自動で直しますか？

既定で自動修正します。コントローラが宣言状態と実際のクラウド状態を常時突き合わせ、手動で変更された設定を宣言側へ戻します。これは事故防止に効く一方、意図した手動変更まで巻き戻すため、変更はGit経由に統一する運用設計が前提です。緊急の手動対応が必要な場面では、対象リソースの管理ポリシーを一時的に切り替える運用も検討します。

関連記事

• Kubernetesとは？仕組み・Dockerとの違い・読み方を解説：Crossplaneが動作基盤とするKubernetesの前提を押さえられます
• ArgoCDとは？GitOpsによるKubernetes継続的デリバリーの仕組み：Crossplaneと組み合わせるアプリCD側のツールです
• HCP Terraformとは？機能・料金とHCPでの位置づけ：Crossplaneと比較されるTerraform系の選択肢です
• Platform Engineeringとは？2026年の動向と導入の進め方：Crossplaneが実装手段となる内製プラットフォームの文脈です
• クラウドネイティブとは？CNCFの定義・構成技術・導入判断：CrossplaneはCNCF卒業プロジェクトで、その全体像を押さえられます
• コンテナオーケストレーションとは？Kubernetesの役割と判断：Crossplaneの前提となるKubernetesの役割を理解できます