「OSSがあるなら自作するな」は AI時代も正しいか ── Build vs Adopt の新しい判断基準

cloudnativekaigi 2026 nagoya

1. 「OSSがあるなら自作するな」は AI時代も正しいか ── Build vs Adopt の新しい判断基準 Kumo Ishikawa / CyberAgent 2026-05-14 / クラウドネイティブ会議 Day 1 Track B
2. 炎上回避 • ポジション ✓ 事業会社側の技術選定責任者 × OSS のコアメンテナーではない × OSS 貢献を十分にできている側でもない 今日は、その立場から見えている景色の話
3. 自己紹介 Kumo Ishikawa（石川 雲） CyberAgent Service Reliability Group(SRG)所属 • 担当サービス Ameba Platform, ドットマネー, ピグ • 得意領域 Platform Engineering, CI/CD, Security • 登壇歴 • SRE NEXT 2025 • Platform Engineering Kaigi 2025 • Kubernetes Meetup Novice 数回 Kubestronaut (2024) CyberAgent Next Expert of Platform Engineering(2025)
4. • 【話すこと】 AI時代の Build(内製) vs Adopt(OSS採用) の判断基準 Adoptすることのリスク いつBuildに踏み出すべきか • 【話さないこと】 特定OSSの評価 AI実装のパターン・詳細 OSS不要論・全面内製論 本日の内容
5. まず結論から Main Theme 「OSSがあるなら自作するな」は AI時代も正しいか？ 答え: AI時代では、Buildすべき領域が増えた。 ただし、それは「AIで何でも作れるから」ではない。 全部Adoptでも、全部Buildでもない。 Adoptしながら必要な部分をBuildする。
6. 5年前のAdopt判断を見直す
7. 5年前の判断 2021年、私たちは KubeVela(K8s Manifest抽象化ツール) をAdoptした。 当時は自然な判断だった。KubeVelaは、Platformに必要なコア要件を満たしていた。 Platformに必要なコア要件 運用負荷の低減 ユーザはKubernetesを理解しなくてもPlatformを運用できる 柔軟性とコスト効率 Platform側は必要なときに、セキュリティ設定などを低コス トで導入可能 Manifestの抽象化 Kubernetes Manifestが抽象化・モジュール化され、再利用 性が向上 自律性 ユーザアプリケーションのドリフト検出と自動修復
8. 5年後に見えてきたこと KubeVelaは、いまでは私たちのPlatformの根幹に深く入り込んでいる。 一方で、開発元のAlibaba Cloudは撤退した。 新しい開発チームは、私たちが求める方向とは違う方向に進んでいる。 2022~2023 Alibaba Cloud撤退 開発元の主体が離れ、プロジェク トの継続性に懸念が生じた時期。 2024 2代目メンテナーチーム • RoadMapなし • Workflow分離とBugFix中 心 2025 3代目メンテナーチーム • エコシステム連携 • Config周りUX改善 私たちが求める方向: Template機能の増強 https://github.com/kubevela/kubevela/issues/6449#issuecomment-1903304504
9. 簡単には置き換えられない現実 Helm 問題点: 抽象度が低い YAMLの管理が煩雑になりやすく、Platformと しての抽象化レベルを維持するのが困難。 Crossplane 問題点: オーバースペック 構成が複雑になりすぎ、現状の要件に対して運 用負荷が高すぎる。複雑な分岐条件への対応も 困難。 KubeVelaはすでにPlatformに深く結合しているため、簡単には捨てられない。 移行先を探しましたが、決定打となる候補はありませんでした。 Kro 問題点: 未成熟 GA（一般提供）前であり、プロダクション環境 への導入にはリスクがある。複雑なロジックへ の対応も不十分。 https://thinkit.co.jp/article/39157
10. 簡単には置き換えられない現実
11. 既存OSSは決定打に欠ける 一方で、そのまま使い続けるのも不安がある そうなると、残されている選択はただ一つ.... （過激的な発想です)
12. すぐにそう結論づけるのは危ない。 AI時代なんだから、自分たちでBuildできるのではないか？
13. そのBuildってアンチパターンのBuildではないか？ これまでBuildは、避けるべき選択とされてきた。 では、そもそも何が問題だったのか？ どんなBuildがアンチパターンになるのか？ そして、そのアンチパターンはAI時代でも残るのか？ 
14. AI時代に変わるコスト、残るコスト
15. Buildがアンチパターンになる条件 Buildそのものが悪いわけではない。 問題になるのは、作るべきでないものを、維持できない形でBuildすること。  事業価値・Platform価値に効かない  有力OSSでコア要件をすでに満たせる・車輪の再発明  チームで所有できない、作った後の保守が見えていない  信頼性・セキュリティ・運用責任を背負えない
16. Buildのコストは2種類ある 実装コスト 作るまでのコスト • 仕様を整理する • 実装する • テストする • ドキュメントを書く • 既存システムに組み込む 所有コスト 作った後に持ち続けるコスト • 保守・運用し続ける • 障害・セキュリティ対応 • 仕様変更への追従 • チームでの引き継ぎ • 信頼性の担保 Buildのコストは、大きく 実装コスト と 所有コスト に分けられる
17. AIで変わるもの 項目 AI時代ではどう変わるか 仕様を整理する 一部できる。要求の整理、Spec化、抜け漏れ確認を補助できる 実装する かなりできる。コード生成、修正、リファクタが速くなる テストする かなりできる。テストケース生成、既存コードへのテスト追加ができる ドキュメントを書く かなりできる。README、ADR、運用メモを残しやすくなる 既存システムに組み込む 一部できる。接続コードは書けるが、影響範囲の判断は人間が必要 AIは、Buildの実装コストを大きく下げる。
18. AIでも残るもの — 所有コスト 項目 AI時代でも残るもの 保守する 修正案は出せるが、継続して面倒を見る責任は残る 障害対応する 調査・一次対応は補助できるが、判断と責任は人間に残る セキュリティ対応する 調査・一次対応は補助できるが、安全性の保証や責任は残る 仕様変更に追従する 実装は補助できるが、何を守るべきかの優先順位は人間が決める チームで引き継ぐ 文書化は補助できるが、所有体制はAIでは作れない 信頼性を担保する SLOを守る運用補助はできるが、運用責任は残る 運用し続ける 優先順位、体制、責任分界はAIでは代替できない AIは、Buildしたものを所有する責任までは消さない。
19. AI時代のBuildアンチパターンまとめ AI時代でも避けるべき4つのアンチパターン 01 チームで所有 できない 属人化し、チーム全体での継続 的な管理や引き継ぎが困難な Build。 02 責任を 背負えない 信頼性・セキュリティ・運用面 での明確な責任主体が欠如した Build。 03 継続保守の 見通しがない 長期的なメンテナンス計画やリ ソースが確保されていない Build。 では、やはりAdoptし続ければよいのか？ 実装コストは下がるが、「所有コスト」は残る アンチパターンの本質はAI時代以前とほぼ変わらない 04 「作る」 ことだけ見る 開発時の速度のみを優先し、リ リース後の「持ち続ける」視点 が欠けているBuild。
20. Adoptし続ければ安全なのか？ ❏ 代替OSSへ移行しづらくなる OSSにシステムが深く結合し、ロックインが発生する。 ❏ Platformの方向性が左右される OSSのロードマップに自分たちの意思決定が依存する。 ❏ コミュニティの変化を直接受ける 開発元の方針転換やコミュニティの衰退がリスクになる。 ❏ 脆弱性・開発停止時のリスク 開発が止まれば脆弱性対応も不可能になり、現状を我慢せざるを得ない。 Adoptは、Buildの所有コストを避ける代わりに、依存コストを引き受ける判断でもある。 今回のKubeVelaの件から分かったのは、Adoptにも依存コストがある ということ。
21. 見るべきものは「Buildが安くなったか」ではない 真に問うべき核心的な問い Adopt して依存するコスト 外部ソリューションに依存し続け、そのエコシス テムの影響を受け続けるコスト。 Build して所有するコスト 自社で資産として持ち続け、継続的に保守・運用 していく責任とコスト。 vs その「どちらを払うのか」を意思決定する。
22. だからBuild vs Adoptを見直す Step 1 AdoptかBuildかを主判断する。 Step 2 Adoptするなら 依存コストを見る Buildするなら 所有コストを見る AI時代のBuild vs Adoptは、「AIで作れるか」だけでは判断できない。
23. AI時代にBuild or Adoptをどう判断し直すか
24. Matrix 1 — Adopt / Buildの主判断 本質的な判断基準 大事なのは、 「何割使えるか」ではなく 「コア要件を満たせるか」。 •80%使えても、コア要件が欠けていればAdoptしづ らい •30%しか使わなくても、コア要件を満たせばAdopt する価値がある 判断の軸 OSSでコア要件を満たせるか × 対象機能の重要度 結論: コア要件充足は、OSSに任せられるかを見る軸
25. Matrix 1 — Adopt / Buildの主判断 判断の軸 OSSでコア要件を満たせるか × 対象機能の重要度 重要度が高い場合 Platformや事業への影響が大きく、コストを払っ て向き合う価値がある。 • OSSでコア要件を満たせる → Adopt • OSSでコア要件を満たせない → Build 結論: 重要度は、その機能にどこまで投資する価値があるかを見る軸 重要度が低い場合 要件を絞る・小さくBuildする・見送るなど、投資 を抑えた判断を取りやすい • OSSでコア要件を満たせる → Adopt • OSSでコア要件を満たせない → Drop / Light Build
26. OSSでコア要件を 満たせる OSSでコア要件を 満たせない Adopt / Buildの主判断マトリクス Build 自分たちで作る対象 Heavy Adopt Adoptするが、 標準化と運用設計が必要 Drop or Light Build 諦めるか、要件を下げても 必要なら小さくBuild Light Adopt そのまま採用しやすい 自作する価値は低い 対象機能の重要度が高い 対象機能の重要度が低い
27. Matrix 1の読み方 Heavy Adopt • Kubernetes • Istio • ArgoCD • Kubevela(2021) Light Adopt • Falco • Trivy Build • 自社固有の権限モデル Drop / Light Build • 小さな自動化 迷いやすいポイント • 重要だからBuild、ではない: OSSで満たせるなら Heavy Adopt • OSSで満たせないからBuild、でもない: 重要度が低いなら Drop / Light Build • Buildすべきは、「重要」かつ「OSSでコア要件を満たせない」領域のみ。
28. Matrix 2 — Adoptコスト Adoptには、Buildの所有コストを避けられる代わりに、依存コストがある その重さは、主に次の2つで決まる 1. システム結合度 そのOSSが、Platformの構造・運用・データ・権 限・デプロイ・開発体験にどれだけ深く入り込む か。 結合度が高いほど、やめる・置き換える・方針を 変えることが難しくなる。 2. OSS持続性 そのOSSが今後もメンテナンスされ、自分たちの 期待する方向で使い続けられるか。 開発元、コミュニティ、リリース頻度、方向性、 エコシステムの継続性を総合的に見る。 つまりAdoptコストは、 どれだけ深く依存するか × その依存先は今後も信頼できるか で決まる。
29. OSS持続性が高い OSS持続性が低い Adoptコストマトリクス 採用危険 依存を薄くして代替検討 代替がないならFork/Contribute検討 Heavy Adopt Adoptするが、 標準化と運用設計が必要 限定利用 / 撤退前提 依存をなくして使う 代替がないなら捨てる (Buildの出口) Light Adopt そのまま採用しやすい 自作する価値は低い システム結合度が高い システム結合度が低い
30. Matrix 2の読み方 OSS持続性は変わる 5年前のKubeVelaは Heavy Adopt でしたが、開発元撤退や方向性の変化により、現在 は採用危険に移動しました。 → Adopt判断は採用時だけでなく、定期的な見直しが不可欠です。 システム結合度は、無理に下げればよいわけではない Heavy Adoptの場合、結合度が高いこと自体は必ずしも悪ではありません。 例えばKubernetesを採用するなら、その制約を受け入れた上で土台にする覚悟がある はずです。 問題は「結合度が高いのに、OSS持続性が崩れたとき（採用危険）」です。
31. Matrix 2の読み方 採用危険になった場合 選択肢は大きく2つ： • 1. 結合度を下げて、代替OSSを探す: 依存を薄くし、置き換え可能な状態に近づける • 2. 代替がなくFork/メンテナーになる: 使い続けるなら、自分たちで持続性を補う 限定利用 / 撤退前提 基本は別OSSへの切り替えを考える。 代替がなければ、Buildも出口の一つになる。
32. Matrix 3 導入: Buildコスト Buildには、AIで実装コストを下げられる一方で、所有コストは残る。 その重さは、主に次の2つで決まる。 Working Set Size 1人の開発者と1つのAI Sessionが、精度を落 とさず理解・変更・検証できる大きさ。 大きいほど： • 関連コードが多い • 暗黙仕様が多い • 影響範囲が広い • AIに渡す文脈が大きい • 次の人が再開しづらい 継続保守負荷 作った後に、どれくらい継続的に手を入れ続け る必要があるか。 高いほど： • 仕様変更が多い • セキュリティ要件が高い • 周辺システム変更の影響を受ける • 長期的な運用責任が重い Working Set Size × 継続保守負荷
33. 継続保守負荷 が高い 継続保守負荷 が低い Buildコスト分析マトリクス Build危険 そのままBuildしない 要件再設計が必要 Build推奨 AIと人間で扱いやすい 所有コストも低い Build可 テスト・自動化を厚くする 分割してBuild 責務・境界で切る そのままBuildしない Working Setが大きい Working Setが小さい
34. Matrix 3 の読み方 Working Set Size はコード量ではない 暗黙仕様、影響範囲、AIに渡す文脈、再開しやすさで見る 継続保守負荷 は変更頻度だけではない 障害影響・セキュリティ・周辺変更・責任分界まで含めて見る CLAUDE/AGENTS.md / Spec は保守可能性の保証ではない 次の人がAIと一緒に再びWorking Setへ載せるための補助線。Working Setが大きい場合は、責務・境界で分割できるかを見る。 分割できれば分割してBuild。 ただし、継続保守負荷が高いと、分割したつもりでも強く結合しやすい。その場合はBuild危険となる。 Buildコストを見るときに迷いやすいのは、「作れたか」ではなく「次も扱えるか」 。 Buildコストを見るときに迷いやすいポイント
35. マトリクスまとめ 01 主判断 OSSでコア要件を満たせるか × 対象機能の重要度 まず、AdoptかBuildかを決める。 02 Adoptコスト システム結合度 × OSS持続性 Adoptを選ぶなら、依存し続ける重さを 見る。 03 Buildコスト Working Set Size × 継続保守負荷 Buildを選ぶなら、所有し続ける重さを見 る。
36. 5年前のOSSを当てはめる 5年前にAdoptした KubeVela を、3つのマトリクスに当てはめてみる。 01. 主判断 Heavy Adopt だった 当時は、Platformに必要な コア要件を満たしていた。 02. Adoptコスト 今は 採用危険 に近い 現在は、Platformの根幹に深 く入り込んでいる。 一方で、開発元撤退や方向性 の変化により、OSS持続性に は不安がある。 03. Buildコスト 全面Buildは危険 全面的にBuildするには、 Working Setも継続保守負荷 もまだ大きい。 結論：Adoptの継続は困難、Build への移行負荷も高い「板挟み」の状態
37. 今回の判断 01. 貢献と継続 Forkしつつ、upstreamにContributeする 02. 利用範囲最適化 Kubernetes Manifest TemplateとApplication Controllerのみ利用 03. 段階的な移行 利用中の機能単位で分割検討し、部分的に別のOSSへ移行する KubeVela Workflow → Argo Workflow KubeVela Policy → K8s RBAC, 自作コントローラ
38. 本音では、Buildに踏み出したいが... KubeVelaを全面Buildするのは危険だったため、諦める。 気を取り直して 「どの部分ならBuildできるのか」を見ていく。
39. AI時代、Buildすべき領域はどこか
40. 実装コストで諦めていたもの 以前は、実装コストを理由にBuildできな かったものがある 3章の言葉で言うと： • Matrix 1 で Build に寄る • Matrix 3 で Build危険以外に寄る なら、Build候補に戻せる。 AI時代では、実装・テスト・ドキュメント 化のコストが劇的に低下します。 以前なら諦めていたものを、再びBuild候 補に戻せるようになります。 Build Matrix
41. 実例 — RBAC Controller 作りたかったもの Platform向けに、Kubernetes RBACを安全に自動生成する仕組み。 AIエージェント/CIに必要なnamespaceだけ権限を渡す 以前の判断：Build断念 • Controller / Operator実装の初期コストが重かった • CRD設計、RBAC生成ロジック、テストまで考えると踏み出す勇気がない • 以前実装したControllerが運用に乗らず、失敗した経験があった
42. 実例 — RBAC Controller 作りたかったもの Platform向けに、Kubernetes RBACを安全に自動生成する仕組み。 AIエージェント/CIに必要なnamespaceだけ権限を渡し、本番アクセスは制限したい 今の視点: Build候補 • コア要件を満たすOSSがない 一件あったけど、持続性の観点で不採用 • Platformの権限管理として極めて重要 → Build の領域
43. 実例 — RBAC Controller 作りたかったもの Platform向けに、Kubernetes RBACを安全に自動生成する仕組み。 AIエージェント/CIに必要なnamespaceだけ権限を渡し、本番アクセスは制限したい 今の視点: Build候補 • WorkingSetが小さい • 継続管理負荷が高い → Build可 の領域
44. krbacをAIでBuildしてみた krbac: Kubernetes RBACを宣言的に管理するOperator 高レベルなポリシーを定義すると、namespaceごとの Role / RoleBinding に自動展開する。 AIでの進め方 • Claude Code + Superpower で要件を整理 • 解決方法と技術スタックをAIと比較 • K8s Controller / Operator として実装方針 決定 • 実装プランをAIとレビュー • 利用者体験を優先してCRDを設計 • 評価ループを回しながら動作確認・改善 結果 → 相談から実機テストまで約4時間で完 了 • Dev運用段階 • Secret deny等の安全弁を表現可能 • 各種GuideやAPI RefまでSpecとして完備
45. krbacをAIでBuildしてわかったこと Buildできるようになった、という話は、 いきなりOSS全体を作り直す話ではない。 krbacは、KubernetesをAdopt したまま、 足りない権限管理の仕組みだけをBuild した。 実務では AdoptしながらBuildする ことがある。
46. Buildは一種類ではない Core領域 • Adoptする • 標準機能や重要なOSSの本体。そのまま使うことでエコ システムの恩恵を受ける。 周辺・境界領域 • Buildする • 自社Platformへの最適化や、固有の運用要件を満たす ために自作する。 例: Kubernetes (Heavy Adopt) 主要コンポーネントは自作しない • API Server • Scheduler • Controller Manager 自社Platform向けの拡張（Build） 周辺ツールで価値を出す • kubectl plugin • manifest生成CLI / script • Platform固有の診断ツール
47. Buildの種類 Extension Build OSSを拡張する実装を作 る。 例: • kubectl pluginや Platform固有CLI • Controller / Operator • Admission webhook • Helm Plugin Configuration Build 設定・テンプレート・ ポリシーを作る。 例: • Helm Template • RBAC policy • manifest生成ルール Fork Build OSSをforkして、自社要 件に合わせる。 例: • upstreamに入らない修 正を持つ • 自社要件に合わせた パッチを維持する • Contribute前提で一時 的にforkする Core Build 中核機能そのものを自作 する。 例: • OSSが担っていた主要 機能を置き換える • 自社固有のPlatform機 能として作り直す AI時代では、Configuration BuildとExtensionBuildを 以前よりBuild候補として考えやすくなった。
48. 第4章まとめ: AI時代、Buildすべき領域 Build候補に入れるべきなのは、主にこの3つ。 01 Matrix 1で Buildに寄る領域 OSSでコア要件を満たせず、重要度が 高いもの。 02 Matrix 3で 「Build危険」以外の領域 Working Setを小さくでき、継続保守 負荷を扱える範囲に収められるもの。 03 Adoptしながら Buildする領域 CoreはAdoptしつつ、自社Platform に合わせるための設定・標準化・拡張 ・運用補助をBuildするもの。
49. まとめ
50. 結論再掲 Main Theme 「OSSがあるなら自作するな」は AI時代も正しいか？ 答え: AI時代では、Buildすべき領域が増えた。 ただし、それは「AIで何でも作れるから」ではない。 全部Adoptでも、全部Buildでもない。 Adoptしながら必要な部分をBuildする。
51. Buildすべき領域が増えた理由 1 Buildの実装コストが 下がった 2 Adoptにも依存コス トがあると分かった 3 BuildとAdoptは二択 ではない
52. Takeaway 今日持ち帰ってほしいのは2つ。 1 Build / Adoptは3つのマトリクスで見直す 主判断、Adoptコスト、Buildコストを分けて見る。 2 Build候補に戻す領域を見極める • Core Build: OSSでコア要件を満たせない重要機能 • 所有コストを扱える領域: Build推奨 / Build可 / 分割してBuild • AdoptしながらBuildする領域: Configuration / Extension / Fork
53. Next Action: Amebaではどう動くか 1 KubeVelaは、全面Buildしない • 2026年現在は採用危険に近い、ただし全面Buildするには「Build危険」に入る • コア機能以外をWorking Set単位に分割し、Buildできる部分から置き換える • コア機能は参加(Fork/Contribute)を目指し、代替OSSも定期的に調査 2 Build候補を洗い出し、優先順に実行 • 実装コストで諦めていたが、継続保守負荷が低い領域を探す ◦ まずBuild推奨から始め、習慣化したらBuild可 / 分割してBuildへ広げる ◦ Fork Buildしつつ、Extension Buildのできる領域
54. ありがとうございました