やあやあ ボクはずんだ餅の精霊 ずんだもんなのだ
いまやAIコード支援ツールとしてCursorやClineが注目を集めているけれど プロジェクト独自のルール管理はとっても重要なのだ
かつては「.clinerules」という単一ファイルに全部まとめるのが一般的だったけれど 規模が大きくなると管理や解析が大変で不便になるケースが多かったんだ
そこで新方式として登場したのが「.mdcファイル」なのだ
そしてClineには「カスタムインストラクション」という素敵機能があって これを活用するとプロンプト運用がとても効率化されるから ぜひ最後まで読んでほしいのだ
まずは全体像からお話するのだ
従来の.clinerulesは単一ファイルで 大量のルールを詰め込む形だったから 大規模プロジェクトではカオスになりがちだったのだ
.mdcファイル方式では YAMLヘッダとMarkdown本文を組み合わせ 複数ファイルに分割できるメリットを提供するんだ
またClineにはユーザーごとの「カスタムインストラクション」があるから プロジェクト全体のルールと個人の好みを両立しやすくなるのだ
上の図のように clinerulesの単一ファイルスタイルから mdcファイルへの移行で 多くの課題が解消されるのだ
ボクがよく見る例としては .clinerulesに 「変数名はキャメルケースに統一」「セキュリティ上の理由で.envファイルは読み込まない」 などが書かれているケースがあるのだ
単一ファイルに全て詰め込むだけなので 小規模なプロジェクトならそれほど苦にならないかもしれない
しかしメンバーが増えたり コード量が増えたりすると あっという間に読みづらいファイルになってしまうのだ
拡大すると管理も大変で 適用範囲を細かく設定したい場合も柔軟に対応できなくなるんだ
1 管理の大変さ
巨大な1ファイルにルールを押し込むため どこに何が書いてあるか分かりづらいのだ
2 柔軟性の欠如
すべてのファイルに同じルールが適用されるので 「このディレクトリだけ別のコーディング規約」 といった指定が難しい
3 Markdownの曖昧さ
書式に統一感がなく 自動解析が難しい事例も多発
こうした課題の結果 よりスマートな運用方法が望まれるようになり それを叶えるのが.mdcファイル方式なのだ
.mdcファイルは YAML形式のヘッダ情報とMarkdown本文を組み合わせたファイル形式なのだ
具体的にはこんな感じ
---
Description: セキュリティルール
Globs: [**.js, **.ts]
---
# セキュリティのガイドライン
- 機密情報をコードに書かない
- .envファイルは除外
この仕組みを使うと たとえば「security.mdc」「style.mdc」「test.mdc」と分割して カテゴリごとに配置できるのだ
Globsとはファイルパターン指定のことなのだ
たとえば
Globs: [src/**/*.js]
と書けば src配下のjsファイルだけに適用される
これによって「テストファイルには別ルール」「ドキュメントファイルには別ルール」など 細かい制御が可能になるのだ
カテゴリ分けしやすく 適用範囲も明確 というのが.mdcファイル最大の強みなのだ
1 現在の.clinerules内容を読み込む
まず全体を見て ルールを整理する
2 .cursor/rulesディレクトリを作成
ここに複数のmdcファイルを置くのだ
例: security.mdc style.mdc test.mdc
3 YAMLヘッダとMarkdown本文を書き込む
先頭に
---
Description: セキュリティルール
Globs: [**.js, **.ts]
---
などと書いてから 具体的なルールをMarkdown形式で書く
4 ClineやCursorを再起動
ツールが新しいmdcファイルを認識しているか確認する
5 テストで挙動を確かめ 不備がなければ旧.clinerulesを退避
このステップを守ればスムーズに移行できるはずなのだ
それでも .clinerulesの単一ファイル運用よりは遥かに拡張性が高いのだ
Clineでは ユーザーごとに設定できる「カスタムインストラクション」という欄があるのだ
VSCodeの拡張設定画面で「Custom Instructions」を開き テキストを入力して保存するだけで いつもそのインストラクションがClineのベースラインになるんだ
例として
を書いておくと 個人の開発スタイルがプロジェクトをまたいでも維持されるのだ
つまり.mdcrulesや.mdcファイルがプロジェクト単位の設定なのに対し カスタムインストラクションはユーザー単位の設定になるのだ
まだmdcに移行できない あるいは移行途中という場合もあるかもしれないので clinerulesの具体例を紹介するのだ
# Security
# Sensitive Files
DO NOT read or modify:
- .env files
- **/config/secrets.*
- **/*.pem
- Any file containing API keys tokens or credentials
# Security Practices
- Never commit sensitive files
- Use environment variables for secrets
- Keep credentials out of logs and output
こんな感じで セキュリティ上注意すべきファイルを明記し「読むな」「書き込むな」と強調しておくと トラブルを避けやすい
mdcにするなら YAMLヘッダを加えて 拡張子を.mdcに変え Descriptionで「セキュリティルール」と明示すると さらに分かりやすくなるのだ
Clineの魅力はチャット形式で指示を与えることだけど プロンプト運用を工夫しないと 効率が下がってしまうのだ
以下の点を意識すると かなりスムーズに作業が進むはずなんだ
1 文脈を十分に提示
どのファイルを編集するのか どういう目的なのか 明確に説明する
2 大きなタスクは分割
「DBモデル作成」「APIエンドポイント追加」「テストケース作成」 のように段階を踏む
3 具体的な質問
「エラーの根本原因は何？」「自信度は1から10でどれくらい？」 のように聞く
4 レビューで微調整
Clineが提案したコードをチェックし 「可読性を上げて」「テストカバレッジを確保して」など 追加要求を都度与える
このループを回すことで コード品質や生産性がぐぐっと高まるのだ
コミュニティでもいろいろなプロンプトテクニックがシェアされているのだ いくつか挙げてみるね
こういう風に「やってほしいこと」「チェックしたいこと」をプロンプトに盛り込むと Clineが適切に行動しやすくなるんだ
ここではClineを上手に使うコツをまとめるのだ
1 mdcファイルでチームルールを管理
security.mdc style.mdcなど 分割してコミットすると 全員が同じ環境を再現できる
2 カスタムインストラクションで個人の希望を統一
コーディングスタイルやログ形式など 自分だけの方針を指定して常に適用
3 プロンプトを段階的に
大きな要望を一気に出すより 小さなタスクに分けて都度指示する方が誤りが少ない
4 AIの回答を見て微調整
「もう少しメモリを意識した実装にして」「モジュールを分けてほしい」などリアルタイムで伝える
5 秘密情報やセキュリティ関連のルールを厳密に
特に.envやAPIキーに触れないよう明言しないと 思わぬ漏洩につながる可能性がある
今すぐ.mdcに移行できない人もいるはず そんなときでも少し工夫すると clinerulesが多少見やすくなるのだ
例えば
# Project Guidelines
# Documentation Requirements
- 常にREADMEを更新
- docsディレクトリを機能追加に合わせて刷新
- CHANGELOG.mdに追記
# Architecture Decision Records
- ライブラリのバージョン変更や新しいアーキ導入時にdocs/adrへまとめ
- docs/adr/template.mdを活用
# Code Style and Patterns
- OpenAPI Generatorでコード生成
- src/generated下に集約
- エラーはsrc/utils/errors.tsの方式
- 継承よりコンポジション優先
# Testing Standards
- 単体テスト必須
- 統合テストでAPI確認
- E2Eテストで主要フロー検証
こうしてセクションを分けるだけでも なんとなく見通しが良くなるんだ
最終的には.mdcファイルへ移行するとより便利なのだ
AIコード支援ツールは 今後ますます高機能化していく可能性が高いのだ
Clineもバージョンアップごとに 新しい連携方法や解析手法が追加されるかもしれない
そのときにmdcファイル方式なら カテゴリごとのルール拡張が比較的楽で カスタムインストラクションとの相性も良いのだ
こうした新機能との連携を考えると mdcファイル方式へシフトしておくのが得策なのだ
ここまで読んでくれたみんなには .clinerulesが抱えていた課題と .mdcファイルのメリット そしてClineのカスタムインストラクションの活用法が少しでも伝わったら嬉しいんだ
1 clinerulesは単一ファイルで簡単だけど 大規模になると管理困難や柔軟性不足が目立つ
2 .mdcファイルは YAMLヘッダ+Markdown本文により 複数ファイル化 グロブ指定で範囲を明確にできる
3 Clineのカスタムインストラクションはユーザー単位で共通するルールを設定できるため プロジェクトを超えた個人の開発方針を維持できる
4 プロンプト運用が重要で チャット形式の指示をわかりやすく分割し フィードバックを繰り返すのがポイント
5 将来的にAIが進化しても .mdcファイル方式は拡張が容易なので 早めの移行を検討する価値がある
ボクがオススメする運用は
1 mdcファイルで「セキュリティ」「スタイル」「テスト」などに分割して管理
2 Clineのカスタムインストラクションで個人的な好みを設定
3 チャットプロンプトに「コード省略禁止」「分析先行」など明確な要求を入れてAIを導く
こうすると 開発効率と品質が同時に向上するはずなのだ
皆さんも ぜひ自分のプロジェクトで試してみてね
ずんだもんの解説はここまでなのだ
また会う日まで ごきげんようなのだ