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

by Kumo Ishikawa

Embed

Start on current slide

Slide 1

Slide 1 text

「OSSがあるなら自作するな」は AI時代も正しいか ── Build vs Adopt の新しい判断基準 Kumo Ishikawa / CyberAgent 2026-05-14 / クラウドネイティブ会議 Day 1 Track B

Slide 2

Slide 2 text

炎上回避 ● ポジション ✓ 事業会社側の技術選定責任者 × OSS のコアメンテナーではない × OSS 貢献を十分にできている側でもない今日は、その立場から見えている景色の話

Slide 3

Slide 3 text

自己紹介 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)

Slide 4

Slide 4 text

● 【話すこと】 AI時代の Build(内製) vs Adopt(OSS採用) の判断基準 AdoptすることのリスクいつBuildに踏み出すべきか ● 【話さないこと】特定OSSの評価 AI実装のパターン・詳細 OSS不要論・全面内製論本日の内容

Slide 5

Slide 5 text

まず結論から Main Theme 「OSSがあるなら自作するな」は AI時代も正しいか？答え: AI時代では、Buildすべき領域が増えた。ただし、それは「AIで何でも作れるから」ではない。全部Adoptでも、全部Buildでもない。 Adoptしながら必要な部分をBuildする。

Slide 6

Slide 6 text

5年前のAdopt判断を見直す

Slide 7

Slide 7 text

5年前の判断 2021年、私たちは KubeVela(K8s Manifest抽象化ツール) をAdoptした。当時は自然な判断だった。KubeVelaは、Platformに必要なコア要件を満たしていた。 Platformに必要なコア要件運用負荷の低減ユーザはKubernetesを理解しなくてもPlatformを運用できる柔軟性とコスト効率 Platform側は必要なときに、セキュリティ設定などを低コストで導入可能 Manifestの抽象化 Kubernetes Manifestが抽象化・モジュール化され、再利用性が向上自律性ユーザアプリケーションのドリフト検出と自動修復

Slide 8

Slide 8 text

5年後に見えてきたこと KubeVelaは、いまでは私たちのPlatformの根幹に深く入り込んでいる。一方で、開発元のAlibaba Cloudは撤退した。新しい開発チームは、私たちが求める方向とは違う方向に進んでいる。 2022~2023 Alibaba Cloud撤退開発元の主体が離れ、プロジェクトの継続性に懸念が生じた時期。 2024 2代目メンテナーチーム ● RoadMapなし ● Workﬂow分離とBugFix中心 2025 3代目メンテナーチーム ● エコシステム連携 ● Conﬁg周りUX改善私たちが求める方向: Template機能の増強 https://github.com/kubevela/kubevela/issues/6449#issuecomment-1903304504

Slide 9

Slide 9 text

簡単には置き換えられない現実 Helm 問題点: 抽象度が低い YAMLの管理が煩雑になりやすく、Platformとしての抽象化レベルを維持するのが困難。 Crossplane 問題点: オーバースペック構成が複雑になりすぎ、現状の要件に対して運用負荷が高すぎる。複雑な分岐条件への対応も困難。 KubeVelaはすでにPlatformに深く結合しているため、簡単には捨てられない。移行先を探しましたが、決定打となる候補はありませんでした。 Kro 問題点: 未成熟 GA（一般提供）前であり、プロダクション環境への導入にはリスクがある。複雑なロジックへの対応も不十分。 https://thinkit.co.jp/article/39157

Slide 10

Slide 10 text

簡単には置き換えられない現実

Slide 11

Slide 11 text

既存OSSは決定打に欠ける一方で、そのまま使い続けるのも不安があるそうなると、残されている選択はただ一つ.... （過激的な発想です)

Slide 12

Slide 12 text

すぐにそう結論づけるのは危ない。 AI時代なんだから、自分たちでBuildできるのではないか？

Slide 13

Slide 13 text

そのBuildってアンチパターンのBuildではないか？これまでBuildは、避けるべき選択とされてきた。では、そもそも何が問題だったのか？どんなBuildがアンチパターンになるのか？そして、そのアンチパターンはAI時代でも残るのか？ 

Slide 14

Slide 14 text

AI時代に変わるコスト、残るコスト

Slide 15

Slide 15 text

