【クラウドネイティブ会議】OSS依存と自作の保守負荷をどう見極めるか――AI時代に変わるBuild vs Adopt判断

クラウドネイティブの世界では「OSSがあるなら自作するな」という考え方が広く共有されてきた。しかし、AIコーディングの進化により、BuildとAdoptの判断基準は変わりつつある。クラウドネイティブ会議のセッション「『OSSがあるなら自作するな』はAI時代も正しいか――Build vs Adoptの新しい判断基準」では、サイバーエージェントの石川雲氏が、KubeVelaをめぐる依存と移行の課題をもとに、OSSに依存するコストと自作して所有するコストを比較し、AI時代に必要な判断軸を解説した。

「OSSがあるなら自作するな」は、AI時代も正しいのか

「OSSがあるなら自作するな」。クラウドネイティブの世界では、長くそうした考え方が共有されてきた。Kubernetesをはじめ、成熟したOSSエコシステムを活用することで、多くの現場は開発・運用の負荷を下げてきた。

しかし、AIコーディングの進化により、この前提は揺らぎ始めている。仕様を整理すればコードやテスト、ドキュメント作成をAIが支援し、以前なら実装コストの高さから見送っていた機能も短時間で作れるようになりつつある。では、AI時代においても「OSSがあるなら自作するな」という原則は正しいのか。

サイバーエージェントの石川雲氏は、事業会社側の技術選定責任者という立場から、この問いを掘り下げた。石川氏は最初に、今回の話は特定OSSの評価でも、AI実装の詳細でも、OSS不要論や全面内製論でもないと前置きした。そのうえで、AI時代ではBuildすべき領域は増えたが、それは「AIで何でも作れるから」ではないとも強調した。全部をAdoptするのでも、全部をBuildするのでもなく、Adoptしながら必要な部分をBuildする^※。その判断基準を見直すことが、本セッションの主題である。

※：Build：自前での作成。Adopt：既存のOSSの利用。

まず結論から

KubeVela採用から見えた、Adoptの依存コスト

まず石川氏が取り上げたのは、5年前のAdopt判断である。2021年、同氏らはKubernetes Manifestの抽象化ツールであるKubeVelaを採用した。当時の判断は自然なものだったという。KubeVelaは、同氏らのPlatformに必要なコア要件を満たしていたからだ。

求めていたのは、ユーザーがKubernetesを深く理解しなくてもPlatformを運用できること、セキュリティ設定などを低コストで導入できること、Kubernetes Manifestを抽象化・モジュール化して再利用性を高められること、さらにユーザーアプリケーションのドリフトを検出し、自動修復できることである。

しかし、5年経過後に見えてきた景色は異なっていた。KubeVelaはすでにPlatformの根幹に深く入り込んでいた。一方で開発元は撤退し、その後のメンテナンスチームは、石川氏らが求める方向とは違う方向に進み始めたという。石川氏らが求めていたのはTemplate機能の増強だったが、新しい開発チームはWorkflow分離やBugFix、エコシステム連携、Config周りのUX改善などに向かっていた。

5年後に見えてきたこと

前述のようにKubeVelaがPlatformの根幹に深く入り込んでいたという理由から、別のOSSへの移行も簡単ではなかった。たとえば、Helmは抽象度が低く、Crossplaneは現状の要件に対してオーバースペックで、Kroは未成熟という課題があった。既存OSSは決定打に欠ける一方、そのまま使い続けることにも不安がある状態である。

この事例が示すのは、Adoptが常に安全な選択とは限らないという現実だ。OSSを採用すれば、自分たちで作る所有コストを避けられる。しかしその代わりに、OSSの継続性や方向性に左右される依存コストを引き受けることになる。とはいえ、AI時代だからといって、すぐにBuildへ進むのも危うい。次に問うべきは、そのBuildがアンチパターンではないか、という点である。

BuildかAdoptかを見極める3つのMatrix

ではAI時代にBuildとAdoptのどちらを選ぶべきか。それはどう判断すればよいのか。石川氏は、ビルドコストを「実装コスト」と「所有コスト」に分けて整理した。実装コストとは仕様整理、実装、テスト、ドキュメント作成などにかかるコストである。所有コストとは作った後に保守し続け、障害対応やセキュリティ対応、仕様変更の判断、チーム内での引き継ぎを担うコストである。

