ある夜、ひとつのチャットに「この PR の差分を小さく」「見出しのトーンも整えて」と続けて頼んだことがありました。返ってきたのは動くコードと、レビューコメントに混ぜにくい長い説明文でした。指示はどちらも正しそうなのに、成功条件が二つあると、出力はどちらにも中途半端になります。
AIコーディングエディタを使い始めると、最初は「コードを書いて」「このバグを直して」と、ひとつのチャットになんでも頼んでしまいがちです。それでも動くことは多い。ただ作業が長引くほど、品質のぶれや、意図しない方向への寄り道が増えます。
そのときに効くのが、役割（role / subagent / persona）を分けて使うという考え方です。Cursor では Custom Modes、Rules、Subagents、Agent Skills といった仕組みで、「フロント専用」「レビュー専用」「記事執筆専用」といった振る舞いをあらかじめ定義できます。本記事では、なぜ役割分割が品質を上げるのか、実務でどう設計するかを、過度な期待を交えず整理します。
目次
- Cursor で「役割」をつくるとは何か
- なぜ役割を分けると品質が上がるか
- コンテキスト混線を防ぐ効果
- 専門プロンプトを資産として再利用できる
- 実務で使える役割分割の例
- 役割設計のコツ（プロンプトに書くこと）
- 個人開発からチーム運用への拡張
- やりすぎないための境界線
- 今日から試せる最小ステップ
- まとめ
Cursor で「役割」をつくるとは何か
ここで言う「役割」とは、エージェントに毎回ゼロから人格を説明し直すことではありません。特定の仕事に最適化した指示セットを、名前付きで再利用できる状態を指します。
Cursor まわりでは、だいたい次のような層で役割を表現できます（製品の UI 名や配置は更新されやすいので、概念として捉えてください）。
| 層（概念） | 向いていること | 置きすぎると起きやすいこと |
|---|---|---|
| Rules | リポジトリ共通の前提・禁止・表記 | 仕事固有の詳細まで押し込み、メンテが重い |
| Custom Modes / Subagents | 仕事単位の成功条件と振る舞い | 役が増えすぎて、どれを使うか迷う |
| Agent Skills | 手順が決まった操作（PR 作成など） | 「人格」代わりに使い、評価軸が曖昧になる |
製品の画面名は変わりやすいので、上表は概念としての分担です。役割はモデルを替えることより、制約の置き場を分けることに近いです。
ポイントは、モデルそのものを替えることではなく、同じモデルでも入力の制約と評価基準を固定することです。役割は「誰に頼むか」のラベルであると同時に、「何をしないか」のガードレールでもあります。万能な一人に全部任せるより、得意領域がはっきりした複数の役に分けたほうが、出力の判断基準は安定しやすいです。
なぜ役割を分けると品質が上がるか
品質が上がる理由は、天才的なプロンプト魔法というより、評価軸の衝突を減らすことにあります。
たとえば「見た目を良くして」「型安全にして」「すぐマージできるように小さく直して」を一度に頼むと、エージェントはどれを優先すべきか迷いやすいです。結果として、
- スコープ外のリファクタが混ざる
- UI の文言と実装の詳細が同時に変わり、差分が読みにくくなる
- 「動いた」ことと「レビュー可能な差分」が混同される
といったことが起きます。
役割を分けると、各チャット（または各エージェント）に単一の成功条件を渡せます。フロント担当ならアクセシビリティと見た目の一貫性、バックエンド担当ならドメイン境界とテスト、レビュアーなら受け入れ条件との照合——評価軸が一つだと、出力のブレが減ります。
これは人間のチームでも近いです。設計・実装・レビューを同時に一人へ積むより、いま何を優先するかを分けたほうが、その場の判断は安定しやすい。AI でも同じで、役割分割の第一の効果は「速さ」より、一度の依頼のなかで評価軸が喧嘩しないことです。やり直しの話は、次の「資産化」の節に譲ります。
コンテキスト混線を防ぐ効果
長いチャットの最大の敵は、情報不足よりも情報の混線です。
同じスレッドで「API 設計の議論」→「CSS の微調整」→「利用規約の文言」→「CI の失敗調査」と進めると、途中の前提が後続の判断を汚染します。エージェントは会話履歴を材料にするため、古い方針や別ドメインの用語が、関係ない回答に混ざりやすいのです。
役割分割は、この混線を構造的に減らします。
- 実装チャットではコードとテストだけを扱う
- 執筆チャットでは記事構成と読者体験だけを扱う
- 法務・表現レビューは下書き確定後の別チャットに回す
- インフラ調査はデプロイやネットワークの前提だけを共有する
INTERESTIC の開発でも、Web Tool Lab の実装とブログ原稿を同じスレッドに載せたことがあります。途中から、コード差分の指摘のなかに「読者への着地」の話が混ざり、どちらも中途半端になりました。実装は差分の正しさ、執筆は読者の次アクション——成功条件が違うと、履歴はそのまま汚染源になります。チャットを分けるだけで、互いのノイズはかなり減ります。
「同じモデルなのに、なぜ分けるのか」と疑問に思うかもしれません。答えは単純で、モデル能力の上限より先に、文脈の純度がボトルネックになることが多いからです。新しいチャットに切り替える行為自体が、すでに役割分割の第一歩です。
専門プロンプトを資産として再利用できる
役割を一度きちんと書くと、それは個人の暗黙知から再利用可能な資産になります。
毎回「このリポジトリは Laravel と React で…」「ブランド名は INTERESTIC…」「コミットは頼まれるまでしない…」と書き直すのは、時間も精度も安定しません。役割（や Rules / Skills）に落としておけば、
- 新規メンバーや未来の自分が同じ品質で始められる
- 失敗パターン（やりすぎリファクタ、秘密情報の扱いなど）を禁止事項として固定できる
- 「良いレビュー」の観点をチェックリスト化できる
といった効果が続きます。
特に効くのは、否定形の指示です。「丁寧に書いて」より、「未検証の効果を断定しない」「宣伝過多にしない」「スコープ外のファイルを触らない」のほうが、出力のばらつきを抑えやすいことがあります。役割プロンプトは、理想の人格だけでなく、現場で踏んだ地雷の記録でもあります。うまくいった指示だけを残し、効かなかった美辞麗句は削る——その反復が、役割を本当の資産にします。
実務で使える役割分割の例
最初から大量の役割は不要です。次の5系統から始めると、個人開発でもチームでも使いやすいです。
| 役割 | 主な担当 | 成功条件の核 | 混ぜない相手（例） |
|---|---|---|---|
| frontend | UI / a11y / コンポーネント境界 | 既存パターンに沿い、装飾が増えていない | backend のドメイン変更 |
| backend | ドメイン / API / テスト | 振る舞いがテストで説明できる | 見た目の好みの議論 |
| infra | Docker / CI / デプロイ | 再現手順が残り、危険操作は止まる | 記事トーンの調整 |
| writer | ブログ / ドキュメント | 次に試せることが明確 | 実装差分の細部 |
| reviewer | 照合・リスク・スコープ外 | 指摘が検証可能で優先度が分かる | 「ついでに全部直す」実装 |
frontend
UI・アクセシビリティ・デザイントークン・コンポーネント境界を担当。成功条件は「見た目と操作性が既存パターンに沿い、不要な装飾が増えていないこと」。実装範囲をフロントのディレクトリに限定すると、バックエンドへの越境が減ります。見た目の好みを抽象的に頼むより、「既存コンポーネントを優先する」など、プロジェクト固有の禁止事項を書くと再現性が上がります。
backend
ドメイン層・API・バリデーション・テストを担当。Controller にビジネスロジックを抱え込まない、といったアーキテクチャ上の制約を役割に書くと強いです。成功条件は「振る舞いがテストで説明でき、差分がレビュー可能であること」。認証やデータ変更に触るときは、影響範囲を先に確認させると安全です。
infra
Docker / CI / デプロイ / ネットワークを担当。ローカル環境の破壊（開発用設定の不用意な上書きなど）を禁止事項に入れる価値が高い領域です。成功条件は「再現手順が残り、本番操作は明示指示があるまで行わないこと」。便利さより、取り返しのつかない操作を止める役として設計すると機能します。
writer
ブログやドキュメントの執筆担当。読者・文字数・見出し数・煽りの禁止を先に固定します。成功条件は「読者が次に何を試せるかが明確で、未確認事実を断定していないこと」。実装チャットと混ぜないのが鉄則です——混ぜると、途中から「コンポーネントの話」が地の文に混ざり、読者向けの着地が消えることがあります。SEO を意識するとしても、キーワードの詰め込みより、見出しの意図と導入の明確さを優先したほうが読み手に届きます。
reviewer
実装や文章のレビュー担当。自分で大きく直すより、受け入れ条件との差分・リスク・スコープ外変更を指摘する役にすると機能します。成功条件は「指摘が検証可能で、優先度が分かること」。修正役とレビュー役を分けるだけでも、「作った本人が自分を正当化する」バイアスを減らせます。
必要に応じて seo-expert や legal-reviewer のような専門役を足すと、「全部を一人のエージェントに背負わせない」運用がさらに安定します。まずは常用の少数役を磨き、専門役は必要なときだけ呼び出す温度感で十分です。
役割設計のコツ（プロンプトに書くこと）
良い役割プロンプトは長い必要はありません。次の項目が入っているかが重要です。
- 目的: 何の仕事をする役か（1文）
- 成功条件: 完了と判断する基準
- 禁止事項: やってはいけないこと
- 入力の前提: どの情報があれば着手できるか
- 出力形式: PR 本文、チェックリスト、Markdown など
- エスカレーション: 迷ったら親役や人間に戻す条件
骨格だけ抜き出すと、次の形で足りることが多いです。
# 役割: reviewer（概念例）
## 目的
受け入れ条件と差分を照合し、検証可能な指摘を返す。
## 成功条件
- 指摘ごとに「何を見たか」「なぜ問題か」「優先度」が分かる
- 大きな実装修正はしない（指摘に留める）
## 禁止事項
- 未確認の効果・速度を断定しない
- スコープ外ファイルへの「ついで修正」を提案しない
- 秘密情報・本番操作を自己判断で進めない
## 入力の前提
PR 差分、受け入れ条件、変更意図（あれば）
## 出力形式
優先度付きチェックリスト（Critical / Nice-to-have）
## エスカレーション
仕様が曖昧、または本番影響が不明なときは親チャット／人間に戻す
よくある失敗は、「優秀であれ」とだけ書いて、評価軸を曖昧にすることです。役割名が fancy でも、成功条件がなければ通常の汎用チャットと大差ありません。
また、Rules（リポジトリ共通）と Role（仕事単位）を混ぜすぎないことも大切です。ブランド表記や言語方針は共通 Rules に、フロント特有の UI 原則は frontend 役割に、という分担にするとメンテしやすくなります。プロンプトは一度書いて終わりではなく、失敗を見るたびに1行ずつ更新する運用が現実的です。
個人開発からチーム運用への拡張
個人で効いた役割設計は、チームでも同じ構造で拡張できます。
- リポジトリの Rules を「チームの最低ライン」にする
- レビュー役のチェック観点を PR テンプレートと揃える
- 執筆役のトーンをブランドガイドと接続する
- インフラ役に「明示指示がないデプロイ禁止」を入れる
こうすると、AI 利用が属人的なテクニックではなく、チームの作業プロトコルになります。新しく Cursor を使い始めたメンバーでも、「まずは reviewer で差分を見てもらい、その後 frontend で直す」のように手順を共有できます。
ただし、役割を増やしすぎると発見コストが上がります。チームでは「常用3〜5役 + 稀に使う専門役」くらいに抑えると、形骸化しにくいです。カタログの充実より、毎週使う役を磨くほうが効果が出ます。誰がどの役を更新するかを決めておくと、ルールの陳腐化も防ぎやすいです。
やりすぎないための境界線
役割分割は万能ではありません。次の点には注意が必要です。
- 小さな修正まで役割を切り替えると遅い: タイポ修正や1ファイルの明確なバグは、汎用チャットで十分なことが多い
- 役割名が品質を保証するわけではない: 成功条件と禁止事項が本体
- バージョン依存の機能名に縛りすぎない: UI は変わり得るので、「仕事単位の制約」として設計する
- 人間の判断を省略しない: セキュリティ、法務、本番操作は最終確認を残す
要するに、役割は加速装置であって、責任の委譲先ではありません。品質の最終責任は、まだ人間側にあります。危険な操作ほど役割で止め、安全な反復作業ほど役割で速くする——その使い分けが大切です。
今日から試せる最小ステップ
大掛かりな再設計は不要です。次の順で十分です。
- よくやる仕事を3つ書く（例: 実装 / レビュー / 文章）
- それぞれに成功条件と禁止事項を5行以内で書く
- Cursor の Mode / Subagent / Rules のいずれかで保存する
- 1週間、仕事の種類が変わったらチャット（役割）も変える
- うまくいった禁止事項だけ共通 Rules に昇格する
最初の成果は劇的な速度向上より、「変な方向に進む回数が減った」という感覚であることが多いです。それで十分です。品質は、派手な一発より、失敗の再現率を下げることで積み上がります。うまくいった週の終わりに、役割プロンプトへ1行だけ追記する習慣があると、資産化が進みます。
まとめ
まずは frontend / backend / reviewer の3役で足りることが多いです。それぞれに成功条件と禁止事項を短く書き、実装と執筆はチャットを分けてみてください。
役割分割の効き方は派手さより地味です。評価軸が喧嘩しなくなり、古い前提が次の判断へ持ち越されにくくなり、うまくいった禁止事項だけが翌週に残る。その積み重ねが、日々の AI コーディングを安定させます。
正本・関連
この記事の正本（INTERESTIC ブログ）: