Clineを200名規模で試してみました

背景

世の中では、2024年後半からいわゆるVibe Coding が急速に盛り上がり始めていました。モノタロウでもAIを活用してシステム開発を速度向上させるための調査や検証が進んでおりました。

私の担当するプロジェクトでは、システム開発速度を上げたいという需要から、先行でAI関連の投資を受けやすい状況にありClineの導入にトライすることになりました。 少し前からDevin(https://devin.ai/) の導入を進めていたこともあり、このような技術への期待値は高い状況でした。

どのような状態を目指していたか

2024年後半からいわゆるVibe Codingが加速し、当社でもAIを活用した開発速度向上の検証を進めていました。今回のトライでは、「AIにコードを書かせる体験」そのものをまずは獲得し、新しい開発パラダイムの可能性を見極めることを目的としました。導入初期は、自然言語の指示だけでコードが生成される体験に強い驚きを覚えました。

実際、導入してしばらくは自然言語で指示を出すだけで、魔法のようにプログラムが書かれていくその状況に大興奮していたのを覚えています

• Cursor
• Windsurf

素早く導入できること。どんなものかもよく分かっていなかったので、軽量に試せることが重要でした。

ちょうど社内で別部署のおかげで、Anthropic APIを試せる状況下であったことも追い風になり、Clineを小さく始められる状況になりました。 最低限の管理ルールを作成し、興味を持ちそうな人に声をかけつつ20人程度の規模で使い始めました。

利用者は増加を続け、2025年5月頃には200人を超えるメンバーに対してAPI Keyを発行することになりました。 それぞれのチーム内で、 .clinerules を育てる動きや、プロンプトを共有するような仕事の仕方も増えていきました。

改善したかった課題はどれくらい解決されたか

利用者からの評判は非常によく、「新規スクリプトの作成が非常に早くなった」「これ無しでは開発できない」という意見も出るほどでした。

また、非エンジニアの社員メンバーでもシステム開発に参画する事例が生まれるなど、面白い変化も見えました。

(参考)　『言えば作れる』時代の到来：AI×データパイプラインで実現した次世代開発スタイル - MonotaRO Tech Blog

一方で、アウトプットであるPullRequestの数にはそれほど変化は見られないなど、使いこなしや業務フローそのものをどのように変えていくかという観点では課題が見られました。

導入初期は大きな問題はありませんでしたが、利用規模の拡大に伴い、

• APIキーの発行・管理の煩雑さ
• 利用状況の可視化不足（誰がどれだけ使っているか）
• 費用の見通しの立てにくさ（完全APIベースゆえの変動）
• 請求・引き落とし運用管理

といった管理面の負債が顕在化しました。

GitHub Issue Licensing Conflict: Apache 2.0 vs Terms of Service Content Rights Requirements · Issue #3510 · cline/cline で議論されているように、どのように利用するかによってライセンスの適用が変わりますのでご注意ください。

Cline社の見解では、独自でAPIキーを利用する場合には、Apache License 2.0が適用される(Cline社は利用者のデータを収集しない)とのことですが、Cline公式のサービスを活用する場合には異なるデータの取り扱いになります。

詳細は、Cline - AI Coding, Open Source and Uncompromisedなど、公式の情報をご確認いただければと思います。

Clineの活用は非常に価値のあるものでしたが、費用面や管理面での難しさや企業としてどのようなプラットフォームを利用するか？という観点から、Cursorへの移行を進めております。

OSSとしてのClineプロジェクトは今後も応援したいと考えております。

意思決定の経緯などは以下のスライドにもありますので、ご参考にしていただければと思います。

モノタロウでCursorを導入してみた理想と現実、それと未来