Zenn
鈴木商店Publicationへの投稿
🎉

【実体験】フロントリプレイスでClineを導入したら開発効率が爆上がりした話

わちち
に公開
React
TypeScript
リプレイス
Cline
Claude Code
tech

『その作業・・・AIだったらすぐ終わりますよ？』

最近、marionette.js から React へのフロントリプレイスを進めています。

現在、リプレイス対象の画面改修がなかなか大変だったんですが、
clineを利用したら大幅に開発効率が上がったので何をしたのかを話します！

[前提]リプレイス対象画面の大変さについて

リプレイス対象の画面は、下記のような厳しさがあります。

  • APIの数が多い
    • 実装途中ですが、今40個くらいあります。2画面でですよ？
  • 各APIのレスポンスに含まれるプロパティもかなり多い
    • 平均20〜30個くらいで、多いものだと約100個のプロパティを持っている
    • その中には使用していないプロパティもある
  • 表示を分岐するケースがたくさんある

Reactに置き換えるだけではすんなりとはいかず、思った以上に骨の折れる作業になっています。

ちなみにclineって？

VSCode拡張機能として動作するAIコーディングアシスタントです。
チャット形式でコードの生成・修正を依頼でき、ファイルの作成から編集まで自動でやってくれます。
実際のプロジェクトファイルを理解した上でコードを書いてくれるのが特徴です。

https://github.com/cline/cline

👀 実際どのくらい開発効率を上げることができた？

リプレイス開始前に自分 + GitHub Copilotで実装した場合の概算工数見積もりを行い、実際のcline活用での進捗と比較してみました。

事前見積もり（従来手法の場合）

  • (概算)想定工数：約50日
  • 主な作業：手動での型定義作成、コンポーネント実装、テストコード作成

実際の結果（cline活用）

  • 実績工数：約30日で完了
  • 差分：約20日短縮（40%の効率化）

何がこの差を生んだのか？

最も効果が大きかったのは、下記の作業でした。

  1. 型定義の自動生成（APIレスポンス → TypeScript型）
  2. 定型的なコンポーネントの大量生成
  3. テストコードのひな形作成

特に、40個以上のAPIそれぞれの型定義を手作業でやっていたら...と考えると恐ろしいですね
では、最も効果が大きかった作業でどのようにclineを活用したかを触れていきます！

⚠︎注意点

もちろん、この20日短縮がすべてclineの効果とは言えません！

  • プロジェクトの習熟度向上
  • 既存コードパターンの蓄積
  • チーム開発プロセスの改善
  • 共通化部品の利用

なども含まれています。また、工数見積もりの甘さも起因してる可能性があります。
ただ、clineが大きな要因の一つであることは間違いないと感じています。

✅ clineが役に立った場面

①型定義の自動生成（APIレスポンス → TypeScript型）

リプレイス前はOpenAPIでもなければ、静的型付け言語でもありません。
そのためレスポンスを見て、TypeScriptでちゃんと型をつけないといけません！これが地味にしんどいです。

そこでclineの出番です。
手作業の場合とclineを活用した場合の作業内容と作業時間の比較がこちらです。

Before（手作業の場合：比較のため一番しんどい方法）
1. 実際のレスポンスを確認
2. プロパティと値の型を確認  
3. `typo`に気をつけて１つずつ記載...

作業時間：約30分

After（clineの場合）
1. 実際のレスポンスを `xxxx.json` として自PJにコピペする
2. `xxxx.jsonから型定義に起こして`と`cline`に頼む
3. (必要であれば型の調整)

作業時間：約2分

cline様に頼めば、約15倍の効率化が見込めます！
ここは本当に助かりました！

ちなみにプロパティ名から予測してコメントも追加してと頼めば、コメントも自動で追加してくれます。

実際に使用していたプロンプト例

タスク：xxx.jsonからxxxの型を実装してほしいです

- xxx.json
  - これは実際のレスポンスデータです
  - nullになっているのは一旦string | nullと定義してください
  - 文字列になっているのは、string
  - 数値はnumberで

- 型名(新規作成)
  - Xxx
- ファイル名
  - xxxts

- 留意点
  - コメントを追加してほしい。命名から予測してください
      - 記載方法：  /** xxx */

②単純なコンポーネントの複数実装

似たようなファイル構成やデータ取得の動線だけど、コンポーネント名とかちょっと違うのでコピペしてリネームしていく作業を自分でやるのって地味にめんどうくさいですよね。

そんな時にもcline!
似たようなUIを何個もつくるとき、土台が一発でできるのはありがたいです。

clineの生成精度が上げるために下記のポイントを意識してプロンプトを作成していました！

  • ポイント
    • [超重要]実装参考ファイルを提示してあげる
    • 禁止事項を設けること
    • コンテキストの量を大きくしすぎないこと

