クイックサマリー: AIコーディングエディタ Cursor では、Custom Modes・Rules・Subagents・Agent Skills といった仕組みを使い、「実装専用」「レビュー専用」「執筆専用」のような役割（role / subagent）を名前付きで定義できます。役割ごとに成功条件と禁止事項を固定することで、出力品質のぶれとコンテキストの混線を構造的に減らせます。本記事は Cursor 向けの解説ですが、同じ考え方は Claude Code のサブエージェントや Antigravity CLI のスキルにもそのまま応用できます。
「コードを書いて」「ついでに文言も整えて」と、ひとつのチャットになんでも頼んでいるうちに、スコープ外のリファクタが混ざったり、古い前提が後続の回答を汚染したりして消耗していませんか。作業が長引くほど品質のぶれや意図しない寄り道が増えるのは、AIコーディングでよくある課題です。
この課題への実践的な解決策が、役割（role / subagent）を分けて使うという考え方です。Zenn に公開された INTERESTIC 氏の記事「Cursor で役割（role / subagent）をつくるメリット」では、役割分割がなぜ品質を上げるのか、実務でどう設計するかが過度な期待を交えずに整理されています。本記事ではその内容をベースに、設定手順と実開発フローでの使い方を解説します。
- Cursor の Rules / Custom Modes / Subagents / Agent Skills の使い分け
- 役割分割で品質が上がる3つの理由（評価軸・コンテキスト・資産化）
- frontend / backend / infra / writer / reviewer の5役割の設計例
- 役割プロンプトに書くべき6項目と、やりすぎないための境界線
なお、Cursor 本体はクローズドソースの商用プロダクトです（無料プランあり・詳細は公式サイトで確認）。本記事で扱う「役割定義」自体は、ユーザーが自分のプロジェクト内に書くプロンプト資産であり、特別な追加費用はかかりません。
Cursorの「役割（subagent）」とは何か
ここで言う「役割」とは、エージェントに毎回ゼロから人格を説明し直すことではなく、特定の仕事に最適化した指示セットを、名前付きで再利用できる状態を指します。元記事によると、Cursor まわりでは概念として次の層で役割を表現できます。
- Rules: リポジトリ共通の前提・禁止事項・表記ルール（例: ブランド名、コミット方針）
- Custom Modes / Subagents: 仕事単位の成功条件と振る舞い（例: レビュー専用モード）
- Agent Skills: 手順が決まった定型操作（例: PR 作成フロー)
重要なのは、モデルそのものを替えることではなく、同じモデルでも入力の制約と評価基準を固定することです。役割は「誰に頼むか」のラベルであると同時に、「何をしないか」のガードレールでもあります。なお Cursor は2025年10月に Cursor 2.0 でマルチエージェント機能を強化しており、2026年7月時点では公式Xアカウントによると Claude Opus 5 が独自ベンチマーク CursorBench で 66.7 を記録するなど、複数モデル・複数エージェントの並列運用が前提の製品に進化しています。役割設計の価値は今後さらに高まると考えられます。
役割を分けると品質が上がる3つの理由
理由1: 評価軸の衝突を減らせる
「見た目を良くして」「型安全にして」「小さい差分で」と一度に頼むと、エージェントはどれを優先すべきか迷い、スコープ外のリファクタが混ざったり、「動いた」ことと「レビュー可能な差分」が混同されたりします。役割を分けると各チャットに単一の成功条件を渡せるため、出力のブレが減ります。
理由2: コンテキストの混線を防げる
元記事では「長いチャットの最大の敵は、情報不足よりも情報の混線」と指摘されています。同じスレッドで API 設計→CSS 調整→CI 調査と進めると、古い方針や別ドメインの用語が関係ない回答に混ざります。著者自身の体験として、Web ツールの実装とブログ原稿を同じスレッドに載せた結果、コード差分の指摘に「読者への着地」の話が混ざり、どちらも中途半端になったという具体例が紹介されています。モデル能力の上限より先に文脈の純度がボトルネックになることが多い、というのが著者の結論です。
理由3: 専門プロンプトが再利用可能な資産になる
役割を一度きちんと書くと、新規メンバーや未来の自分が同じ品質で作業を始められます。特に効くのは否定形の指示で、「丁寧に書いて」より「未検証の効果を断定しない」「スコープ外のファイルを触らない」のほうが出力のばらつきを抑えやすい、と元記事は述べています。
役割の設定手順 — プロンプトに書く6項目
Cursor では設定画面から Custom Mode や Rules を定義できます（UI 名や配置はバージョンアップで変わりやすいため、正確な設定場所は Cursor の公式ドキュメントで確認してください）。定義するプロンプトの中身が本体であり、元記事によると次の6項目が入っているかが重要です。
- 目的: 何の仕事をする役か（1文）
- 成功条件: 完了と判断する基準
- 禁止事項: やってはいけないこと
- 入力の前提: どの情報があれば着手できるか
- 出力形式: PR 本文、チェックリスト、Markdown など
- エスカレーション: 迷ったら人間に戻す条件
reviewer 役割の記述例
元記事で示されている骨格をそのまま引用します。長い必要はなく、この程度で足りることが多いとされています。
# 役割: reviewer
## 目的
受け入れ条件と差分を照合し、検証可能な指摘を返す。
## 成功条件
- 指摘ごとに「何を見たか」「なぜ問題か」「優先度」が分かる
- 大きな実装修正はしない（指摘に留める）
## 禁止事項
- 未確認の効果・速度を断定しない
- スコープ外ファイルへの「ついで修正」を提案しない
- 秘密情報・本番操作を自己判断で進めない
## 入力の前提
PR 差分、受け入れ条件、変更意図（あれば）
## 出力形式
優先度付きチェックリスト（Critical / Nice-to-have）
## エスカレーション
仕様が曖昧、または本番影響が不明なときは親チャット／人間に戻すRules と Role の分担
よくある失敗は「優秀であれ」とだけ書いて評価軸を曖昧にすることです。ブランド表記や言語方針のようなリポジトリ共通事項は Rules に、フロント特有の UI 原則は frontend 役割に、と置き場を分けるとメンテしやすくなります。プロンプトは一度書いて終わりではなく、失敗を見るたびに1行ずつ更新する運用が現実的です。
実開発フローに組み込む — 5つの役割設計例
最初から大量の役割は不要です。元記事では次の5系統から始めることが推奨されています。
- frontend: UI・アクセシビリティ・コンポーネント境界を担当。成功条件は「既存パターンに沿い、不要な装飾が増えていない」。実装範囲をフロントのディレクトリに限定すると越境が減ります
- backend: ドメイン層・API・テストを担当。「Controller にビジネスロジックを抱え込まない」等のアーキテクチャ制約を書くと効果的です
- infra: Docker / CI / デプロイ担当。「本番操作は明示指示があるまで行わない」という禁止事項の価値が最も高い領域です
- writer: ドキュメント・ブログ執筆担当。実装チャットと混ぜないのが鉄則とされています
- reviewer: 修正役とレビュー役を分けるだけで「作った本人が自分を正当化する」バイアスを減らせます
実際の開発タスクへの適用例としては、「まず reviewer 役で PR 差分と受け入れ条件を照合させ、優先度付きの指摘リストを得てから、frontend 役の新しいチャットで指摘の Critical だけを修正する」という2段階フローが挙げられます。バグ修正なら「調査役で原因仮説を出させ、実装役のチャットには確定した原因と修正方針だけを渡す」形にすると、調査中の誤った仮説が実装に持ち越されません。職種別に見ると、受託開発のエンジニアなら reviewer 役をPRテンプレートと揃えて納品品質を安定させる、テクニカルライターを兼ねる個人開発者なら writer 役でトーンを固定して実装の専門用語混入を防ぐ、SRE 寄りの担当者なら infra 役の禁止事項で危険操作を止める、といった使い方が考えられます。
類似の仕組みとの比較
「役割を名前付きで定義して使い分ける」機能は、Cursor 以外の AI コーディングツールにも存在します。概念は共通なので、一度設計した役割プロンプトは他ツールへ移植しやすいです。
| ツール名 | 対応CLI/エディタ | ライセンス | 最終更新 | 特徴 |
|---|---|---|---|---|
| Cursor（Custom Modes / Rules / Subagents） | Cursor（VS Code フォーク） | クローズド（無料プランあり） | 活発（2025年10月に2.0） | GUI で役割を切替。マルチエージェント並列に対応 |
| Claude Code サブエージェント | Claude Code CLI | 本体はクローズド・定義はユーザー資産 | 活発 | Markdown ファイルで役割定義。ツール権限を役割ごとに制限可能 |
| Antigravity CLI（Agent Skills） | Antigravity CLI | 本体はクローズド・SKILL.md はユーザー資産 | 活発 | SKILL.md をワークスペースに配置して手順・役割を共有 |
いずれも「役割定義そのものはユーザーが書く Markdown/プロンプト資産」という点は共通です。ツールを乗り換えても、成功条件と禁止事項の蓄積は無駄になりません。
注意点 — やりすぎないための境界線
元記事は役割分割を万能とは位置づけていません。客観的に見て、次の制約を理解しておく必要があります。
- 小さな修正まで役割を切り替えると遅い: タイポ修正や1ファイルの明確なバグは汎用チャットで十分なことが多いです。役割分割が向かないケースです
- 役割名が品質を保証するわけではない: 成功条件と禁止事項が本体です。名前だけ fancy な役割は汎用チャットと大差ありません
- UI 名・機能名はバージョン依存: Cursor の画面名や配置は更新されやすいため、「仕事単位の制約」という概念で設計し、正確な操作は公式ドキュメントで都度確認してください
- 人間の判断は省略できない: セキュリティ・法務・本番操作の最終確認は人間側に残すべきです。役割は加速装置であって、責任の委譲先ではありません
- チームでは役割を増やしすぎない: 発見コストが上がり形骸化します。元記事では「常用3〜5役＋稀に使う専門役」程度が推奨されています
セキュリティ面では、役割定義自体はローカルのプロンプト資産であり追加の外部通信は発生しませんが、Cursor 本体はクラウドの LLM にコードを送信して動作します。コード送信を避けたい場合はプライバシーモード等の設定を公式ドキュメントで確認してください。役割プロンプトに API キー等の秘密情報を書かないことも基本です。
まとめ — まずは3役から
- 役割分割の効果は「速さ」より、評価軸の衝突とコンテキスト混線を減らすこと。最初の成果は「変な方向に進む回数が減った」という感覚として現れます
- 役割プロンプトの本体は成功条件と禁止事項。特に否定形の指示（スコープ外を触らない・未検証を断定しない）が効きます
- まずは frontend / backend / reviewer の3役で十分。うまくいった禁止事項だけを共通 Rules に昇格させる運用が現実的です
今日から試すなら、よくやる仕事を3つ書き出し、それぞれに成功条件と禁止事項を5行以内で書き、Cursor の Mode / Rules として保存する——この最小ステップで始められます。より詳しい設計思想は元記事（Zenn）を、機能の正確な設定方法は Cursor 公式ドキュメントを参照してください。なお、同様の役割分割は Claude Code のサブエージェント機能でも標準的に実現できるため、CLI 派の方はそちらから試すのも良い選択と考えられます。
コメント