roo cline の token を節約したい
野放図に auto approveを行なうとお金があっという間に溶けていきます。
個人的に感じた重要なポイントを書き残します。
この記事は個人使用で得た知見で間違っている場合があります。
記事記述当初のノウハウであり、rooの更新によって最適化されると思います。
放置する可能性が高く劣化記事となった場合はご容赦ください。
auto approve の段階的な導入
最初のうちは autoapprove off で tokenの溶け具合を観察する。
ファイル読み書きの許可から auto approve を始め、徐々に任せられそうな部分を autoに切り替えていく。
taskを投げて寝て、起きたら出来てる、ようなことができるのがゴールだが、taskや仕様の作り方を工夫する訓練をくりかえして到達することになる。まずは横で rooの動きを観察しながら効率化をはかっていく。
いかに try & error をさせないかを考える
本題。
3回やってまだ続けるようなら、そもそももアプローチに問題があるということ。
そのモデルでは対処できない可能性 o3-mini-hight で解けるときもあるが、コストが高い!!
try&エラーにより ゴミファイルが増大し、プロジェクトが汚損してしまい 最悪の結果になる。
ダメ絶対。
対策:
- n回ミスったら最初からやり直すか、auto approveを off にするよう人格に書く
- 手動で git stash でファイルを消して、アプローチを変えるように伝える(失敗していて、アプローチを変える必要があることをrooに認識させる)
エラーで止まる場合、roo(というかモデル)が疑っている原因が的外れである場合が多い。
cursor や roo の触りはじめでよくあったことだが、延々とtry&errorをつづけてると、無駄な修正で本当にプロジェクトがごみになる。
だいたい、自分でdebugしたほうが早いケースがおおいので、無理にrooにやらせないこと
しかし、違うPCでdebugさせたらすんなり直すこともあったり、モデルのその時の気分(というか、モデルにも使用者の人格が伝わる?)で変わったりするから困る。
memory-bank の最適化
rooが追記する memory-bank が肥大化してプロンプトのたびに読み込みtokenが増大する問題:
- 分解したタスクは tasks/配下に置き、よみこませないようにする
- memory-bank は全体のプロジェクト仕様などを置く
- rooの人格などの基本設定は後述
プロンプトの最適化
- taskの粒度が大きいとプロンプトが長くなる
- 違うタスクを始める場合は、新たにプロンプトを開いて始める
作業確認の効率化
- rooが webブラウザを開くと、大量のtokenを消費するので、ブラウザは開かせない
- サイトを作成するときは、e2eテストを作成させて、e2eテストを通して作業確認させる
MCPの使用制限
- mcpサーバーを極力使わない
- mcpがシンプルなものであろうと、アドオンでtokenを消費する
- mcpは重要技術なので、利用価値があるものは試していきたい
タスク管理の工夫
- taskごとにコミットするので、taskをできるだけ細かく分割する
- 手順作成時に、多すぎるact内容の場合、planを分割させる(例:04-01)
人間側でやったほうが効率的な作業
- 簡単なコマンド実行は、ユーザー側で実行する(pnpm install、ファイル削除など)
- 簡単なプロジェクト全体にわたるリネームなどは roo にやらせない
- シェルやvscodeの一括置換でやればいいだけ(コードを全部読むのでtokenが溶ける)
- プロジェクトに関係ない技術的な質問は他のAIを使って確認する(お金かからないので)
roo の設定
いろんなところに設定する場所があるので迷うが、token消費を抑えるための記述を重要視する。
最初に chtGPTsan に 構成について質問してから始めた
人格設定
- 毎回呼ばれるので端的にかく
- 丁寧な言い回しや細かい説明はみてないので、省略させる
think English, answer in Japanese.
reply simply, not complexity
.clinerules/の設定
- 毎回呼び出されるので厳選
- AIと壁打ちして書く、上書きはさせない
- 日本語で書かない(英語の方が理解力が上がる + Token数節約)
設定項目例:
- コーディング規約
- 開発手法・戦略
- ドメイン知識・独自ルール
- コメントスタイル
- 失敗時のフロー制御(例:"同じファイルへの操作を2回失敗するならプランを再検討して")
- タスク完了の定義(例:"〇〇でのテストが全件通るのがタスク完了です")
- Linter/Formatter/Testツールの使い方(例:"npm scriptに従ってください")
memory-bank
- プロジェクトの細部の仕様を置く
- roo自身が更新する
- 毎回呼び出されるので、置くデータは厳選する
tasks/配下
- 大まかなプロジェクトの構成をAIと壁打ちする
- 壁打ちした結果をタスクに分解して、ここに収める
- 1回のプロンプトで完了するくらいのボリュームにタスクを分解すること
その他TIPS
API利用
- anthoropic のAPIを利用すると、auto approveで実行中にrate limitで止まる
- open routerでクレジットを買えば、止まることがない
モデル選択
- architect: Claude 3.7を使用
- code: Claude 3.5を使用
- 部分的で簡単な仕様変更ならClaude 3.7ではなく、3.5で続ける
- o3-mini-highはdebugに試したがループして使用を諦めた(token使用料も多い)
- そもそもdebugが必要な場合は要注意:
- 仕様に問題がある
- 他の仕様と干渉している
- タスクの粒度が大きすぎる
→ 仕様とタスク整理に戻るほうがよい
参考にしたページ
先人の知見の共有に感謝します。
-
memory-bank最適化について:
https://zenn.dev/jtechjapan_pub/articles/a1cace00f7f96f -
clineとの向き合い方:
https://zenn.dev/berry_blog/articles/c72564d4d89926
Discussion