記事一覧

みなさん、AI アシスタントの「Cline」使ってますか？便利なんだけど、もっと便利にしたいなーって思ったことありませんか？今回は公式ドキュメントを元に、Cline をプロジェクトに合わせてカスタマイズする方法を解説していきます！

Cline をカスタマイズする方法は主に 2 つあります：

1. <strong>Custom Instructions（ユーザー設定）</strong>：VSCode 全体に適用される個人設定

1. <strong>.clinerules ファイル/フォルダ</strong>：プロジェクト固有の設定

<code>.clinerules</code> ファイルは、プロジェクト固有の指示を Cline に与えるための設定ファイルです。これをプロジェクトのルートディレクトリに置くことで、そのプロジェクト内での全てのやり取りに影響を与えることができます。

ユーザー固有の設定（Custom Instructions）が VSCode 全体で適用されるのに対して、<code>.clinerules</code>はプロジェクトごとに異なる設定を適用できる、という違いがあります。さらに、<code>.clinerules</code>はバージョン管理システムでチーム全体と共有できます。

以下のような目的で使用できます：

• チームメンバー間でプロジェクトの基準を統一
• 開発プラクティスの徹底
• ドキュメント要件の管理
• 分析フレームワークの設定
• プロジェクト固有の動作定義

# プロジェクトガイドライン
## ドキュメント要件
- 機能を修正する際は /docs の関連ドキュメントを更新する
- README.md を新機能と同期させる
- CHANGELOG.md にエントリを追加する

## アーキテクチャ判断の記録
以下の場合はADRを /docs/adr に作成：
- 主要な依存関係の変更
- アーキテクチャパターンの変更
- 新しい統合パターン
- データベーススキーマの変更
  /docs/adr/template.md のテンプレートに従う

## コードスタイルとパターン
- OpenAPI Generatorを使用してAPIクライアントを生成
- TypeScript axiosテンプレートを使用
- 生成されたコードは /src/generated に配置
- 継承よりコンポジションを優先
- データアクセスにはリポジトリパターンを使用
- エラー処理は /src/utils/errors.ts のパターンに従う

## テスト基準
- ビジネスロジックにはユニットテストが必須
- APIエンドポイントには統合テストを実施
- 重要なユーザーフローにはE2Eテストを実施

大規模なプロジェクトでは、単一の <code>.clinerules</code> ファイルではなく、<code>.clinerules</code> フォルダを使用することもできます。以下のような構造で管理します：

your-project/
├── .clinerules/           # アクティブなルール
│   ├── 01-coding.md      # コーディング標準
│   ├── 02-documentation.md # ドキュメント要件
│   └── current-sprint.md  # 現在のスプリント用
├── clinerules-bank/      # 利用可能なルールの保管庫
│   ├── clients/          # クライアント固有のルール
│   ├── frameworks/       # フレームワーク固有のルール
│   └── project-types/    # プロジェクトタイプ別の標準
└── ...

この構造のポイントは、<code>.clinerules/</code> フォルダ内のすべての Markdown ファイルが自動的に読み込まれ、統合された 1 つのルールセットとして扱われる点です。ファイル名の先頭に数字を付けることで、論理的な順序を指定できます。

1. <strong>文脈に応じた活性化</strong>：必要なルールだけを活性化
2. <strong>メンテナンス性の向上</strong>：個別のルールファイルを独立して更新可能
3. <strong>チームの柔軟性</strong>：タスクに応じて必要なルールを適用可能
4. <strong>ノイズの削減</strong>：アクティブなルールセットを必要最小限に

Cline v3.13 からは、<code>.clinerules</code>ファイルとフォルダの管理がさらに簡単になりました！チャットインターフェースの入力フィールドの下に専用のポップオーバー UI が追加されています。

この UI でできることは：

1. <strong>現在有効なルールの確認</strong>：グローバルルール（ユーザー設定から）とワークスペースルール（<code>.clinerules</code>ファイルやフォルダの内容）のどちらが現在有効かを即座に確認できます。
2. <strong>ルールの簡単切り替え</strong>：ワークスペースの<code>.clinerules/</code>フォルダ内の特定のルールファイルを、クリック一つで有効/無効にできます。これは<code>react-rules.md</code>や<code>memory-bank.md</code>などのコンテキスト固有のルールを必要な時だけ活性化するのに最適です。
3. <strong>ルールの追加・管理</strong>：ワークスペースに<code>.clinerules</code>ファイルやフォルダがまだ存在しない場合は、簡単に作成したり、既存のフォルダに新しいルールファイルを追加したりできます。

これにより、会話中にファイルや設定を手動で編集することなく、コンテキストの切り替えや異なる指示セットの管理が大幅に簡素化されます。

Cline には<code>.clineignore</code>という設定ファイルもあります。これは<code>.gitignore</code>に似た機能で、コードベースの分析時に無視するべきファイルやディレクトリを Cline に指示するためのものです。

主な目的：

• ノイズの削減：自動生成されたファイル、ビルド成果物などの不要なコンテンツを除外
• パフォーマンスの向上：Cline が処理する必要のあるコードの量を制限
• 注目点の絞り込み：コードベースの関連部分に Cline の注意を向ける
• 機密データの保護：機密設定ファイルへの Cline のアクセスを防ぐ

例：

クライアントプロジェクトを切り替える場合：

# クライアントBのプロジェクトに切り替え
rm .clinerules/client-a.md
cp clinerules-bank/clients/client-b.md .clinerules/

フロントエンドプロジェクトの場合：

# Reactプロジェクトの設定を適用
cp clinerules-bank/frameworks/react.md .clinerules/

• 個々のルールファイルは特定の懸念事項に焦点を絞る
• ルールの目的を明確に示す分かりやすいファイル名を使用する
• アクティブな<code>.clinerules/</code>フォルダを gitignore に入れつつ、<code>clinerules-bank/</code>は追跡するという方法も検討する
• 一般的なルールの組み合わせを素早く有効化するためのチームスクリプトを作成する

.clinerules ファイルを作成する際は、以下の点を意識すると効果的です：

• <strong>明確かつ簡潔に</strong>: シンプルな言葉で、あいまいさを避ける
• <strong>望む結果に焦点を当てる</strong>: 具体的な手順ではなく、求める結果を説明する
• <strong>テストと改善</strong>: 実験を繰り返し、自分のワークフローに最も合う方法を見つける

<code>.clinerules</code> ファイル（またはフォルダ）を活用することで、Cline をプロジェクトの要件に合わせて細かくカスタマイズすることができます。チーム全体で一貫した開発プラクティスを維持しつつ、必要に応じて柔軟に設定を変更できる、強力なツールといえます。

2025 年の最新機能であるポップオーバー UI を使えば、会話中にもルールを柔軟に切り替えられるようになり、より使い勝手が良くなっています。

ぜひ、あなたのプロジェクトでも<code>.clinerules</code>を活用して、より効率的な開発環境を作ってみてください！

参考：[Cline Rules Documentation](https://docs.cline.bot/prompting/prompt-engineering-guide)