こんにちは！アルダグラムでエンジニアをしているkageyamaです。
最近のAIの発展は目覚ましく、普段の開発業務における生産性向上に大きく貢献しています。
弊社開発部でも、今年から積極的にAIツールの導入・活用を進めており、AI戦略ユニットも発足しました。
現在は色々なツールを各自が試しながら知見を共有して、より良い開発体験を模索しています。2025年4月時点で、開発部では以下のAIツールを全社員が利用できる環境を整えています。
- ChatGPT
- Claude
- OpenAI Platform
- Devin
- Gemini Code Assist
- Cursor
- Junie
- Cline (RooClineも含む)
この記事では、上記の中でも Cline を扱いやすくするために導入した .clinerules について、その知見を共有していきます。
目次
- アルダグラムでの.clinerulesの役割
- 導入の背景と目的
- 実装における重要な議論
- 余談：.roomodes はコミットしない
1. アルダグラムでの.clinerulesの役割
.clinerulesとは：
Cline のシステムプロンプトで参照されるファイルで、プロジェクト内のすべての指示に
影響されるファイルとなる。開発に必要なコンテキストを詰めることで、出力の精度をあげたり、
セキュリティ的な面で .env は読み込まない等の制御が可能。
弊社では、主に以下の3つの役割を担っています：
-
プロジェクト固有のコンテキストの共有
- 技術スタック（Next.js, TypeScript, GraphQLなど）
- アーキテクチャ設計（Atomic Design, コンポーネント責務分離）
- コーディング規約（命名規則、ファイル構成）
-
セキュリティ境界の設定
- 機密ファイル（.env, APIキーなど）へのアクセス制限
-
開発効率の最適化
- 巨大ファイル（schema.graphql, package-lock.json等）の扱いに関するガイドライン
- プロジェクト固有の注意点や推奨プラクティス
2. 導入の背景と目的
2-1. max_tokens 問題
.clinerulesを設定する前までは、GraphQLスキーマファイルなど数万行規模のファイルをAIに自動読み込ませた場合に max_tokens 問題が発生していました。そのため、プロンプトで
schema.graphqlは、max_tokensに引っ掛かるため読み込まないでください。どのschema情報が欲しいかを教えてください。
といった情報を差し込まざるを得なかったですが、コレは非常に不便です。
.clinerules(と.clineignore)では、このような巨大ファイルの取り扱いを読み込ませないように事前コンテキストで定義できます。
2-2. セキュリティリスクの軽減
.envファイルやAPIキーなどの機密情報の取り扱いは、開発者の判断に委ねるには大きなリスクがありました。
.clinerules, .clineignore によって、これらのファイルへのアクセスを明示的に制限し、セキュアな開発環境にしたいと考えていました。
2-3. 品質の向上を目指して
個人のプロンプトによって生成されるコードの品質にはばらつきが生じると思いますが、ドメイン固有の事前コンテキストによって左右される場合は改善することができます。
例えば、1ヶ月前に入社したメンバーでも5年目のメンバーでも、 .clinerules で事前コンテキストが整っていれば品質は一定水準で保たれるはずです。
3. 導入時の議論
.clinerules を導入するにあたって、Cline をすでに利用したことのあるメンバーと一緒に議論した結果、重要な方針は下記になりました。
実装手順などの依存されたくないルールは記載せず、必要最低限の記載にする
.clinerules の役割は「事前コンテキストの提供」に限定すべきだと判断しました。これは、実装手順や、GoFパターンなどの提案は、毎回のタスクによって変更が発生するものであり、チーム全体で扱う .clinerules には不適切になるからです。チーム全体でそれらの制約をかける組織も存在すると思いますが、弊社ではそのようなルールは現在細かく設定しておりません。
そのため、.clinerules は、拡張README.md みたいな位置付けで考えています。オリジナルで追加したいコンテキストは、ローカルコンテキストで加えてあげれば良いはずです。
上記の制約により、プロジェクト自体に追記する rules は限定的になり、メンテナンスもしやすいと感じています。
4. 余談 .roomodes はレポジトリには含めない
当初、私は .roomodes も導入した方が何かと良いかもと考えていました。
個人の開発環境をカスタマイズする強力な .roomodes ですが、結果的には「含めない」という判断をしました。理由は、
- 個人の開発スタイルは尊重したい
- プロンプトの多様性を維持
- 画一的なアプローチを避ける
などが挙げられます。RooCline であれば、ローカルでの設定も可能なので、その案内だけを Notion に記載しました。
実際の.clinerules構成と解説
.clinerules の構成にあたって、mizchi さんが公開している .clinerules を大いに参考にさせていただいているため、この場で感謝を申し上げます。
1. 重要な前提事項
AIと開発者の関係性定義し、「開発支援ツール」として位置づけることで、適切な活用促進を目指します。
## 重要
ユーザーはClineよりプログラミングが得意ですが、時短のためにClineにコーディングを依頼しています。
ただし、ClineはGitHubから学習した広範な知識を持っており、個別のアルゴリズムやライブラリの使い方は私が実装するよりも速いでしょう。
反面、現在のコンテキストに応じた処理は苦手です。コンテキストが不明瞭な時は、ユーザーに確認します。
## 作業開始準備
`git status` で現在の git のコンテキストを確認します。
もし指示された内容と無関係な変更が多い場合、現在の変更からユーザーに別のタスクとして開始するように提案してください。
無視するように言われた場合は、そのまま続行します。
2. プロジェクト技術スタック
技術スタックを明確に定義することで、AIが生成するコードが既存のプロジェクト構成と整合性を保つことを目指します。
# プロジェクト概要
KANNAはNext.jsで構築されたフロントエンドアプリケーションです。主に以下の技術スタックを使用しています：
- フロントエンド
- Next.js (Page Router)
- TypeScript
- GraphQL
- Material UI
- バックエンド連携
- Firebase認証
- GraphQLによるAPI通信
- テスト
- Jest
- Storybook (UIコンポーネントカタログ、VRT)
3. コーディング規約とベストプラクティス
プロジェクト固有の開発方針を明確にすることで、AIが生成するコードの品質と一貫性を確保することを目指します。
実装方針は提案しませんが、一般的なアプローチ手法やプラクティスについては軽く記載することにしました。
# 技術スタックとベストプラクティス
## TypeScript関連
### 関数型アプローチ (FP)
- 純粋関数を優先
- 不変データ構造を使用
- 副作用を分離
- 型安全性を確保
## プラクティス
- 小さく始めて段階的に拡張
- 過度な抽象化を避ける
- コードよりも型を重視
4. アーキテクチャ設計指針
アーキテクチャの設計方針を明確にすることで、AIが生成するコンポーネントが既存の設計パターンに従うことを目指します。
# UIコンポーネント設計
## Atomic Design
KANNAではAtomic Designの原則に従ってUIコンポーネントを構築しています：
- **Atoms**: 最小単位のコンポーネント
- **Molecules**: 複数のAtomsを組み合わせた機能単位
- **Organisms**: 特定の機能を持つ複雑なコンポーネント
- **Templates**: ページのレイアウト構造
- **Pages**: 実際のページコンポーネント
## コンポーネントの責務分離
- **Presentational Components**: 見た目のみに責任を持つ
- **Container Components**: データ取得やロジックを担当
- **Custom Hooks**: ロジックの再利用を促進
5. プロジェクト構造とファイル規約
プロジェクト構造とファイル命名規則を明確にすることで、AIが適切な場所に適切な名前でファイルを生成できることを目指します。
# プロジェクト構造
./
├── pages # Next.jsのページコンポーネント
│ └── ... # 各ページコンポーネント
└── src
├── config # 設定ファイル
├── lib # ユーティリティライブラリ
├── ui # UIコンポーネント
│ ├── atoms # 最小単位のコンポーネント
│ ├── molecules # 複数のAtomsを組み合わせたコンポーネント
│ ├── organisms # 特定の機能を持つ複雑なコンポーネント
│ ├── templates # ページのレイアウト構造
│ └── styles # グローバルスタイル関連
└── core # UI非依存のコード
├── graphql # GraphQL関連
├── hooks # カスタムフック
└── interfaces # 型定義
└── master # マスターデータ
## ファイル命名規則
- Reactコンポーネント: PascalCase
- ユーティリティ関数: camelCase
- pagesディレクトリ: kebab-case
6. セキュリティガイドライン
# セキュリティガイドライン
## 機密ファイル
以下のファイルの読み取りと変更を禁止：
- .env ファイル
- APIキー、トークン、認証情報を含むすべてのファイル
## セキュリティ対策
- 機密ファイルを絶対にコミットしない
- シークレット情報は環境変数を使用する
- ログや出力に認証情報を含めない
セキュリティに関する明確なガイドラインを設けることで、機密情報の取り扱いに関するリスクを最小限に抑えています。
7. GraphQL関連の指針
GraphQL関連の指針を明確にすることで、アルダグラム全体で決めたルールに従って実装することを目指します。ドメイン固有なルールをどこまで書くかは難しいのですが、配置場所などの定義などは早々変わることはないと判断し加えています。
# GraphQL関連
- クエリファイルは対応するコンポーネントと同じディレクトリに配置
- フラグメントを活用して再利用性を高める
- 必要最小限のデータのみを取得
- 型生成を活用してタイプセーフなコーディング
## GraphQLファイルの配置場所
基本的には、ページ表示用クエリと UI 操作から実行されるコンポーネントの隣に配置します。
- ページ描画時やUI 操作から非同期に実行する GraphQL クエリ
- GraphQL クエリを実行するコンポーネントの隣 (同階層のディレクトリ内) に配置
- 例
- `foo`
- `foo.graphql`
- `foo.tsx`
- `bar`
- `bar.graphql`
- `bar.tsx`
- Fragment
- 原則、`hogehoge/fragment.graphql` の fragment は新規では使用しない
- fragment を利用する場合は、各ページ・機能ごとに定義した fragment ファイルを作成すること (依存関係を最小限にする)
- hogehoge/fragment.graphql には配置せず、各機能・ページごとに fragment ファイルを作成
- 例
- foo
- `a/b/c/fooFragment.graphql`
- bar
- `d/e/f/barfragment.graphql`
- ただし、fragment を利用せず実装できるのであれば、積極的には使わない
8. ignoreファイルの指定
## 読み込まない方が良いファイル
以下のファイルはステップ数が多いため、max_tokensとなりやすいファイルになります。基本的には読み込まないで必要な箇所を質問するようにしてください。
- schema.graphql
- graphql.ts
// 割愛
9. その他
そこまで重要ではないので割愛しますが、その他で言うと
- 多言語対応
- パフォーマンス最適化
- Storybook
- テスト
- importルール
- 人格（ずんだもんを採用しました）
などのルールも指定しました！
まとめ：効果的な .clinerules 設定のために
アルダグラムでは、現状 .clinerules を「制約」ではなく「ガイドライン」的な立ち位置にいると考えています。どこまでの事前コンテキストがあると AI 側がスムーズに開発支援をできるか、模索中の段階ではありますが今後もより良い環境を提供していきたいですね。
.clinerules に今後大きな変更が発生するかもですが、組織で Cline を活用する上での参考になれれば幸いです。
もっとアルダグラムのエンジニア組織について知りたい方は、以下のリンクをご覧ください：
株式会社アルダグラムのTech Blogです。 世界中のノンデスクワーク業界における現場の生産性アップを実現する現場DXサービス「KANNA」を開発しています。 採用情報はこちら: herp.careers/v1/aldagram0508/
Discussion