ポストCline時代のOSS開発はPlugin対応が必須なのか？
はじめに
LLMの支援が当たり前になった現在、オレオレツールを公開するハードルは下がり続けている。
私も以前からOSSコントリビュートはしていたが、Clineにより生産性を高められ、初のOSS公開に至った。(その後、既存のより良いPluginが見つかりArchiveした)
他にも諸々あり、自分の経験から表題の危機感をぼんやりながら書いてみる。
前提
- Clineとはコーディングに特化したAI Agentを扱うことのできるVS Code拡張機能である。
- 本記事は、この記事の内容を踏まえている。
Clineの盛り上がり
2025年の年明けから現在、Clineの話題でTwitterが盛り上がっている。
もっとも2024年11月末時点でこの記事のために情報収集した時には、盛り上がりは限定的であった。
いま盛り上がっている理由として、下記の条件が揃い、追い風が吹いている状況が一因と想像できる。
1. Auto Approve(自動承認)による”セミオート運転”の実現
Cline 3.0のリリースでAuto Approveが実装され、Fork版でなくとも”セミオート運転”のような開発ができるようになった。
Auto-approve
Cline's most requested feature is here 🎉 You can now let Cline work more autonomously with the new Auto-approve menu, letting you choose what tools he can use without needing your permission.
2. DeepSeek v3の登場による性能・コスト面の大幅な改善
2024/12/26にDeepSeek v3が登場し、性能の高さとコストの低さが注目されている。ClineからはOpenAI CompatibleのAPIも扱うことができ、トークン消費量の大きいClineとシナジーが話題になっている。
6710億個ものパラメーターを持つDeepSeek-V3はOpenAIのマルチモーダルAIモデル「GPT-4o」に匹敵し、場合によってはGPT-4oを上回る性能を発揮するとのことです。
割引期間中はDeepSeek-V3のコストはClaude 3.5 Sonnetの約1/54、終了後は約1/14です。
注意点として、年末年始直前にDeepSeek v3が登場し、Clineのキャッチアップとともに「長期連休の宿題」として目立っているだけという可能性もある。どちらを信じるかは各人に任せたい。
3. 影響力のあるエンジニアの言及
2025/01/07の安野貴博氏の言及から、これまでAIエージェントを利用していなかったITエンジニアにも、広くリーチされたように見受けられる。
ちなみに、厳密にはRoo-Clineを利用しているらしい。
ClineはなぜForkされているのか？
この仮説が詳しい。
特にこの点が原因の大きな部分と思われる。
- メンテナが少なく、パッチの受け入れ態勢が取れていない
- カスタマイズには実装の変更が必要である
余談だが、Cline作者のSaoud Rizwan氏は開発体制の増強のためにサンフランシスコへ移住し、Issue対応が薄くなっており、という背景もあるようだ。
Fork版Cline
今後どうなるかはさておき、現在のClineはFork版が乱立している。
名前をよく見るのはRoo-Cline、Bao-Cline、Cool-Clineだが、軽く調べてみたところBao-Cline特有のメリットを見つけることはできなかった。よってBao-Clineと、本家&Roo&Baoを売りにしているCool-Clineは優先度を下げても良さそうだ。
もっとも製造元が不明瞭なOSSの利用は控える、という考え方もあり、これらのFork版を今のところ使う予定はない。仮に方針を変えるにしても、機能的なメリットが明確なRoo-Cline以外は、現状Fork版に手を出さない予定だ。
OSSが外部からのPRを受け入れづらくなっている
話は少々脱線するが、2024年4月に明らかになったxzのバックドア問題は衝撃的だった。
小さなPRで数年信頼を重ね、難読化された攻撃コードのmergeに成功する。というフィクションめいた手法は、OSSとして外部からのパッチを受け入れるべき？という問題に発展している。
例えばEmbulkのメンテナ募集の背景にも、この事件の余波が見て取れる。
良くない方の未来予測
ここまで話してきた内容を繋げて見ると、あまり良くない仮説が見えてくる。
- AIエージェントにより個人開発者の開発速度が高速化され、オレオレツールが公開されるのと並行に、既存OSSへのIssueやPRが大幅に増加する可能性がある。
- 既存OSS側で届いたパッチの妥当性、それらが悪意の検証コストがメンテナ側での課題となり、受け入れコストが高まる。
- Upstreamに入らなかった機能は、個別に3rd partyツールとして公開されうる。本家のコードが小さい、あるいは本家との連携Interfaceが存在しない場合、ClineのようにFork版として乱立される可能性がある。
Fork版乱立の問題
本家のプロダクトと独立したBetter系のForkが乱立した場合、何が問題になるか？
個別のForkが独自の改良や機能追加を行う一方で、複数のForkに貢献することは現実的ではないので、本家・分家ともに開発リソースの取り合いになり、開発リソースは分散する。アプデの度に逐一機能の星取表などを作るわけもないので、利用者も雰囲気で分散する。またForkが当たり前になると、″分家″の導入に抵抗がなくなり、悪意のあるパッケージを導入してしまうリスクも懸念だ。
本家プロダクトと明確に決別する意図があるならともかく、機能追加の理由でエコシステムが分散するのは好ましくないと考えている。
プラグイン運用の具体例
私がよく使っている/関わっているOSSの中にプラガブルなものがある。3rd Party機能が点在しているにせよ、それらを選ぶ際は機能が局所化されており、コードも読みやすい量の方が好ましいと考えている。
Hono
Cloudflare Workersのバンドルサイズを削るためモジュール化を強く意識した設計になっており、拡張性が高い。MiddlewareとHelperというInterfaceで、3rd Partyとしても追加機能をエコシステムに組み込みやすい。
CDK
AWS CloudFormation、Terraform、Kubernetesに対応する各種CDKでは、ユーザ定義リソース(Construct)も、公開するレジストリであるConstructs Hubに登録することで簡単にエコシステムに組み込むことができる。
llm
LLMのAPIをシェルの世界観に組み込めるllm(コマンド)も、モデルプロバイダ毎にpluginとして導入する方式である。
こちらも所定の形式でPyPIに登録すれば3rd Partyツールもエコシステムに組み込むことができる。
まとめ
「今後のOSS開発はPlugin対応が必須なのか？」という問いについては、「”ForkしてBetter版”のコストが下がりつつある今、Pluginとして3rd Partyの受入口を用意しない場合、エコシステムに影響を及ぼすかもしれない」というのが現在の認識だ。
利用者的にも利用しているプロダクトがなぜか共倒れになっていいことは何もないので、このような風潮はあまり好ましくないと考えている。尤もただの杞憂や与太話で済むなら喜ばしいことではあるが。
Discussion