AIコーディングによって下がるのは、主に実装コストである。コード生成、テスト生成、ドキュメント作成の負荷は確かに下がる。しかし、作ったものの責任までAIが引き受けてくれるわけではない。安全性をどう保証するか、どの変更を優先するか、障害時に誰が判断するかは、依然として人間とチームの責任として残る。石川氏は「AI時代でもアンチパターンの本質はほぼ変わりません」と語った。

AIで変わるもの

そのうえで石川氏は、BuildとAdoptを判断するための3つのMatrixを提示した。

Matrix 1は、AdoptかBuildかを判断する入口である。軸は「OSSでコア要件を満たせるか」と「対象機能の重要度」である。ここで重要なのは、OSSの機能を何割使えるかではない。80％使えてもコア要件が欠けていればAdoptしづらく、30％しか使わなくてもコア要件を満たしていればAdoptする価値がある。重要度が高く、OSSでコア要件を満たせるならHeavy Adopt、満たせないならBuildを検討する領域となる。

Matrix 2は、Adoptする場合のコストを見るためのものである。AdoptはBuildの所有コストを避ける判断である一方、OSSへの依存コストを引き受ける判断でもある。この依存コストは、「OSSの持続性」と「システムの結合度」で決まる。システムへの結合度が高いほど、置き換えや方針転換は難しくなる。またOSSの持続性は、開発元、コミュニティ、エコシステムが今後も期待する方向で継続するかを見る必要がある。Adoptの判断は採用時だけで完結せず、定期的に見直す必要がある。

Matrix 3は、Buildする場合のコストを見るためのものである。軸は「Working Set Size」と「継続保守負荷」である。Working Set Sizeとは、1人の開発者と1つのAIセッションが、精度を落とさずに理解・変更・検証できる大きさを指す。関連コードや暗黙仕様、影響範囲が大きいほど、次の担当者が再開しづらくなる。継続保守負荷は、作った後にどれだけ手を入れ続ける必要があるかを示す。仕様変更やセキュリティ要件、周辺システム変更の影響が大きいものほど、所有コストは重くなる。

この3つのMatrixによって、BuildとAdoptは単純な二択ではなくなる。まずMatrix 1で、その機能がOSSに任せられる領域か、自分たちで向き合うべき領域かを見極める。AdoptするならMatrix 2で依存コストを評価し、BuildするならMatrix 3で所有コストを評価する。AI時代に見るべきなのは、単に「Buildが安くなったか」ではない。Adoptとして依存コストを払うのか、Buildとして所有コストを払うのか。いずれのコスト負うべきなのかを見極めることが、石川氏の示した新しい判断基準である。

全面Buildではなく、Adoptしながら必要な部分をBuildする

3つのMatrixでKubeVelaを見直すと、5年前のHeavy Adoptは正しい判断だった。当時はPlatformに必要なコア要件を満たし、対象機能の重要度も高かったためである。

しかし現在は、Platformに深く結合していて置き換えが難しい一方、開発元の撤退やメンテナンスチームの方向性の変化により、OSSの持続性には不安がある。Matrix 2で見れば、Adoptコストは高まっている。かといって、全面的にBuildし直すことも危険である。KubeVela相当の仕組みはWorking Set Sizeが大きく、継続保守負荷も高い。Matrix 3で見ても、全面Buildは避けるべき領域に入る。

そこで石川氏が示したのは、全面Buildではなく、利用範囲を最適化する方針である。Kubernetes Manifest TemplateとApplication Controllerは使い続ける一方、コア機能以外はWorking Set単位に分割し、別のOSSへの移行や自分たちでのBuildを検討する。使い続けながらコントリビュートし、代替案を調査し、必要な部分だけをBuild候補に戻す考え方である。

実装コストで諦めていたもの

実際に石川氏らのチームでは、Kubernetes RBACを宣言的に管理するOperator「krbac」をBuildした（RBAC：Role Based Access Control、ロールに基づいたリソースへのアクセス制御）。以前から欲しかったものの、コントローラー実装のコストが高く、見送っていた機能だったが、相談から実機テストまで約4時間で完了し、Dev運用段階に至ったという。

最後に石川氏は、AI時代にBuildすべき領域が増えた理由として、Buildの実装コストが下がったこと、Adoptにも依存コストがあること、そしてBuildとAdoptは二択ではないことを挙げた。「OSSがあるなら自作するな」という原則は、AI時代だからと言って単純に否定されたわけではない。何をOSSに任せ、何を自分たちで所有するのか。Adoptの依存コストとBuildの所有コストを見極め、必要な部分だけをBuildする。その現実的な判断こそが、石川氏の示したAI時代のBuild vs Adoptである。