ある夜、ひとつのチャットに「この 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 ブログ）: