開発者の認知負荷軽減を目指して選んだCrossplane - Self-serviceの理想と現実

クラウドネイティブ会議2026
day2 5/15 Track A 17:40~
株式会社hacomono
有働 開
https://kaigi.cloudnativedays.jp/sessions/2895/?from=timetable&day=day2

現在hacomonoはアプリ量産によって事業拡大を狙っており、私のチームではKubernetesを利用したGitOpsベースのSelf-service基盤を構築することでアプリ開発支援に挑戦しています。

しかしGitOpsで扱いづらいマネージドサービスの扱いに課題を感じていました。
そこでCrossplaneを採用し、あらゆるリソースをカスタムリソースに抽象化することでGitOpsで完結する基盤を目指しました。
これにより複数のIaCを使って数百行記述する必要のあったリソースが数~数十行のmanifestで扱えるようになりました。

一方、Crossplaneの運用負荷/学習コストが高いことや、抽象化に時間がかかること、抽象化による柔軟性の低下等の新たな課題も感じています。

本セッションではCrossplaneを採用するに至った背景や、実際に運用して感じたメリデメ、抽象化によって得られるものと失うもの等を実体験に基づいて共有します。
Kubernetesとマネージドサービスとの連携に課題を感じている方やCrossplaneの導入を検討している方等に知見を提供します。

Transcript

