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エージェントを実務へ持ち込むうえで重要なテーマになりそうです。