エージェントのカスタマイズ
コーディングエージェントは、カスタマイズなしでも非常に高い能力を備えています。ソフトウェアエンジニアリングで実証された手法をよく理解しており、概ね適切な判断を下します。
ただし、チーム独自のコーディングスタイル、好みのツール、ビジネスのコンテキストは把握していません。そこでカスタマイズが役立ちます。エージェントを調整することで、より効果的に働かせ、より高品質な出力を得られます。
Cherri Code では、新しいチームメイトをオンボーディングする際の方法に対応した、2 層のカスタマイズを提供しています。エージェントが常に知っておくべきことには ルール を、必要に応じて参照できる専門知識には スキル を使用します。
ルール: 静的コンテキスト
ルールは.cursor/rules/に保存されるMarkdownファイルで、エージェントは会話のたびに開始時に参照します。エージェントがコードを扱う方法を形づくる、常に含まれる指示と考えることができます。
優れたルールファイルは短く具体的で、内容をコピーするのではなく例を参照します：
# Commands- `npm run build`: Build the project- `npm run typecheck`: Run the typechecker- `npm run test`: Run tests (prefer single test files for speed)# Code style- Use ES modules (import/export), not CommonJS (require)- Destructure imports: `import { foo } from 'bar'`- See `components/Button.tsx` for canonical component structure# Workflow- Always typecheck after making a series of code changes- API routes go in `app/api/` following existing patternsルールは、次のような情報に最適です。
- エージェントが把握しておくべきビルド・テストコマンド
- エージェントが従うべきコード規約
- コードベース内の標準的な例への参照
- ガードレール (変更してはいけないファイル、避けるべきパターン)
ルールで避けるべきこと
- スタイルガイドを丸ごとコピーしないでください。 代わりにリンターを使用してください。ルールはツールを置き換えるのではなく、補完するものです。
- すべてのコマンドを記載しないでください。 エージェントは一般的なツールをすでに把握しています。プロジェクト固有のコマンドだけを追加してください。
- まずはシンプルに。 ルールはすべての会話に含まれるため、増えるほど負担になります。エージェントが同じ間違いを繰り返していることに気付いたときだけルールを追加し、短く保ってください。
チーム全体で共有知識を活用できるよう、ルールはgitにチェックインしてください。
スキル: 動的コンテキスト
スキルを使うと、専門知識やワークフローによってエージェントの機能を拡張できます。ルールとは異なり、スキルは動的に読み込まれます。エージェントは、現在のタスクに応じてスキルを使用するか判断します。
スキルはSKILL.mdファイルで定義し、ドメイン知識、カスタムワークフロー、エージェントが実行できるスクリプトやコードを含めることができます。
---description: Deploy to staging. Use when the user asks to deploy, ship, or push to staging.---# Deploy to staging## Steps1. Run `npm run build` and confirm it succeeds2. Run `npm run test` and confirm all tests pass3. Run `npm run deploy:staging`4. Verify the deployment by checking https://staging.example.com/health5. Report the deployment status and URLルールとスキルの主な違い：
| ルール | スキル | |
|---|---|---|
| 読み込まれるタイミング | すべての会話 | 関連する場合のみ |
| 目的 | 常時適用される規約 | 特化したワークフロー |
| コンテキストコスト | 常にコンテキストの容量を使用 | 呼び出された場合にのみ完全なコンテキストを使用 |
| 最適な用途 | エージェントが常に知っておくべきこと | エージェントが依頼に応じてできること |
エージェントが ES モジュールの import ではなく CommonJS の require() を使い続けていることに気付きました。最適な対処法は？
MCP: 外部ツールへの接続
MCP (Model Context Protocol) を使用すると、エージェントを外部ツールに接続し、関連するコンテキストを取り込めます。MCP サーバーは、このコンテキストと、エージェントが必要に応じて実行できるアクションを提供します。
たとえば、エージェントを以下に接続できます。
- メッセージの読み取りや更新の投稿を行う Slack
- 本番環境のログを調査する Datadog
- エラーの詳細やスタックトレースを確認する Sentry
- データを直接クエリする データベース
- デザイントークンやコンポーネント仕様を取得する Figma
使用しているツール向けのサーバーは、マーケットプレイス で見つけられます。
エージェントの機能としてのCLIツール
MCPに加え、エージェントはターミナルにインストールされている任意のCLIツールを実行できます。gh、aws、kubectl、docker などのツールは、追加の設定なしで利用できます。エージェントはこれらを直接実行できます。
ルールで、エージェントに利用すべきツールを指定します。
- GitHub のすべての操作（issue、PR、CI チェック）には `gh` を使用する- ファイルストレージの操作には `aws s3` を使用するデバッグにも役立ちます。CI のステータスを確認したり issue を調べたりするためにブラウザへ切り替える代わりに、エージェントに「gh を使って、この PR で CI が失敗した理由を確認して」と依頼できます。エージェントはコマンドを実行し、出力を読み取り、それに基づいて対応します。
再利用可能なワークフローの保存
エージェント入力で / を使うと、必要なときにスキルを呼び出せます。これにより、スキルを名前でトリガーできる再利用可能なワークフローとして使えるようになり、1日に何度も実行するタスクに最適です。
たとえば、コミット、プッシュ、プルリクエストの作成を行う /pr スキル:
---description: Create a pull request for the current changes.---1. Look at the staged and unstaged changes with `git diff`2. Write a clear commit message based on what changed3. Commit and push to the current branch4. Use `gh pr create` to open a pull request with title/description5. Return the PR URL when donepr: # Create a pull request Create a pull request for the current changes. ## Steps 1. Look at the staged and unstaged changes with `git diff` 2. Write a clear commit message based on what changed 3. Commit and push to the current branch 4. Use `gh pr create` to open a pull request with title and description 5. Return the PR URL when done
Add to Cherri Codeスキルとして役立つその他のワークフロー:
/fix-issue [number]:gh issue viewでissueの詳細を取得し、関連するコードを見つけてバグを修正し、PRを作成/review: リンターを実行し、よくある問題を確認して、対応が必要な点を要約/update-deps: 古い依存関係を確認し、1つずつ更新して、その都度テストを実行
これらをgitにチェックインすれば、チーム全員が実行できます。
カスタマイズの前後
カスタマイズの効果を具体的に見てみましょう。Next.js、Tailwind、Vitest を使用するチームを例にします。
ルール導入前： エージェントはテストに jest を使用し (トレーニングデータでより一般的なため) 、CSS modules でコンポーネントを作成し、API ルートを適当な場所に配置します。
3 つのルールを追加後：
- Tests use Vitest, not Jest. See `src/__tests__/example.test.ts` for patterns.- Style with Tailwind utility classes. No CSS modules or styled-components.- API routes go in `app/api/[resource]/route.ts` following existing patterns.エージェントはデフォルトでチームの規約に従います。会話のたびに同じミスを修正する必要はもうありません。
よくある失敗パターン：ルールの過剰設計
何にでもルールを書きたくなるかもしれませんが、そうしないでください。ルールが多すぎると不要なコンテキストを消費し、エージェントを混乱させる可能性があります。
ルールは最小限に抑え、品質を高く保ちましょう。チームで継続的に更新する共有アーティファクトとして扱うべきです。たまにしか必要ないものは、代わりにスキルに入れてください。
次のステップ
チームのパターンに合わせてエージェントをカスタマイズしました。最終章では、このコースで学んだことをすべて活用したエンドツーエンドの例を通じて、すべてをつなげます。