AIチームを運営する技術｜GPT・Claude Code・Codexを分業させる実践フロー

AI開発で失敗する人は、AIに「全部やって」と頼みます。

でも、実際にAIを仕事や開発に入れていくと、すぐに分かります。

AIは万能の作業者ではありません。人間が設計せずに丸投げすると、ものすごい速度で間違った方向へ進みます。

要件が曖昧なら、曖昧なまま実装します。
レビュー基準がなければ、動いているように見えるだけのコードを出します。
記憶の置き場がなければ、前回決めたことを忘れます。
外部ツールの使い方が曖昧なら、調べたふり、読んだふり、確認したふりをします。

ここで必要になるのは、「AIを使う技術」ではありません。

AIチームを運営する技術です。

この記事では、私が実務で組み立てているAIチームの設計を、かなり具体的に書きます。

主役は、次の6つです。

ただし、この記事は「どのAIが一番すごいか」を比べる記事ではありません。

この記事のゴールは、読者が自分のAI開発環境へ次の3つを持ち帰れることです。

この記事では、単なるノウハウ紹介ではなく、実例、プロンプト、チェックリスト、レビューゲート、記憶装置、ガバナンス設計まで入れます。

第1章：なぜAIを3人に分けるのか

まず、AIを1人の天才として扱うのをやめます。

私が今いちばんしっくり来ている分け方は、次の3人です。

この分け方のポイントは、能力差ではありません。

同じAIに、PM、実装者、レビュアーを全部やらせないことです。AIは自分が書いたものを甘く見やすいからです。人間でも同じです。

だから、役割を分けます。

特に非エンジニアがAI開発をする場合、危ないのは「いきなり実装」です。

「こういうアプリ作って」

と頼むと、AIは親切に作り始めます。

でも、そこで抜けやすいものがあります。

これを決めないまま実装すると、あとで詰まります。AIを3人に分ける目的は、速く作ることではありません。

止まるべき場所で止まれるようにすることです。

実践ワーク：AIチームの役割表を作る

まず、自分の環境で次の表を埋めてください。

プロジェクト名:

PM役:
担当AI:
任せること:
任せないこと:

実装者役:
担当AI:
任せること:
任せないこと:

レビュアー役:
担当AI:
任せること:
任せないこと:

人間が必ず判断すること:
1.
2.
3.

この表がないままAIに実装させるのは、責任者もレビュー担当も置かずに開発を始めるようなものです。

実例：note記事制作をAIチームで回す場合

ここからは、実際の運用例として、チョコレートノートの記事制作をAIチームで回すケースを置きます。

テーマは、たとえば次のようなものです。

AIチームを運営する技術について、チョコレートノート用の記事を書く。
読者は、AIを使って開発や業務改善をしたい人。
無料記事ではなく、有料サブスク技術記事として、実践テンプレートまで持ち帰れる内容にする。

この時、いきなりClaude Codeに「記事を書いて」と頼みません。

まず、AIチーム全体の流れをこう分けます。

GPT
  → PMメモを作る
  → 読者、成功条件、章構成、足りない論点を整理する

Claude Code
  → リポジトリ内の articles_type、flow、既存記事を読む
  → チョコレートノートの型に合わせて下書きを作る

Codex
  → 文字数、構成、具体性、テンプレート量をレビューする
  → 「有料記事として弱い点」を指摘する

Obsidian
  → 過去の失敗、投稿ルール、画像生成の注意、記事方針を参照する
  → 今回の学びを作業ログへ残す

Fairy Tale
  → 目的、成功条件、根拠、検証、フィードバック候補を管理する

MCP
  → 必要に応じてファイル、Git、ブラウザ、記憶、画像生成などの外部ツールを接続する

図解にすると、こうです。

人間
 ↓ 目的と違和感を渡す
GPT PM
 ↓ PMメモ
Claude Code 実装者
 ↓ 下書き・ファイル編集
Codex レビュアー
 ↓ 品質指摘・差分確認
Claude Code 修正
 ↓
人間チェック
 ↓
Obsidian / Fairy Tale に学びを保存

この流れの良いところは、「記事を書くAI」と「記事を見るAI」を分けられることです。

書いた本人にレビューまで任せると、文章はきれいでも、弱いところを見逃しやすくなります。