AIコーディング支援を使っていると、次の段階でよく出てくるのが、
「役割ごとのAIエージェントを作って、開発チームのように動かせないか？」
という発想です。
たとえば、
- PM役が要求を整理する
- Tech Lead役が設計する
- PG役が実装する
- QA役がテスト・レビューする
といった形です。
Claude Code向けには、こうした「AI Agent Team」を扱う仕組みとして ccteams のようなアプローチがあります。
ただ、実務で考えると本当に欲しいのは「Claude Code専用の役職プロンプト集」ではありません。
今回整理したかったのは、**Claude CodeでもCursorでも再利用できる“AI開発工程そのもの”**です。
結論：Teamだけでは足りない
ポイントは、次の3つを分離して考えることです。
Team
誰が担当するか
Graph
どの順序・条件で仕事を渡すか
Harness
何を許可し、どう検証するか
これをまとめて、
Team × Graph × Harness
として扱います。
Team
AIエージェントの役割です。
たとえば、
PM
↓
Tech Lead
↓
Developer
↓
QA
のように、工程ごとの担当を定義します。
しかし、役割を作っただけでは「複数のAIがいる」だけです。
Graph：AI同士の仕事の流れを決める
重要なのがGraphです。
たとえば、
このように、
- 誰から誰へ渡すか
- どの条件で戻すか
- どこまで自動化するか
を定義します。
人間の開発プロセスでいう、ワークフローや工程管理に近い考え方です。
Harness：AIを自由に動かしすぎない
もう1つ重要なのがHarnessです。
AIエージェントに、
- ターミナル実行
- ファイル変更
- Git操作
- 外部アクセス
などを許可すると、便利になる一方でリスクも増えます。
そこで、
AI Agent
↓
Permission / Rule
↓
Tool execution
↓
Test / Lint / Review
↓
Accept or Reject
のように、AIの行動を「囲う」仕組みが必要になります。
これがHarness Engineeringの考え方です。
Claude CodeとCursorで共通化できる
面白いのは、この設計思想自体は特定のAI開発ツールに依存しないことです。
Claude Code側では、
- Agent Teams
- Hooks
- Permissions
- Plugins
などを使えます。
Cursor側でも、
- Subagents
- Skills
- Rules
- Hooks
- Sandbox
- Worktrees
といった仕組みに展開できます。
つまり、
Common Contract
Team / Graph / Harness
│
┌──────┴──────┐
↓ ↓
Claude Code Cursor
adapter adapter
という形にできます。
重要なのは、Claude Code版とCursor版を別々に設計しないことです。
共通のContractを作り、それぞれの実行環境へadapterで変換する。
この構成にすると、AI開発工程そのものを持ち運べます。
「プロンプト集」から「AI開発基盤」へ
これまでAIエージェントというと、
あなたはPMです
あなたはシニアエンジニアです
あなたはQA担当です
のような「役職プロンプト」を作るところで終わりがちでした。
しかし実務では、必要なのは役職ではなく、
役割
＋
工程
＋
権限
＋
検証
＋
成果物
です。
ここまで定義して初めて、AIを「開発チーム」として扱いやすくなります。
そして、この構造を共通化しておけば、Claude CodeからCursorへ移ったとしても、開発プロセスをゼロから作り直す必要がありません。
次回
元資料では、この考え方をさらに具体化し、
- ccteamsをどう活かすか
- Cursorへどう移植するか
- Team / Graph / Harnessの共通Contract
- runtimeごとのadapter設計
- 安全設計
- Starter Kit構成
まで整理しています。
AIコーディングツールを単なる「コード生成AI」ではなく、ソフトウェア開発工程を実行するランタイムとして見ると、かなり設計の見え方が変わります。
このあたりは、今後AIエージェントを実務へ持ち込むうえで重要なテーマになりそうです。