$100燃やして分かったClineのTips
これなに
前から欲しかったCLIツールがあり、Clineに作らせることにした。
せっかくなのでClineのみで開発した肌感覚が欲しくて、結果として$100かかった血の記録を残す。
前提
- Fork版ではなく、本家のClineの話をする。
- 公式ドキュメントを読まずに突っ走ったので、現場ノウハウ的な内容ではある。
- Amazon Bedrockでの費用感を試したかったので、以下のモデルを利用した。
- Claude 3.5 Sonnet
- Claude 3.5 Haiku
Clineの位置づけ
Clineの基本的な知識及び2024年末までの状況は、この記事で理解できる。
.clinerules
プロジェクト固有のシステムプロンプトは、Clineではclinerulesファイルに記述する。個人用のSetting >> Custom instructions
とは位置づけが異なる。
.clinerules
はルートディレクトリに置いて使う。
Plan/Act
v3.2でPlan/Act Modeが簡単に扱えるようになった。年末年始にv3.0を触っただけの人は必ず押さえておく。
- Plan: Read Onlyでコンテキスト収集、戦略策定、要件理解、実装計画の作成
- Act: Planを引き継いだ効率的な実装、Try&Error
後でも触れるが、このPlan/Actはv3.0のAuto Approve並みに大切な機能なので、必ず理解して使う。
LLMのI/Oコスト
今回利用するClaude 3.5 Sonnet v2とClaude 3.5 Haiku v2のコストがこれだ。入力/出力のコスト比が1:5であることがわかる。
つまりTry&Errorのような書き出し比率の高い進め方をするとトークン費用が嵩む。Clineの内部ツールの話をすると、部分更新用のreplace_in_file
ではなくwrite_to_file
を使うとファイルの全書き出しとなり、費用が高くなるので理解しておく。
Tips
ということで本題に入る。
1. Plan/Actのモデル選定
Plan/Actのモデル選定が気になる人もいると思う。
- Planは必ず賢いモデルで実行する。
- Actは簡単だと思ったら廉価なモデルで実行する。失敗したら適切なモデルで実行する。
$1にタッチするラインという肌感覚でしかないが、これで比較的ワークした。
planモード、すなわちコンテキストが少なく、出力テキスト量が少ないタイミングではハイスペックのモデルを使っても良い。Plan自体の出来が良くないと結局無駄なので、ReasoningモデルやSonnet V2をガンガン使った方が手戻りは少ない。
逆にコンテキストが増えてファイルをガンガン吐くActフェーズ、中盤以降は安価なモデルを選択することで効率よくトークン消費を抑えられる、気がする。失敗して最初からいいモデル使っとけば……ということもある。ActについてはReasoningよりSonnetが良いという情報もあるので、この辺りは引き続き調査が必要だ。
2. Planの質を高める
Planモードで始めるとリポジトリを読み込んで、良い感じのPlanを出してくれて、「あとはActにしてください。」と尋ねられるのだが、焦らない。
良さそうなプランに見えても「10段階でいまどれくらい?」とか「今の出来高を60%として100のものを出せ」だとか、要はブラッシュアップさせるフェーズを必ず挟む。Actの成功率に如実に響くので本当に大事。ここまでの話でわかる通り、PlanフェーズはAuto Aprrove機能を有効にしない方がいい。
3. Planは細分化する
Clineは「全部実装してから全部テストして壊れたらひたすら直せばいいや」という動きをする。財布が壊れるのでこれを止める必要がある。
建てたプランを「細かなステップにして」「各ステップでテストコードのpassを確認して」のような文言で細分化させ、作業スコープを縮める。この進め方だと、Actで頓挫した時にも「ADRのPhase3から続けて」のように再開しやすい点もメリットだ。
4. セーブポイントを作る
Planの結果は必ずセーブする。 ADRでもDesign Docでもなんでも良いから「Planをファイル出力してセーブ」させる。
Actで転けた時にまたPlanをやり直すとSonnet換算で最低$1前後飛ぶので心理的にも金銭的にも負荷が高い。Planのドキュメントは大した量ではないので、ケチらず必ず出力する。
Actで失敗したらPlanでセーブした結果を読ませてタスクを細かく砕く。「ここは失敗したとこなので慎重に進めたい」「タスクを分割して」とか細分化した案を提案してもらう。importの削除やらサッとできる部分はこちらで直してから頼むのも良い。
5. タスク毎に確実にコミットする
Actが成功して、テストも通ったらそこで必ずコミットする。調子に乗ってリファクタを入れるとClineが徹底的に破壊し尽くしてパーになる。愚直に必ずCommitする。
スルスル行くので2,3タスク終わらせてから良いや〜と調子に乗ると出力に失敗してファイルがぶっ壊れる。貴方は調子に載っているのでClineが以前成功した修正を覚えていない。あなたの数ドルは戻ってこない。必ずCommitする。
大事なことなので2回書きました。必ず守ってください。あと見ていて何か変だな?と感じたらその時点で止める。確実に壊れているかループしていると思った方がいい。
6. シェル芸で済むことを任せない
プロダクト名を変えたくなったので変えて〜と頼んだらファイルを端から開き始めて4ドル消費した。絶対にやってはいけない。
ファイルを全部開くみたいな動きは当然入力コンテキスト量が多くなるし、1行置換する度にファイル全てを吐き出すこともある。こういう水平展開的な動きはエディタ・IDEの機能を使ったり、シェル芸をChatGPTに聞くなどしてやった方が圧倒的に安い。
とにかくCline以外にFormatter/Linterやシェル芸でやる選択肢が思いついたら人力で段取りした方が良くて、タスクに落とすのが面倒な一塊を依頼するイメージで任せる。
7. clinerules VS System Prompt
clinerules
チームで守った方がいいものはclinerulesに書く。個人の嗜好以外は全部書いていいと思う。
何を書けばいいかわからない場合は、以下から始める。
- 公式の例
- Roo-Code(旧Roo Cline)の開発で使われている
clinerules
- Cursorの
cursorrules
を引用する
System Prompt
個人の趣味とか必要なものを書く。正直あまり活用できていないので記事にあまり書けることはない。今回は個人のOSS開発なので「think English, answer in Japanese.」だけ書いている。
8. 不要ならMCPモードはOff
厳密には今回の検証後に知ったのだが、MCPのために300トークンが使われているらしい。
※token計算の参考
繰り返すとコストに跳ねるのでSetting >> Advanced Settings >> Mcp: Mode
からOffにする。下に抜粋するコードで分かるように、システムプロンプトも使われなくなる。
${
mcpHub.getMode() !== "off"
? `
## use_mcp_tool
Description: Request to use a tool provided by a connected MCP server. Each MCP server can provide multiple tools with different capabilities. Tools have defined input schemas that specify required and optional parameters.
Parameters:
- server_name: (required) The name of the MCP server providing the tool
- tool_name: (required) The name of the tool to execute
- arguments: (required) A JSON object containing the tool's input parameters, following the tool's input schema
9. 公式ドキュメントを読む
Clineは直感的に触れるOSSであり、今回の開発もほぼ独学で実践した。
ふと公式ドキュメントを見ると充実しているのがわかるので、やはり読んだ方がいいという当たり前の結論に至る。この記事で書いた課題のいくつかも、よりいい方法が見つかるかもしれない。
以下、筆者が独断で選んだページを列挙する。
公式Twitterも積極的なのでWatchしておくと良い。
振り返り
TipsのうちCline固有のものを除くと、「普通の開発プロセスを普通にやろう」という点に尽きる。自然言語で何でもやってくれるAIだ、というより既存のジュニアに任せている作業をいかにオフロードするか、という考え方をする必要がありそうだ。
Appendix.
検証の背景
今回の背景としてAmazon Bedrock OnlyでClineを使ったらどうなるか?という情報が欲しかった。
受託開発時にはツール選定に制約が多々ある。メガクラウドのLLM + VS Code Pluginで完結するClineには注目している。
費用内訳
合計20時間弱かけて$100なので、だいたい$50/日。個人用途でぶん回すと高いが、人件費よりは安いくらいだ。
費用の振り返りはこんなところ
- Claude 3.5 Sonnet v2とClaude 3.5 Haiku v2という安価ではないモデルを採用した。
- 実質的にはBedrockでは3.5 Sonnet(V2)しか選択肢はなさそう。3.5Haikuにランクを落とすと効率は露骨に下がる。
- Clineの癖や頼み方がわからずトークンを浪費してしまった、
- BedrockではPrompt CacheがまだGAされておらず、都度トークンを消費してしまう。
このうち3は自然に解決する問題なのでコストは下がるだろう。また今回書いたように2をブラッシュアップさせれば、10%~15%程度下げられると想定している。
コーディングAgentを使う必要はあるのか
AIコーディングで登場する概念として以下の3つがあり、Clineは3にあたる。
- コード補完ツール
- チャットアシスタント
- コーディングエージェント
1+2はCopilot、副操縦士、秘書相当。3は優秀なインターン生、新卒3年目の部下相当と捉えている。これらは排他ではないので、片方があるからもう片方は要らないとはならない。
Discussion