Buildがアンチパターンになる条件 Buildそのものが悪いわけではない。問題になるのは、作るべきでないものを、維持できない形でBuildすること。  事業価値・Platform価値に効かない  有力OSSでコア要件をすでに満たせる・車輪の再発明  チームで所有できない、作った後の保守が見えていない  信頼性・セキュリティ・運用責任を背負えない

Slide 16

Slide 16 text

Buildのコストは2種類ある実装コスト作るまでのコスト ● 仕様を整理する ● 実装する ● テストする ● ドキュメントを書く ● 既存システムに組み込む所有コスト作った後に持ち続けるコスト ● 保守・運用し続ける ● 障害・セキュリティ対応 ● 仕様変更への追従 ● チームでの引き継ぎ ● 信頼性の担保 Buildのコストは、大きく実装コストと所有コストに分けられる

Slide 17

Slide 17 text

AIで変わるもの項目 AI時代ではどう変わるか仕様を整理する一部できる。要求の整理、Spec化、抜け漏れ確認を補助できる実装するかなりできる。コード生成、修正、リファクタが速くなるテストするかなりできる。テストケース生成、既存コードへのテスト追加ができるドキュメントを書くかなりできる。README、ADR、運用メモを残しやすくなる既存システムに組み込む一部できる。接続コードは書けるが、影響範囲の判断は人間が必要 AIは、Buildの実装コストを大きく下げる。

Slide 18

Slide 18 text

AIでも残るもの — 所有コスト項目 AI時代でも残るもの保守する修正案は出せるが、継続して面倒を見る責任は残る障害対応する調査・一次対応は補助できるが、判断と責任は人間に残るセキュリティ対応する調査・一次対応は補助できるが、安全性の保証や責任は残る仕様変更に追従する実装は補助できるが、何を守るべきかの優先順位は人間が決めるチームで引き継ぐ文書化は補助できるが、所有体制はAIでは作れない信頼性を担保する SLOを守る運用補助はできるが、運用責任は残る運用し続ける優先順位、体制、責任分界はAIでは代替できない AIは、Buildしたものを所有する責任までは消さない。

Slide 19

Slide 19 text

AI時代のBuildアンチパターンまとめ AI時代でも避けるべき4つのアンチパターン 01 チームで所有できない属人化し、チーム全体での継続的な管理や引き継ぎが困難な Build。 02 責任を背負えない信頼性・セキュリティ・運用面での明確な責任主体が欠如した Build。 03 継続保守の見通しがない長期的なメンテナンス計画やリソースが確保されていない Build。では、やはりAdoptし続ければよいのか？実装コストは下がるが、「所有コスト」は残るアンチパターンの本質はAI時代以前とほぼ変わらない 04 「作る」ことだけ見る開発時の速度のみを優先し、リリース後の「持ち続ける」視点が欠けているBuild。

Slide 20

Slide 20 text

Adoptし続ければ安全なのか？ ❏ 代替OSSへ移行しづらくなる OSSにシステムが深く結合し、ロックインが発生する。 ❏ Platformの方向性が左右される OSSのロードマップに自分たちの意思決定が依存する。 ❏ コミュニティの変化を直接受ける開発元の方針転換やコミュニティの衰退がリスクになる。 ❏ 脆弱性・開発停止時のリスク開発が止まれば脆弱性対応も不可能になり、現状を我慢せざるを得ない。 Adoptは、Buildの所有コストを避ける代わりに、依存コストを引き受ける判断でもある。今回のKubeVelaの件から分かったのは、Adoptにも依存コストがあるということ。

Slide 21

Slide 21 text

見るべきものは「Buildが安くなったか」ではない真に問うべき核心的な問い Adopt して依存するコスト外部ソリューションに依存し続け、そのエコシステムの影響を受け続けるコスト。 Build して所有するコスト自社で資産として持ち続け、継続的に保守・運用していく責任とコスト。 vs その「どちらを払うのか」を意思決定する。

Slide 22

Slide 22 text

だからBuild vs Adoptを見直す Step 1 AdoptかBuildかを主判断する。 Step 2 Adoptするなら依存コストを見る Buildするなら所有コストを見る AI時代のBuild vs Adoptは、「AIで作れるか」だけでは判断できない。

Slide 23

Slide 23 text

AI時代にBuild or Adoptをどう判断し直すか

Slide 24

Slide 24 text