そして手作業の場合とclineを活用した場合の作業時間の比較がこちらです。

Before(手作業の場合)：作業時間 約30分
↓
After(Clineの場合)：作業時間 約5分

約6倍の効率化！！
といってもあくまでも土台なので、仕様に沿った修正はもちろん必要です！

実際に使用していたプロンプト例

タスク：これからやろうとしているのは、/xxx/xxxの構成とほとんど同ような部品を作成しようとしています

- [components]と[store層の動線]、[フェッチ処理]まで作成して

- 実装参考[**重要なコンテキスト**]
  - page層：xxx/xxx
    - UI:xxx.tsx
    - hooks:use-xxx.ts
  - fetch-hooks層：use-fetch-xxx.ts

---
- ファイル名 / コンポーネント名
  - xxx / Xxx
---
- 関連するModel
  - xxxx(xxxxの情報)
    - 配置場所：xxx/xxx.ts
---
API(実装済み)
- 取得API:getxxx
  - store層のasync-thunksから経由して利用すること
    - データフロー:async-thunks→ slice→ selector→ page層
  - async-thunksはxxx.async-thunks.tsで定義すること
--- 
- 関連しているstore層
  - xxxで値を管理してください
---
- 留意点
  - 実装参考ファイルは重要なコンテキストです
  - 既存の実装・構成を踏襲するようにしてください
- 禁止事項
  - **store層において、既存の実装箇所の修正は行わないこと**

③テストコードのひな形も生成

手作業の場合とclineを活用した場合の作業時間の比較がこちらです。

Before(手作業の場合)：作業時間 約30分
↓
After(clineの場合)：作業時間 約5分

約6倍の効率化！！
hooksのテストは毎回書くのが面倒なので、初期の構成ができているだけでめちゃくちゃ助かります

実際に使用していたプロンプト例

タスク
- store層のテストを実装してほしい
  - 末尾に追加していって

テスト対象
- xxxx.async-thunks.ts
  - xxx
- xxxx.slice.ts
  - xxx
- xxxx.selectors.ts
  - xxx

実装参考
- xxx.async-thunks.spec.ts
- xxx.slice.spec.ts
- xxx.spec.ts

留意点
- 実装参考の書き方を踏襲すること
- 既存のテストに修正を加えないこと

😶 clineを使っていて困るところ

いいところを言いすぎたので悪いところも書いていきましょう。。。

参考実装がないときは自由すぎるコードを生成しがち

  • 仕様固有のパターンや、まだ誰も作ったことがないような処理では、clineが「とりあえず動く」コードを書いてしまいます
  • 結果として、チームの開発ルールや設計思想から外れたコードが生成されることも...
  • 汎用的なものは得意だけど、特殊な要件には少し弱い印象です

設計面でのガイドが弱い

実際に使ってみて感じた課題が以下になります。

  • 責務分離が甘くなりがち

    • 機能を親hooksに詰め込みすぎる傾向
    • 「とりあえず動かす」ことを優先して、後で分割しにくいコードになることも

  • レイヤー設計を無視しがち

    • プレゼンテーション層にビジネスロジックを書いてしまう
    • 「コンポーネント内で全部解決」みたいなコードが生成されることも

対応策

  • .clinerulesファイルでプロジェクトの設計ルールやコーディング規約を設定する
  • 実装参考ファイル構成を明示的に提示する
  • 生成後のコードレビューはもちろん必須！

clineは確実に開発を加速してくれますが、設計の最終責任は人間が持つことが大切ですね。

まとめ：clineはおすすめ

  • 「あったら便利」じゃなくて、「ないとやってられない」レベル
  • 実装開始前の見積もりと比較して約40%の開発効率化できた
    • ⚠️ 全てがclineの効果とは言えません
  • 特に実装参考ファイルを提示できるリプレイス案件では、効果を実感しやすいと思います

同じようにリプレイスや画面の再構築に取り組んでいる方がいたら、 まずは cline を試してみてほしいです！
ほんと、開発がちょっと楽になりますよ〜。

追記：Claude Codeもおすすめ

実は最近、clineよりClaude Codeをよく利用しています。
2週間前にこの記事をWIPとして置いていたら、もうClaude Codeの方が僕の中で優勢になっちゃっていました。。。
AI時代は移り変わりが早くて恐ろしいっすね

↓↓↓以前投稿した、Claude Codeセットアップがよくわかる良記事
https://zenn.dev/suzukishouten/articles/c58cb56a41714e

ps. 追記の追記：Gemini CLI 出ちゃってた

鈴木商店
鈴木商店Publication

Discussion