1. Last Update 2022.03.16 開発者の認知負荷軽減を目指して選んだ Crossplane Self-serviceの理想と現実 クラウドネイティブ会議 2026 Platform Engineering Track
2. 2 目次 1. 導入 2. Crossplane概要 3. hacomonoでの採用事例 4. 運用して感じた良さ 5. 運用して感じた難しさ 6. 運用上の工夫 7. まとめ
3. section 1 導入
4. 4 自己紹介 有働 開(Kai Udo) • 社歴 ◦ 2020/4 ~ 2024/6 某製造業 ◦ 2024/7 ~ 株式会社hacomono 現在: 共通基盤グループ所属 • GitHub: u-kai, X: @u_kai1012 • CloudNative会議初参加です！ よろしくお願いいたします！
5. 5 本日話すこと・話さないこと 話すこと • Crossplaneでできることの概要 • 我々がCrossplaneを選定した理由 • 我々のCrossplane活用方法 • Crossplaneを活用して感じられたメリットや難しさ、工夫点など 話さないこと • Crossplaneの具体挙動 a. https://speakerdeck.com/hacomono/platform-engineering-with-crossplane-resource-abstraction-simplified b. https://techblog.hacomono.jp/entry/2025/12/11/000000 • Crossplane以外の具体的な技術選定について a. https://techblog.hacomono.jp/entry/2025/10/14/110000 b. https://findy-tools.io/products/aws-eks/208/840 • Crossplaneの網羅的な活用方法
6. section 2 Crossplane概要
7. 7 Crossplane概要 • CNCFのプロジェクトで去年の11月Graduated Stageに🎉 • Upbound社が提供している商用版も(本日はOSS版の話) • 名前の通り横断的(Cross)なControl planeが実現可能 出典: https://www.crossplane.io/
8. 8 Crossplaneで達成できることの概要 1~あらゆるリソースを Kubernetesリソースに !~ あらゆるリソースが Kubernetesリソースとして管理できるように !
9. 9 Crossplaneで達成できることの概要 2~Composite Resourceの実装が可能 ~ K8sのリソースをまとめた独自カスタムリソース ※を実装可能 あらゆるリソースの組み合わせを抽象化して提供可能に！ ※ 正確にはXRと呼ばれていますが、わかりやすさを考慮して本資料ではカスタムリソースと表記しています。
10. section 3 hacomonoでの採用事例
11. 11 hacomonoについて hacomonoというWellness業界向けSaaSを提供中
12. 12 hacomonoのこれから ~マルチプロダクト戦略について ~ 各プロダクトは独立して開発してマイクロサービスの恩恵を受けたい これからはマルチプロダクトにも注力して事業拡大を狙う
13. 13 プロダクト量産に向けて プロダクトの量産を実現するには... a. 中央チームが全プロダクトのインフラを構築する b. インフラ人材をプロダクト毎にアサインして都度インフラを構築する c. プロダクト開発者自身でインフラ構築をできるように仕組み化する etc…
14. 14 中央チームによるインフラ構築のアプローチ • ガバナンスの担保が可能 • プロダクト開発者がプロダクト開発に集中できる • プロダクト数に比例して運用コストが増えがち • 中央チームがボトルネックになりうる
15. 15 プロダクト毎にインフラ人員をアサインしてプロダクト毎にインフラ構築するアプローチ • プロダクト開発者と密にやり取りしてインフラ構築できる • 柔軟なインフラ構築が可能 • プロダクト数に比例してインフラ人員が必要になる • 構成がバラバラになりうる
16. 16 プロダクト開発者自身でインフラ構築できるようにするアプローチ • プロダクト開発者自身で高速なインフラ構築が可能 • プロダクト数に比例して基盤チームの運用工数が増えにくい • 仕組みの中でガバナンス担保が可能 • 仕組み作りが必要 • 汎用的に構築することで個別最適化が難しくなる可能性
17. 17 プロダクト開発者自身でインフラ構築できるようにするアプローチ • プロダクト開発者自身で高速なインフラ構築が可能 • プロダクト数に比例して基盤チームの運用工数が増えにくい • 基盤レイヤーによるガバナンス担保が可能 • 仕組み作りが必要 • 汎用的に構築することで個別最適化が難しくなる可能性 Self-service基盤構築を採用！
18. 18 Self-service 基盤の技術選定 K8s ✖ エコシステム ✖ GitOpsを採用 必要なmanifestをGitにpushするだけで OKな状態を目指した • 必要な機能を基盤に組み込みやすい • GitOpsによって開発者の認知負荷や運用工数を下げられる • あらゆるリソースを一貫したK8s APIで管理/提供できる
19. 19 K8s/GitOps で感じた課題 以下のような課題が浮上 • マネージドサービスの扱いやK8sリソースとの連携 • プロダクションレディなK8sリソースの定義 • 基盤独自の仕様や複雑さ • 上記を全てAIで解決できるか？ Self-service利用者のペルソナを K8s/Terraformに慣れてない開発者と想定
20. 20 マネージドサービスの扱い • マネージドサービスはGitOpsで管理しづらいので別IaCを使う必要あり K8s✖GitOps マネージドサービス ✖IaC ✖ CDツール • manifest + 別IaCの学習/管理が必要になる • K8sリソースとマネージドサービスの連携が必要なケースは複雑... • それぞれ別々の仕組みでデプロイする必要がある
21. 21 プロダクションレディな K8sリソースの定義 • セキュアで信頼性のあるK8sリソースを定義するには十分な知識が必要 • 様々なリソースを適切な設定で組み合わせる必要があり複雑 PDB? maxSurge?? securityContext? affinity?antiAffinity? HPA?それともKEDA? PSS??
22. 22 基盤独自の仕様や複雑さ • 開発者は基盤独自の設定を適切に設定する必要がある ◦ Account IDやデプロイするネットワークリソース IDなど ◦ 付与が必須なラベルや属性など 基盤管理者 開発者 cost-center labelつけてください devはxxでprodはyy AccountIDで す この前お願いした環境変数です が、HOGE_HOGEに変更してほ しいです。 このリソースはdevに置きたい IDなんだっけ？？💦 調整必須の細かい変更多いんだ よな〜💦 • 上記に変更があった場合は基盤管理者と開発者で調整が必要になる
23. 23 AIにインフラ構築の全てを任せることはできないか？ • 知識を有してないと良いIaCの出力は難しい • 複雑なIaCのレビューは難しく、認知負荷が高い • リスクを考慮するとAIを100%信用するのは（まだ）簡単ではない 堅牢なコンテナをデプロイしたいって 言ったらめっちゃ出てきた。。。なん じゃこれ。。。 権限不足ならrootで動かすのしょう がないよな？多分。。。 堅牢なワークロードはこちらで す。 ちなみに権限不足で動かな かったのでrootで動かしてま す。 💦
24. 24 K8s を使ってプラットフォームエンジニアリングを実現する際の考慮ポイント • K8s 自体の運用負荷 ◦ 専門チームが頑張るしかない!? • manifest を開発者に書いてもらう場合... ◦ 開発者に生じる manifest の認知負荷 ◦ ガバナンス担保が難しい ◦ 基盤変更の適用が難しい • 他のマネージドサービスと連携する場合... ◦ K8sとの連携が難しい ◦ マネージドサービスの設定/管理が大変 イケてる仕組みでも開発者の負荷が高いと意味がない... 認知負荷や工数が大きい。。。 なんとかせねば。。。
25. 25 K8s を使ってプラットフォームエンジニアリングを実現する際の考慮ポイント • K8s 自体の運用負荷 ◦ 専門チームが頑張るしかない!? • manifest を開発者に書いてもらう場合... ◦ 開発者に生じる manifest の認知負荷 ◦ ガバナンス担保が難しい ◦ 基盤変更の適用が難しい • 他のマネージドサービスと連携する場合... ◦ K8sとの連携が難しい ◦ マネージドサービスの設定/管理が大変 イケてる仕組みでも開発者の負荷が高いと意味がない... Crossplaneを採用!
26. 26 Crossplaneで達成できること (再掲) Crossplaneによって マネージドサービス含むあらゆるリソースを K8sリソースで管理可能 & あらゆるK8sリソースの組み合わせを抽象化して提供可能に！
27. 27 Crossplaneの採用 Crossplaneの採用で • マネージドサービス含めほぼ全てをGitOpsで管理可能！ 少ないmanifestと認知負荷であらゆるリソースを定義可能に！ 開発者自身で簡単かつ安全なインフラ構築ができるはず！ • プロダクションレディなリソースをカスタムリソースで提供可能！ • 基盤独自の仕様や複雑さはカスタムリソースの裏側に隠蔽可能！ • 抽象化とガードレールでレビューの認知負荷を軽減可能！
28. 28 Crossplaneを活用した実際の Self-service 基盤イメージ 複数チームが利用中 & 利用予定
29. 29 Self-service 基盤詳細 • インフラコードは基盤リソース/複数プロダクトをまとめたモノレポ • プロダクト毎のAWSリソース分離はXRの裏側で達成 • 開発者にはGitおよび限定されたAppProjectの権限のみ解放 • 一般的なプロダクト開発のニーズに焦点を当ててXRを構築 • 許可されたリソースのみを利用可能にしてガバナンス担保 • 全AWSサービス/K8sリソースに対応しているわけではない • 基盤を利用できるケースとできないケースでガイドラインを引いている
30. 30 Crossplane の活用例 ~アプリケーションコンテナと S3 Bucket~ Crossplaneなし: manifest 150行,Terraform 100行を別々の仕組みでデプロイ Crossplaneあり: manifest 数十行をGitにpushするだけでデプロイ
31. 31 Self-service 基盤で達成できたこと • 開発者のみで必要な全リソースを構築できている 🎉! • プロダクト数が増えても基盤運用者の負荷が上がりづらい状態に 🎉!
32. section 4 運用して感じた良さ
33. 33 提供機能の変更が容易 • Operatorのプログラム不要で抽象の提供が可能 • 抽象化によって (契約を破らない前提で)機能追加/修正が開発者との調整なしで実施可能 プログラムなしで実装 できる！ labelの追加っと hapからkedaに変更っ と 0スケールやcron ベースのスケールが 可能になったらしい いつか利用を検討し よう
34. 34 開発者への最小な権限付与 GitOpsとの組み合わせによって開発者への K8s/AWS権限付与を最小限に！
35. 35 AIによる基盤運用者およびプロダクト開発者への支援が可能 • 開発者への精度の高い manifest作成支援が可能 • 基盤管理者への基盤開発や Crossplaneのナレッジ収集など支援が可能 コンテナデプロイしたい！ 新しいカスタムリソース定 義して！ Crossplaneのここどう なっている？
36. 36 K8s を使ってプラットフォームエンジニアリングを実現する際の考慮ポイント • K8s 自体の運用負荷 ◦ 専門チームが頑張るしかない!? • manifest を開発者に書いてもらう場合... ◦ 開発者に生じる manifest の認知負荷 ◦ ガバナンス担保が難しい ◦ 基盤変更の適用が難しい • 他のマネージドサービスと連携する場合... ◦ K8sとの連携が難しい ◦ マネージドサービスの設定/管理が大変 イケてる仕組みでも開発者の負荷が高いと意味がない... Crossplaneサイコーでは？？
37. 37 K8s を使ってプラットフォームエンジニアリングを実現する際の考慮ポイント • K8s 自体の運用負荷 ◦ 専門チームが頑張るしかない!? • manifest を開発者に書いてもらう場合... ◦ 開発者に生じる manifest の認知負荷 ◦ ガバナンス担保が難しい ◦ 基盤変更の適用が難しい • 他のマネージドサービスと連携する場合... ◦ K8sとの連携が難しい ◦ マネージドサービスの設定/管理が大変 イケてる仕組みでも開発者の負荷が高いと意味がない... もちろん難しさもあります。
38. section 5 運用して感じた難しさ
39. 39 Crossplaneの認知/運用負荷の高さ 他IaC ツールはCLIベースのoneshot実行なので楽。。。 複数コンポーネント への理解/設定/運用が必要 適切な権限設定 マネージドリソース対応追加の作業 モニタリング バージョン管理 インフラ起因のエラー カスタムリソース の追加作業 適切なコンポーネントの設定
40. 40 他IaC ツールと比べ てエコシステムが 発展途上 に感じる • Terraformのplanのような機能がない • Testツールが最近出たばかり ◦ 商用版には前から存在する模様 (今後OSS版に追加されるかも!?※) • カスタムリソースの構成リソースをレンダリングする機能はあるが... ◦ 現在の構成との差分がわからない ◦ それが正しいか、稼働するかどうか 動かさないとわからない 運用管理には独自ツールの作成やマインドチェンジが必要 ※: https://github.com/crossplane/crossplane/issues/6810
41. 41 Crossplaneによるカスタムリソース提供の落とし穴 ~実際に起きた設定ミス ~ カスタムリソース作成には十分な Crossplane/K8s/マネージドサービスの知識と検証 /テストが必要 失敗しても Runningし続けるカスタムリソース ... 設定ミスによる AWSサービスとの差分で無限 Reconcile… 消したくても消えない永続層が無限 Reconcile... Crossplaneのバグで期待する更新がされない ... etc… 重い。。。
42. 42 全てのユースケースを CrossplaneによるSelf-serviceで対応するのは大変 • Crossplaneで機能のサポートを追加→運用コストがかかる 多くをサポートする十分な運用体制の構築 OR サポート外の明示やサポート外に対する対策方針を固める などが必要 • 能機能追加には追加する機能の十分な知識と運用していく覚悟が必要 • サポート外は開発者責務で別IaC管理→インフラ管理の一貫性が欠如 ◦ Terraform module配布の方が”オプションで組み合わせ可能 ”を達成しやすい...
43. 43 Self-serviceや抽象化を用いても認知負荷を 0にするのは難しい 現実: 基盤に慣れるまではやり取りが必要だった 当初の想定 : ドキュメントや AIを駆使すればほぼ自走できるはず さらに認知負荷を減らすか基盤に慣れてもらうための施策が必要 • 基盤固有のルールや思想と従来の開発手法との乖離がある • GitOpsの思想やツールの利用方法に慣れてない • 抽象化されているとはいえmanifestの扱いに慣れてない
44. 44 その抽象は進化可能か？ 抽象化によるリソース提供は難しい その抽象はニーズを満たせるのか？ その抽象は認知負荷を下げられているか？ 機能追加を進めたら抽象化前とほぼ変わらなくなった ... そもそも抽象化して提供すべきなのか？
45. section 6 運用上の工夫
46. 46 Crossplaneを利用して Self-service提供する上での工夫 ~Crossplane完全理解 ~ コードやドキュメントリーディングによる Crossplane 完全理解を実施 • カスタムリソースを正確に提供するために！ • 正確なトラブルシューティングやモニタリング設定をするために！ • AI活用で精度の高いアウトプットを得るために！ おすすめのドキュメントやコード • https://docs.crossplane.io/latest/whats-crossplane/ • internal/controller/apiextensions/definition/reconciler.go • internal/controller/apiextensions/composite/reconciler.go • internal/controller/apiextensions/composite/composition_functions.go
47. 47 Crossplaneを利用して Self-service提供する上での工夫 ~シナリオテストの実装と実施 ~ シナリオテストの実装と実施による設定ミスの撲滅 • 実際に動かすことでわかる設定ミスを炙り出せる • 実装に対して仕様通りであることに自信を持てる • 変更に対して問題ないことに自信を持てる • AIへフィードバックを与えることができる
48. 48 Crossplaneを利用して Self-service提供する上での工夫 ~ADRによる意思決定 ~ ADRを用いて意思決定し、その結果を保存 • 提供する抽象や機能が適切かどうかトレードオフ含めADRへ • 設計や判断がチーム内でブラッシュアップされるように！ • 過去のADRが継続的な機能改善の指針に役に立つ！ • ADRを元にAIが実装してくれるように！ • 設計背景や思想まで考慮してAIが回答してくれるように！
49. 49 Crossplaneを利用して Self-service提供する上での工夫 ~その他~ • 独自ツールの開発によるカスタムリソース開発効率化 • K8s Eventのモニタリング強化によって設定ミスを気付ける状態へ • 永続層はK8sリソースのみ削除するように設定し、無限Reconcileを防止 • 開発者の心理的ハードルを下げるためのSkills整備 • dev環境かつ担当範囲であればapproveなしでmerge可能にし、いち早く基盤 に慣れてもらうように などなど
50. 50 Crossplaneを活用した Self-serviceで未だに悩んでいること • 個別最適な要求をどこまで受けるべきか？ • どうしたらすぐに基盤に慣れてくれるか？認知負荷を減らせるか？ • 重いシナリオテスト ... • 実永続リソースの Clean up処理... などなど... 悩みながらも日々の改善活動を実施中！
51. section 7 まとめ
52. 52 開発者の認知負荷軽減を目指して選んだ Crossplane • 全てをGitOpsでまとめることができた👌 • 抽象化により複雑さを隠蔽できた👌 • 結果、プロダクト開発者だけでインフラ構築ができている👌 • プロダクションレディな設定になっていることが担保できている👌 • プロダクト数に比例しない運用負荷を実現できている👌
53. 53 Self-serviceの理想と現実 • Crossplaneは良いことばかりではなく、難しく運用負荷もかかる😢 • Crossplaneだけで全てのユースケースに対応するのは大変😢 • 開発者が基盤に慣れるまでのハードルが存在する🤔 • 抽象を提供するとこと自体が難しい😢 • 日々の運用改善が重要😬
54. 54 今後の展望 • 基盤利用にいち早く慣れてもらう仕組みの整備 ◦ オンボーディングの実施 ◦ Getting Startedの整備 • 対応ユースケースを広げて基盤利用をさらに加速させる • 利用者からのフィードバックをもとに継続的改善 • Crossplaneの新CLIの検証/評価 ◦ シナリオテストを薄くしたい... • 上記を達成するための運用体制強化
55. https://www.hacomono.jp/