Matrix 1 — Adopt / Buildの主判断本質的な判断基準大事なのは、「何割使えるか」ではなく「コア要件を満たせるか」。 ●80%使えても、コア要件が欠けていればAdoptしづらい ●30%しか使わなくても、コア要件を満たせばAdopt する価値がある判断の軸 OSSでコア要件を満たせるか × 対象機能の重要度結論: コア要件充足は、OSSに任せられるかを見る軸

Slide 25

Slide 25 text

Matrix 1 — Adopt / Buildの主判断判断の軸 OSSでコア要件を満たせるか × 対象機能の重要度重要度が高い場合 Platformや事業への影響が大きく、コストを払って向き合う価値がある。 ● OSSでコア要件を満たせる → Adopt ● OSSでコア要件を満たせない → Build 結論: 重要度は、その機能にどこまで投資する価値があるかを見る軸重要度が低い場合要件を絞る・小さくBuildする・見送るなど、投資を抑えた判断を取りやすい ● OSSでコア要件を満たせる → Adopt ● OSSでコア要件を満たせない → Drop / Light Build

Slide 26

Slide 26 text

OSSでコア要件を満たせる OSSでコア要件を満たせない Adopt / Buildの主判断マトリクス Build 自分たちで作る対象 Heavy Adopt Adoptするが、標準化と運用設計が必要 Drop or Light Build 諦めるか、要件を下げても必要なら小さくBuild Light Adopt そのまま採用しやすい自作する価値は低い対象機能の重要度が高い対象機能の重要度が低い

Slide 27

Slide 27 text

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でコア要件を満たせない」領域のみ。

Slide 28

Slide 28 text

Matrix 2 — Adoptコスト Adoptには、Buildの所有コストを避けられる代わりに、依存コストがあるその重さは、主に次の2つで決まる 1. システム結合度そのOSSが、Platformの構造・運用・データ・権限・デプロイ・開発体験にどれだけ深く入り込むか。結合度が高いほど、やめる・置き換える・方針を変えることが難しくなる。 2. OSS持続性そのOSSが今後もメンテナンスされ、自分たちの期待する方向で使い続けられるか。開発元、コミュニティ、リリース頻度、方向性、エコシステムの継続性を総合的に見る。つまりAdoptコストは、どれだけ深く依存するか × その依存先は今後も信頼できるかで決まる。

Slide 29

Slide 29 text

OSS持続性が高い OSS持続性が低い Adoptコストマトリクス採用危険依存を薄くして代替検討代替がないならFork/Contribute検討 Heavy Adopt Adoptするが、標準化と運用設計が必要限定利用 / 撤退前提依存をなくして使う代替がないなら捨てる (Buildの出口) Light Adopt そのまま採用しやすい自作する価値は低いシステム結合度が高いシステム結合度が低い

Slide 30

Slide 30 text

Matrix 2の読み方 OSS持続性は変わる 5年前のKubeVelaは Heavy Adopt でしたが、開発元撤退や方向性の変化により、現在は採用危険に移動しました。 → Adopt判断は採用時だけでなく、定期的な見直しが不可欠です。システム結合度は、無理に下げればよいわけではない Heavy Adoptの場合、結合度が高いこと自体は必ずしも悪ではありません。例えばKubernetesを採用するなら、その制約を受け入れた上で土台にする覚悟があるはずです。問題は「結合度が高いのに、OSS持続性が崩れたとき（採用危険）」です。

Slide 31

Slide 31 text

Matrix 2の読み方採用危険になった場合選択肢は大きく2つ： ● 1. 結合度を下げて、代替OSSを探す: 依存を薄くし、置き換え可能な状態に近づける ● 2. 代替がなくFork/メンテナーになる: 使い続けるなら、自分たちで持続性を補う限定利用 / 撤退前提基本は別OSSへの切り替えを考える。代替がなければ、Buildも出口の一つになる。

Slide 32

Slide 32 text

Matrix 3 導入: Buildコスト Buildには、AIで実装コストを下げられる一方で、所有コストは残る。その重さは、主に次の2つで決まる。 Working Set Size 1人の開発者と1つのAI Sessionが、精度を落とさず理解・変更・検証できる大きさ。大きいほど： ● 関連コードが多い ● 暗黙仕様が多い ● 影響範囲が広い ● AIに渡す文脈が大きい ● 次の人が再開しづらい継続保守負荷作った後に、どれくらい継続的に手を入れ続ける必要があるか。高いほど： ● 仕様変更が多い ● セキュリティ要件が高い ● 周辺システム変更の影響を受ける ● 長期的な運用責任が重い Working Set Size × 継続保守負荷

