🎶
Clineの3兄弟をざっくり比較してみた 🧐
Clineの3兄弟（.clinerules / Memory Bank / .mdc）をざっくり比較してみた 🧐
この記事は “AI と一緒にコーディングしてたらプロンプトがカオス化してきた” 私が、悩みを解決すべく Cline の設定ファイルたちを調べたメモです。専門用語はなるべくゆる〜く解説します。
そもそも何が問題？
-
プロンプト肥大化 🤯
「とりあえず全部システムプロンプトに詰め込めばいいや」で始めると、数日後には トークン破産 が待ってます。 -
チームで指示がバラバラ 🙅♂️
Git のコードレビューはやるのに、AI への指示は口頭共有？ それ、後で泣きます。
解決策として Cline が用意してくれているのが 三種の神器：.clinerules, Memory Bank, .mdc です。
.clinerules ― 恒久不変な “社則” ファイル
-
役割: 絶対に守ってほしい大原則 を書く。
-
置き場所: プロジェクト直下 or
~/.clinerules/。 -
ポイント:
- Git でバージョン管理できる → ルールも PR レビュー対象に。
- ファイルが 1KB なら読み込みも爆速。
- 逆に長文化すると応答遅延の元凶⚠️
✏️ Tips: 複数ファイルに分けたいときは
.clinerules/ディレクトリを作って01_base.md,02_security.md…みたいにアルファベット順に並べると良き。
Memory Bank ― AI が忘れっぽい？ ならメモ帳を渡そう
-
役割: 長期記憶。決定事項・進捗ログ・技術メモを Markdown で保管。
-
構造:
memory-bank/配下にprojectbrief.md,techContext.mdなど 6 コアファイルが初期生成される。 -
メリット:
- セッションをまたいでも “前回どこまでやったっけ？” が一瞬で思い出せる。
- ドキュメント化が勝手に進む → ナレッジ共有がラク。
-
デメリット:
- 読み込みトークンが 重い。巨大プロジェクトだとコストがヒリヒリ💸
- 情報が腐ると誤答の温床。定期お掃除は必須！
🚿 お掃除ハック: 週1度 bot に「古い進捗を要約して縮めて」とお願いして自動クリーンアップする仕組みを組むと幸せになれます。
.mdc ― “このフォルダーだけ” ルールを差し込みたいとき
-
役割: front‑matter（YAML）でメタデータを持つ 細粒度ルール。
-
置き場所:
.clinerules/内に置くのがベター。 -
推しポイント:
-
globs: src/**/*.tsxみたいに対象ファイルを絞れる。 - Cursor, RooCode など他 IDE でもそのまま読めるので転用楽ちん。
-
priorityタグで “どのルールが勝つか” を調整可能。
-
-
落とし穴:
- YAML のインデントを 1 つズラしただけで無効化 → プチ発狂案件。
- ルールファイルが増殖すると管理が地獄。
🎯 早見表でおさらい
.clinerules |
Memory Bank | .mdc |
|
|---|---|---|---|
| 主目的 | 恒久ルール | 長期記憶 | 部分適用ルール |
| 読み込み頻度 | 毎タスク1回 | 複数ファイル | 対象操作時のみ |
| トークンコスト | 低 | 中〜高 | 低 |
| メリット | 再現性◎ | 忘れない | 細粒度＆IDE共通 |
| デメリット | 冗長化リスク | お掃除必須 | YAML事故多発 |
🛠️ 実践レシピ
-
まずは
.clinerulesを 1KB 以内で書く
→ “会社の憲法” だけに絞る。 -
コストが気にならない規模なら Memory Bank を導入
- ただし週次で
progress.mdを要約・圧縮する bot を仕込む。
- ただし週次で
-
言語やテスト固有の約束事は
.mdcへ分割- 例：
react-guidelines.mdcにglobs: src/**/*.tsx。
- 例：
-
ルールの衝突は
priority: 1で解決- “勝たせたいファイル” ほど数字を小さく。
TL;DR 💡
- .clinerules = 恒久ルール（軽く・短く）。
- Memory Bank = AI の長期メモ帳（重いので掃除はマメに）。
- .mdc = フォルダー別・言語別の拡張ルール（YAMLミス注意）。
三兄弟をうまく使い分けて、プロンプト破産とおさらばしましょう！
それでは良き AI ライフを〜👋
Discussion