わざわざ言語化されないClineのコツ
これなに
これを書いた後にClineが盛り上がってきたので、また書きたくなった。二番煎じをやめろ。
大枠では変わってないので軽めのTips集です。
前回から変わった点
一か月前(2025/2/3)に書いた時から状況が変わっている
- ハイブリッド推論モデルとして、Claude 3.7 Sonnetが公開(2/24)
-
Clineのアップデート
-
.clineignoreによる読み込み対象からの除外 -
@terminal,@gitによるコンテキスト理解の改善 - MCP Marketplace
-
-
mizchiさんの魂が震えた
モデル選定(2025/03)
利用経験のあるモデルを主観的にランク付けしている。
- Tier1(基本これでいい)
- Claude 3.7 Sonnet
- Tier2(サブ機)
- Claude 3.6 Sonnet
- Claude 3.5 Sonnet
- Gemini 2.0 Pro
- Tier3(節約用。簡単なActをケチる時)
- Claude 3.5 Haiku
- Amazon Nova Pro（Roo Codeのみ）
- Gemini 2.0 Flash
- Tier4(ミスが多く、使ってはいけない)
- GPT-4o
- o1-mini
- Claude 3.0 Haiku
そもそもTier3以下の予算しか用意できない時は使えない、くらいの認識でいて良い。それくらいTier2とTier3の壁は厚い。
Tier1、Tier2について
Claude 3.7 Sonnetは仕様を納得できるまで読み込むのだけど、結果としてダイナミックにファイルを読み散らかしてトークンが嵩んだりする。他にも動きが全体的に過剰に感じる。Tier1,Tier2という上下関係でなく、使い分けが有効な可能性があることを雑感として残しておく。
Mode戦略
最近は3種類の気持ちを使い分けている。
1. 壁打ち
課題に対してplanするだけ。コードベースに対して単に知恵が欲しい時にやる。どっから何したらいいかわからん時に聞くChat感覚の使い方。
この工程は大事だと思っていて、後述の2.と3.を雑に振る前に不明点をこれで解決するとハッピー。読み込み → ユーザーからのフィードバック → 計画策定がワンストップで便利なので、Cline懐疑派の人もこれだけの為に導入していい。
2. 自動開発
課題に対してPlanし、Actする基本のスタイル。直観的に使えるが概要を知りたい人はこちら。
3. 基本の開発スタイル
課題に対してplanし、設計を吐き出して一度終える。デカそうな課題とか、2. で失敗する匂いがある時はここで止めて落ち着く。
Auto Approve
良くも悪くもClineの特徴となる機能である。
Read
読まれたくないファイルは.clineignoreで制御してるので、基本的に常時有効にしている。
強いて言うとClaude 3.7になってからファイルを開きまくるので、たまに無効にする。しかし提案されたファイルの読み込みを手動で許可するだけなので、無効化は気持ちを落ち着ける儀式にすぎないね。
Write
基本的に常時有効にして、おかしいなと思ったら手動Approveに切り替える。雰囲気がヤバいとマイクロマネジメントになるあれです。沼にハマるのでn回ミスったら最初からやり直す、とマイルールを立てておくと良い。
Exec
最近はコマンド実行を自動にしなくなった。安全性もそうだが、コマンド承認のタイミングを停止点にして、休憩なり処理の見直しの時間に充てている。
打つべきコマンドは自動で提案してくれるので、承認を手動にしても不満はそこまでない。
Auto Approveを安全に使いたい
Clineのコマンド実行も自動実行させたい場合、安全性を担保する方法をパッと思いつく限りではこんな所だろうか。
- devcontainer
- Web IDE
- 何らかのSandBox機構
私は考えるのが面倒なのと、あまりマシンパワーが必要なことをしていないのでWeb IDEで済ませている。良さげなSandBox機構が生まれると良いね。
.clinerules/system prompt
AI様だからなんでも出来るだろう、じゃなくて普通のオンボーディングを真面目にやるのが大事。
Must
やらないと性能に影響する
- MemoryBank
- 失敗時のフロー制御
- ex. "同じファイルへの操作を2回失敗するならプランを再検討して"
- タスク完了を定義する
- ex. "〇〇でのテストが全件通るのがタスク完了です"
- Linter.Formatter,Testツールの使い方
- ex. "Lint.Format,Testはnpm scriptに従ってください。具体的な使用例は～"
Should
やらないと完成はするが、出来栄えに満足できないもの
- 開発手法・戦略
- ドメイン知識・独自ルール
- コメントスタイル
No
- 〇〇は読まない、は
.clineignoreに書く。 -
.clinerulesは日本語で書かない。- 英語の方が理解力が上がるらしい。少なくとも実利としてToken数を節約できる
- 内容を確認したくなったらAIに日本語で読み上げてもらう
理念より実例が見たい
Appendix. 筆者の意見
Clineがフレームワークの使い方を間違える
これを参考に.cline/とかに教材としてのテキストを置く
どのフォークを使えばいいの
本家とRoo以外は考えない。私は本家で困っていない。
AWSユーザー向け
Cline側の実装は済んでいるので、Bedrock Prompt CachingがGAするまでは耐えましょう。Nova Proを代替えにすると安いが、世間で利用されている水準からすると繋ぎレベル。
SI/SES業界が興味を持つべきか？
短期的には単金や利益率に影響するので目を背けたくなるのはわかるが、他の省力化ソリューションと同様にかなりの確率でこちらの業界にも来る。明確に人件費・要員調達に実利があるため。Agentを”使える”側になるように早めにキャッチしておく。
Clineに賭けるべきか？
賭けなくてもいいが、実感で判断できる程度には触る。AWSやk8s並に開発者の前提が変わるプロダクトの可能性が高いので、概念が複雑化する前にClineの感覚を身体に叩き込まないと振り落とされてしまう。星取表や公開事例を待ってからでは遅いという焦燥感は持った方がいい。
Discussion