Slide 33

Slide 33 text

継続保守負荷が高い継続保守負荷が低い Buildコスト分析マトリクス Build危険そのままBuildしない要件再設計が必要 Build推奨 AIと人間で扱いやすい所有コストも低い Build可テスト・自動化を厚くする分割してBuild 責務・境界で切るそのままBuildしない Working Setが大きい Working Setが小さい

Slide 34

Slide 34 text

Matrix 3 の読み方 Working Set Size はコード量ではない暗黙仕様、影響範囲、AIに渡す文脈、再開しやすさで見る継続保守負荷は変更頻度だけではない障害影響・セキュリティ・周辺変更・責任分界まで含めて見る CLAUDE/AGENTS.md / Spec は保守可能性の保証ではない次の人がAIと一緒に再びWorking Setへ載せるための補助線。Working Setが大きい場合は、責務・境界で分割できるかを見る。分割できれば分割してBuild。ただし、継続保守負荷が高いと、分割したつもりでも強く結合しやすい。その場合はBuild危険となる。 Buildコストを見るときに迷いやすいのは、「作れたか」ではなく「次も扱えるか」。 Buildコストを見るときに迷いやすいポイント

Slide 35

Slide 35 text

マトリクスまとめ 01 主判断 OSSでコア要件を満たせるか × 対象機能の重要度まず、AdoptかBuildかを決める。 02 Adoptコストシステム結合度 × OSS持続性 Adoptを選ぶなら、依存し続ける重さを見る。 03 Buildコスト Working Set Size × 継続保守負荷 Buildを選ぶなら、所有し続ける重さを見る。

Slide 36

Slide 36 text

5年前のOSSを当てはめる 5年前にAdoptした KubeVela を、3つのマトリクスに当てはめてみる。 01. 主判断 Heavy Adopt だった当時は、Platformに必要なコア要件を満たしていた。 02. Adoptコスト今は採用危険に近い現在は、Platformの根幹に深く入り込んでいる。一方で、開発元撤退や方向性の変化により、OSS持続性には不安がある。 03. Buildコスト全面Buildは危険全面的にBuildするには、 Working Setも継続保守負荷もまだ大きい。結論：Adoptの継続は困難、Build への移行負荷も高い「板挟み」の状態

Slide 37

Slide 37 text

今回の判断 01. 貢献と継続 Forkしつつ、upstreamにContributeする 02. 利用範囲最適化 Kubernetes Manifest TemplateとApplication Controllerのみ利用 03. 段階的な移行利用中の機能単位で分割検討し、部分的に別のOSSへ移行する KubeVela Workﬂow → Argo Workﬂow KubeVela Policy → K8s RBAC, 自作コントローラ

Slide 38

Slide 38 text

本音では、Buildに踏み出したいが... KubeVelaを全面Buildするのは危険だったため、諦める。気を取り直して「どの部分ならBuildできるのか」を見ていく。

Slide 39

Slide 39 text

AI時代、Buildすべき領域はどこか

Slide 40

Slide 40 text

実装コストで諦めていたもの以前は、実装コストを理由にBuildできなかったものがある 3章の言葉で言うと： • Matrix 1 で Build に寄る • Matrix 3 で Build危険以外に寄るなら、Build候補に戻せる。 AI時代では、実装・テスト・ドキュメント化のコストが劇的に低下します。以前なら諦めていたものを、再びBuild候補に戻せるようになります。 Build Matrix

Slide 41

Slide 41 text

実例 — RBAC Controller 作りたかったもの Platform向けに、Kubernetes RBACを安全に自動生成する仕組み。 AIエージェント/CIに必要なnamespaceだけ権限を渡す以前の判断：Build断念 ● Controller / Operator実装の初期コストが重かった ● CRD設計、RBAC生成ロジック、テストまで考えると踏み出す勇気がない ● 以前実装したControllerが運用に乗らず、失敗した経験があった

Slide 42

Slide 42 text

実例 — RBAC Controller 作りたかったもの Platform向けに、Kubernetes RBACを安全に自動生成する仕組み。 AIエージェント/CIに必要なnamespaceだけ権限を渡し、本番アクセスは制限したい今の視点: Build候補 ● コア要件を満たすOSSがない一件あったけど、持続性の観点で不採用 ● Platformの権限管理として極めて重要 → Build の領域

Slide 43

Slide 43 text

