Kumatora の技術ブログ

Cline使っていますか？

私は約2ヶ月間使ってみて、個人的な所感と効果的な使い方についてまとめてみました。

これからCline系のAIエージェントを前提に今の使い方を書いていきます。

VS Code LM APIを使えば、Copilotをエージェントとして利用できます。すでにCopilotを契約している方なら、追加料金なしで使えるのがメリットです。

モデルを幅広く選べるのも使いやすいです。

巷でも言われていますが、Claudeが頭一つ抜けていると感じています。コンテキスト理解力がずば抜けており、こちらの意図を汲み取って適切に対応してくれることが多いです。後述するClineとの理想的な付き合い方も、Claudeでなければ成立しないケースが多いと感じています。

ただし、Claude 3.7 sonnetを使用した際には、一度の会話で$1ほどかかってしまったことがあるので、従量課金のAPIを使う場合は注意かもしれません。「Read files and directories」をAutoApproveにしていたのですが、どんどんファイルを読み込んでいって深掘りをしまくっていたのと、推論出力のコストが高いことが原因としてはありそうです。

他のモデルとしては、o3-miniは、こちらの意図を汲み取りづらく、軌道修正が効きにくいことが多くて微妙でした。また、チャット出力が少ないため、AIが何をしているのか把握しづらいのが難点です。

gemini 2.0 proも評判が良いという噂は聞きますが、experimentalということもあり、まだ使用していません。

※あくまで現時点での私見です。

Devinは非同期・マルチタスクで作業を進めるエージェントだと思いますが、Clineは「同期・シングルタスク」、いわゆるペアプロ的な使い方が一番効果的だと感じています。

その理由は以下の通りです：

• 自然言語だけで全て実装するのはまだ難しく、人が介入した方が効率的なケースが多い
  • 特に複雑で難しいタスクの場合
  • 既存リポジトリのコンテキストを多く含むタスクの場合
• Clineが生成したコードのレビューがボトルネックになりがち
  • 最終的なアウトプットをまとめてレビューするより、Clineが変更したコードを都度レビューする方が楽で安全

一度、2つのリポジトリで並列にClineを動かしてみましたが、どちらもやり取り（ラリー）が増えて進まなくなり、非効率的でした。

ペアプロ的使い方が良いのは、ジュニアエンジニアの場合はペアプロがうまくいくのと同じ原理かもしれません。

Clineの実行を待っている間にマルチタスクしたくなる気持ちもわかりますが、できるだけシングルタスクに集中する工夫が大切だと思います。

Clineとのやり取り（ラリー）が増えれば増えるほど、時間もコストも増大します。また純粋にストレスも溜まるので、ラリーを減らす工夫が重要だと感じています。

• 編集範囲が増えれば増えるほど、Clineの性能は落ちる傾向があるように感じます
  • 大袈裟に言えば、Clineは「あっちもこっちも気になってしまう集中力の低い人」のような特性があります
  • バグが複数あると本筋でないところに気を取られるので、一つずつ完成されたコードを積み上げるのが効果的に思います
• 一気にコードを生成されると、レビューが辛くなります
  • 少しずつ確認していく方が、脳の負荷的にも軽減されます
  • コード量が多すぎると半ば脳死でacceptしてしまい、知らないうちにバグが混入することもあります

• 自然言語だけでは伝わりにくいことも多く、Clineが指示を理解できずにラリーが増えがちです
• 無理に作り直させるより、Clineが生成したコードを自分で修正した方が早いケースが多いです
• Claudeなら、ユーザーが修正した部分も考慮して、続きのコードを書いてくれます

• Clineはリポジトリ全体を読み込めないため、設計の壁打ち相手としては使いづらいです
  • 私の場合は、設計の壁打ちはリポジトリを読ませたGPTsなどを使っています。
  • 複雑なロジックはo1などで事前に検討しておくと良いかなと思います。

• 複雑なタスクや複数ファイルにまたがるタスクでは、ClineのPlan機能（RooCodeではArchitect）で事前に実装方針を固めるのが効果的です
• この段階でのやり取りはそれほど負担にならないので、ここでしっかり方針を固めておきます
• 方針をマークダウンファイルで出力してくれるので、ここでもUserEditを活用すると良いです
• Actモードに移行した際にラリーが最小限になるよう進めます

• Clineはファイルを読み込まないとコンテキストを理解できないため、リポジトリ全体の設定は.clinerulesで教えると効率的です
• Claudeなら.clinerules記載のルールをきちんと遵守してくれることが多いです
  • 守られないこともありますが、「.clinerules読んでやり直して」と指示するだけで対応してくれます

例えば以下のようなルールを記載しています：

• monorepo構成なので、各パッケージの下でテストを実行すること
• テストディレクトリがファイルと同階層に「test」ディレクトリで配置されていること

.clinerules自体もClineを使う中でうまくいかない点があれば更新させると良いです（ただし、基本的なルールはあらかじめ用意しておくと効率的です）。

みんなで育てていける点も魅力です。

• テスト実行してエラーが出たら修正を依頼するのが効果的です
• 完全に解決できないケースもありますが、原因究明が速くなることが多いです
• ただし、基本的にはテストエラーに合わせてコードを修正することが多いので、テスト側に問題がある場合は「テストを直して」と明確に指示する必要があります

拡張機能系:

• Cline
• RooCode（Clineをフォークしたもの。旧RooCline）

VSCode系:

• Copilot Edit
• Cursor Composer

個人的にはRooCodeがおすすめです。

• シンプルにClineの上位互換だと感じています
• RooCodeはClineより動作がサクサクしている印象があります
  • Clineの動作待ち時間が短くなるのは、作業効率に大きく影響すると思います

Copilot EditとCursor Composerは、ファイルの同時編集が行われる点が Clineと体験として異なります。

• Clineでは同時に複数ファイルを操作できないため、マルチタスクが制限されますが、Copilot EditやCursor Composerでは別タブで自動的に編集が行われます
• Cline の場合は、別ファイルを読んでいても、タブが取られてしまうので、その点では体験的には良いです
• ただ、前述したようにシングルタスクの方が効率的だと考えているので、好みの問題でもあるかなと思います。

Copilot Edit と Cursor Composer を比較すると、Copilot Editは機能的にシンプルすぎて、現状ではあまり使う利点が少ないと感じます（まだ使えていませんが、プレビュー版のVSCode Insiderの場合は、エージェントモードがあるので違ってくるかもしれません）。

Cursor Composerは、Cursorの既存機能と組み合わせると開発体験がさらに向上すると感じました。

• タブで既存行も編集できるため、UserEditの体験が良好です（GitHub Copilotだと続きしか書けませんが、Cursorでは既存行の編集も可能です）
  • ただし、ユーザー編集はCursor Composer自体は認識してくれないようで、その点は Cline の方が使いやすいと感じます
• コードやエラーメッセージをCursor Composerにすぐ質問できる機能があり便利です

現時点の感想なので、今後さらに探究を進めていく予定です。

ブラウザやMCPサーバーを組み合わせた使い方はまだできていないので、そこらへんも使ってみたいなと考えています。