$100 くらい溶かしながら社内向けコンポーネントパッケージを Cline 主導で開発した感想

はじめに

以前会社のテックブログでこのような記事を公開しました。

https://tech.enechange.co.jp/entry/2025/06/13/165838

この記事で言っている RenderProps のコンポーネントライブラリは初めて Cline 主導で開発したのですが、そのことについては記事では触れられていなかったのでこっちで雑多に感想をまとめておこうと思います。

Cline を使った開発の感想

定量的な結果

• 工数 : 実作業時間で２週間弱
• コスト : $100 ちょっと
• コード行数 : 1万行くらい（リファクタリングの余地あり）
• 成果 : まだこれから

感想

いいところ

手が速い

単純に文字を書く（生成する）スピードがめちゃくちゃはやかったです。
納得する実装にするには多少微量性調整が必要な場面が多かったですが、それを加味しても人間が書くのの数倍は早い印象でした。

ブランクがある技術でも即対応できる

「読めるけど書けない」「細かい書き方忘れた」といった技術的なブランクがあっても思うような処理がパパッとかけました。
React の CompositionEvent の扱い方や、TypeScript の型定義の細かい書き方など、忘れがちな部分も正確に実装してくれました。

技術選定しながら実装できる

今回はこの点が一番便利だと感じました。
最初はそもそも RenderProps というデザインパターンの存在すら知らずに、UI 依存のない機能のみのコンポーネントライブラリ、という注文からスタートしましたが、
何度かやり取りしているうちに向こうから RenderProps パターンがいいのでは、と提案してくれました。（最初は CustomHooks パターンからスタートしてそれをほぼ全部崩して、といった感じで紆余曲折あり）
これまではデザインパターンもある程度決めた上で開発に入らないと手戻りが多くなってしまうことが多かったですが、AI 生成ならコードを書き直すのもそこまで手間ではないので実際に実装をしながら技術選定をする、という進め方ができるのは新鮮でした。

RenderProps はCustomHooks を使えと公式からもアナウンスがある程度には古いパターンのようですが、今回やりたかったことにおいては CustomHooks よりも RenderProps の方が合ってるのかな、とも思ってます。
ただやっぱり AI の提案を完全に受け入れてしまうとあまり良くない選定をしてしまうこともあるかと思うので、それを適切にジャッジできる知識が使う側に求められるな、とも感じました。

よくないところ

待ち時間が微妙

Cline の生成時間は数分程度ですが、これは微妙な時間です。
Devin のような完全自動化ツールほど丸投げはできず、人間の介入が必要です。
コードが出来上がるまでの時間が数分くらいで、ただ待つには長いけど他のことをやるには短いという状況でした。

生成コードの品質は微妙なこともある

今回の開発は、一度自分が 0 -> 1 的な感じでパパッと作り、それをフロント専門のエンジニアにレビューしてもらい修正する、という流れでしたがかなりの数の指摘をもらいました。
パッケージ管理、lint、formatter、便利なパッケージの導入など、開発環境の整備に関する部分は特に修正が多かったです。
また、副作用がないのに useEffect を使うなど、React のベストプラクティスに沿わない実装も見られました。

デファクトスタンダートな開発環境整備や基本的な rules の設定くらいまではちゃんと知識、経験のある人がやり、実際の開発から AI をガンガン使っていく、というのがいい流れなのかな、と感じました。

次に活かしたい

rules を定める

Cline の出力品質を向上させるために、プロジェクト固有のルールを定めることが重要だと思いました。
ESLint の設定や、使用するパッケージの制約、コーディング規約などを明確にすることで、より一貫性のあるコードが生成されるはずです。

コンテキストをファイルに書かせる

今回はほぼ1つのセッションだけで進めていたのもあり、途中から同じことを何度も依頼したりといったことが発生してしまいました。
セッションを細かく分けることでより効率的な開発ができるのかなと感じました。
セッションを分けても必要な情報を引き継がせるために現在のプロジェクトの状況や、既存のコードベースの構造、使用している技術スタックなどをファイルに記録させることで、Cline がより適切な提案をしてくれるようになるのかな、と考えています。