はじめに
AIにコードを書かせること自体は、もう珍しくありません。
しかし 「AI同士を役割分担させて開発する」 という話は、まだ多くありません。
私は SE / PM としての経験は長い一方で、プログラミングを主戦場としてきたわけではありません。
その立場から、AIを「ツール」ではなく 「役割を持つチームメンバー」 として設計・運用する試行錯誤を続けてきました。
本記事では、Kiro × Claude Code × Codex という構成に辿り着くまでの
失敗と学びを共有します。
GitHub Copilot：実装補助としての有用性と限界
最初に使い始めたのは VS Code の GitHub Copilot でした。
- コード補完は速い
- しかし設計・判断は完全に人間側の責務
SE / PM 視点では、Copilot は 「実装効率を上げる優秀な補助ツール」 であり、
開発プロセス自体を変える存在ではありませんでした。
Claude Code：実装力は高いが、全体最適は苦手
Claude Code が登場したとき、私はこう考えました。
「設計をしっかり作れば、実装は Claude Code に任せられるのでは？」
これは 部分的には正解 でした。
Claude Code は、
- 新規実装が速い
- 指示に忠実
- リファクタリングもこなせる
一方で、プロジェクト規模が大きくなると、
- 目先のタスクに集中しすぎる
- 全体構造や前提条件の保持が弱くなる
- 局所最適な修正を繰り返す
という問題が顕在化しました。
失敗事例①：仕様はあるのに、なぜか壊れていく
何が起きていたか
- 仕様書は存在していた
- Claude Code にも仕様を渡していた
- 実装も一見、仕様通りに進んでいた
それにもかかわらず、
- リファクタリングのたびに挙動がズレる
- テストは通るが意図と違う
- なぜそうなったのか説明できない
という状態に陥りました。
技術的に起きていた問題
仕様が「参照される前提」になっていなかった のです。
Claude Code は、
- 直前の文脈
- 直近のコード
- 今与えられているタスク
を強く優先します。
結果として、
仕様は存在するが、実装を拘束していない
状態になっていました。
回避策：Kiro の役割
- 仕様を「ドキュメント」ではなく 判断基準 に昇格
- 実装前後で必ず仕様に立ち戻る
- 仕様とコードのズレを言語化する
これを Kiro の専任役割 としました。
失敗事例②：デバッグがループして抜けられなくなった
何が起きていたか
- テストが落ちる
- Claude Code に修正させる
- 別のテストが落ちる
- 修正が別の修正と衝突する
前に進んでいるようで、同じ場所を回っている 状態でした。
なぜ抜けられなかったのか
- Claude Code は仮説駆動で進む
- 人間（私）も局所に引きずられる
- 「今何が起きているか」を整理できていなかった
回避策：Codex の役割
- 実装を止める
- 修正案を出させない
- 事実（ログ・状態・差分）を整理する
Codex に 「整理専門」 を任せたことで、
- どこまでが事実か
- 何が推測か
- 何を変えると影響が出るか
が可視化され、ループを抜けられました。
AI切り替えトリガー（実運用ルール）
Claude Code に任せる
- 新規機能の実装
- 明確な仕様に基づく修正
- 方針が固まっているリファクタリング
Kiro に切り替える
- 仕様の解釈に迷ったとき
- 実装結果に違和感を覚えたとき
- 「そもそも正しいのか？」と感じたとき
Codex に切り替える
- テストが 2回以上連続で失敗
- 修正しても別のテストが落ち始めた
- 削除・影響範囲の判断に迷った
- なぜ失敗しているか説明できないとき
現在のAIチーム構成（Mermaid）
あえてやらないこと（重要）
AI をチームとして運用する上で、「やること」以上に重要だったのが やらないことを決める ことでした。
やらないこと
- Claude Code に 仕様の最終判断 をさせない
- Codex に 新規実装 を任せない
- Kiro に コードを書かせない
- 1つのAIに 設計・実装・検証をすべて任せない
- 人間が すべてをレビューしようとしない
これらを明確に分けることで、
- AIの暴走を防げる
- 判断の責任範囲が明確になる
- 開発の安定性が上がる
という効果がありました。
役割を越えた判断が必要な場合は、必ず人が判断する という原則は、常に守るようにしています。
ai-roles.md（実際に使っているファイル）
# AI Roles and Responsibilities
## Claude Code
- 実装担当
- 新規機能・リファクタリング
## Kiro
- 仕様管理
- 設計レビュー・受け入れ判断
## Codex
- デバッグ
- テスト失敗時の原因切り分け
- 安全な削除・変更判断
- 検証ログ・再現手順の文書化
※ AI は自分の役割を越えた判断が必要な場合、必ず人に確認する。
学び
- 仕様は「ある」だけでは足りない
- テストは「通る」だけでは足りない
- 人もAIも不完全である
だからこそ、
役割分担されたチーム設計が必要でした。
サンプルプロジェクトについて
本記事で紹介した AIチーム開発のスタイル を、
そのまま試せる サンプルプロジェクト を GitHub で公開しています。
👉
ai-team-dev-sample
https://github.com/miyakawa2449/ai-team-dev-sample
このリポジトリには、
-
ai-roles.mdによる役割定義 -
CLAUDE.md/CODEX.mdによる実装・デバッグの責務分離 -
docs/による仕様管理 -
reports/による判断・検証ログの記録
といった、記事内で触れた運用をそのまま再現できる構成を含めています。
完成したアプリケーションではなく、「AIをチームとして運用するための雛形」として用意していますので、必要な部分だけを取り入れてもらえれば幸いです。
ディレクトリ構成
.
├── README.md
├── .kiro/
│ ├── specs/
│ │ └── example-calculator/
│ │ ├── requirements.md
│ │ ├── design.md
│ │ └── tasks.md
│ └── steering/
│ └── ai-team-roles.md
├── src/
│ └── example_app.py
├── tests/
│ └── test_example.py
├── reports/
│ └── (検証ログ・判断記録)
├── CLAUDE.md
└── CODEX.md
おわりに
AIは魔法ではありません。
しかし、役割を与え、チームとして扱えば強力なパートナーになります。
同じ立場の方の参考になれば幸いです。
個人ブログについて
この記事では、AIチーム開発の 構成・役割分担・設定ファイル といった
技術的な内容を中心にまとめました。
一方で、
- なぜこの考え方に辿り着いたのか
- どんな迷いや失敗があったのか
- 「判断を人が持つ」ことをどう捉えているか
といった 背景や思考の部分 については、
個人ブログの方で詳しく書いています。
👉 AIを「ツール」ではなく「チーム」として扱うようになった理由
https://miyakawa.codes/blog/why-we-treat-ai-as-a-team-not-a-tool
技術的な構成を読んだ上で、「なぜそうしているのか」に興味を持っていただけた方は、
あわせて読んでいただければ幸いです。