実例 — RBAC Controller 作りたかったもの Platform向けに、Kubernetes RBACを安全に自動生成する仕組み。 AIエージェント/CIに必要なnamespaceだけ権限を渡し、本番アクセスは制限したい今の視点: Build候補 ● WorkingSetが小さい ● 継続管理負荷が高い → Build可の領域

Slide 44

Slide 44 text

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として完備

Slide 45

Slide 45 text

krbacをAIでBuildしてわかったこと Buildできるようになった、という話は、いきなりOSS全体を作り直す話ではない。 krbacは、KubernetesをAdopt したまま、足りない権限管理の仕組みだけをBuild した。実務では AdoptしながらBuildすることがある。

Slide 46

Slide 46 text

Buildは一種類ではない Core領域 ● Adoptする ● 標準機能や重要なOSSの本体。そのまま使うことでエコシステムの恩恵を受ける。周辺・境界領域 ● Buildする ● 自社Platformへの最適化や、固有の運用要件を満たすために自作する。例: Kubernetes (Heavy Adopt) 主要コンポーネントは自作しない ● API Server ● Scheduler ● Controller Manager 自社Platform向けの拡張（Build）周辺ツールで価値を出す ● kubectl plugin ● manifest生成CLI / script ● Platform固有の診断ツール

Slide 47

Slide 47 text

Buildの種類 Extension Build OSSを拡張する実装を作る。例: ● kubectl pluginや Platform固有CLI ● Controller / Operator ● Admission webhook ● Helm Plugin Conﬁguration Build 設定・テンプレート・ポリシーを作る。例: ● Helm Template ● RBAC policy ● manifest生成ルール Fork Build OSSをforkして、自社要件に合わせる。例: ● upstreamに入らない修正を持つ ● 自社要件に合わせたパッチを維持する ● Contribute前提で一時的にforkする Core Build 中核機能そのものを自作する。例: ● OSSが担っていた主要機能を置き換える ● 自社固有のPlatform機能として作り直す AI時代では、Conﬁguration BuildとExtensionBuildを以前よりBuild候補として考えやすくなった。

Slide 48

Slide 48 text

第4章まとめ: AI時代、Buildすべき領域 Build候補に入れるべきなのは、主にこの3つ。 01 Matrix 1で Buildに寄る領域 OSSでコア要件を満たせず、重要度が高いもの。 02 Matrix 3で「Build危険」以外の領域 Working Setを小さくでき、継続保守負荷を扱える範囲に収められるもの。 03 Adoptしながら Buildする領域 CoreはAdoptしつつ、自社Platform に合わせるための設定・標準化・拡張・運用補助をBuildするもの。

Slide 49

Slide 49 text

まとめ

Slide 50

Slide 50 text

結論再掲 Main Theme 「OSSがあるなら自作するな」は AI時代も正しいか？答え: AI時代では、Buildすべき領域が増えた。ただし、それは「AIで何でも作れるから」ではない。全部Adoptでも、全部Buildでもない。 Adoptしながら必要な部分をBuildする。

Slide 51

Slide 51 text

Buildすべき領域が増えた理由 1 Buildの実装コストが下がった 2 Adoptにも依存コストがあると分かった 3 BuildとAdoptは二択ではない

Slide 52

Slide 52 text

Takeaway 今日持ち帰ってほしいのは2つ。 1 Build / Adoptは3つのマトリクスで見直す主判断、Adoptコスト、Buildコストを分けて見る。 2 Build候補に戻す領域を見極める ● Core Build: OSSでコア要件を満たせない重要機能 ● 所有コストを扱える領域: Build推奨 / Build可 / 分割してBuild ● AdoptしながらBuildする領域: Conﬁguration / Extension / Fork

Slide 53

Slide 53 text

Next Action: Amebaではどう動くか 1 KubeVelaは、全面Buildしない ● 2026年現在は採用危険に近い、ただし全面Buildするには「Build危険」に入る ● コア機能以外をWorking Set単位に分割し、Buildできる部分から置き換える ● コア機能は参加(Fork/Contribute)を目指し、代替OSSも定期的に調査 2 Build候補を洗い出し、優先順に実行 ● 実装コストで諦めていたが、継続保守負荷が低い領域を探す ○ まずBuild推奨から始め、習慣化したらBuild可 / 分割してBuildへ広げる ○ Fork Buildしつつ、Extension Buildのできる領域

Slide 54

Slide 54 text

ありがとうございました