AIチームの作り方｜Claude Code・CodexでWebアプリ開発を分業・自動化する実践ガイド

8月 20, 2026

Claude CodeやCodexのようなコーディングエージェントは、コード生成だけでなく、要件整理、設計、実装、レビュー、テストといった開発工程にも利用できます。

さらに、工程ごとに役割を分け、前工程の成果物を次の担当へ渡すことで、複数のAIを1つの開発チームとして動かすこともできます。この記事では、この仕組みを「AIチーム」と呼びます。

今回は、ログイン機能や生成AIによる回答機能を持たないシンプルな「社内FAQ Webアプリ」を題材にします。HTML、CSS、JavaScript、JSONを中心とした小規模なPoCとして、Web開発側では追加費用をできるだけかけずに試せる構成です。

開発工程を要件整理 → 設計 → 実装 → レビュー → 修正 → テスト → 統合に分解し、AIに開発工程そのものを分業させる方法を見ていきます。

1. AIチームの基本構造

今回の開発では、統括、要件整理、設計、実装、レビュー、テストという役割に分けます。分離するのはAIの人数そのものではなく、責任とコンテキストです。

役割	主な仕事	成果物
統括	タスク分解、進捗管理、工程間の調整	タスク、最終成果物
要件整理	必要な機能と制約を整理	`requirements.md`
設計	画面、データ、処理を設計	`design.md`
実装	設計をコードへ変換	ソースコード
レビュー	要件・設計と実装を照合	レビュー結果
テスト	動作と要件充足を確認	テスト結果

小規模なPoCなら、すべてを別エージェントとして常時起動する必要はありません。同じエージェントでも役割を切り替えられます。一方、複数エージェントを利用できる環境では、依存関係の少ないタスクを分離して進めることもできます。

2. 今回作る社内FAQアプリ

PoCでは、FAQ一覧、キーワード検索、カテゴリ絞り込み、FAQ登録・編集・削除を実装します。ログイン、本格的なデータベース、生成AIによる回答機能は対象外です。

技術構成はHTML、CSS、JavaScript、JSONとし、AIチームの開発ワークフローを確認することに集中します。

3. 成果物を受け渡すフォルダを作る

faq-poc/
├── data/
│   └── faq.json
├── docs/
│   ├── requirements.md
│   └── design.md
├── src/
│   ├── index.html
│   ├── style.css
│   └── app.js
├── tests/
└── README.md

この構成では、要件担当がrequirements.mdを作成し、設計担当がそれを読みます。設計担当はdesign.mdを作成し、実装担当は要件と設計の両方を読んでコードを書きます。

AI間の連携を会話だけに依存させず、ファイルを工程間のインターフェースとして利用するのがポイントです。

4. 要件整理を担当させる

社内FAQ WebアプリのPoCを作成します。

対象は一般社員です。
ログイン機能と生成AI機能は不要です。

必要な機能は以下です。
・FAQ一覧
・キーワード検索
・カテゴリ絞り込み
・FAQ登録
・FAQ編集
・FAQ削除

この段階では実装しないでください。
必要な要件と制約を整理し、docs/requirements.md にまとめてください。
判断に必要な情報が不足している場合は、独自に仕様を追加せず質問してください。

成果物となるrequirements.mdを、以降の設計・レビュー・テストの基準として利用します。

5. 既存Skillを要件整理に使う

すべての役割や作業手順をゼロから作る必要はありません。公開されているSkillsやプラグインを組み合わせる方法もあります。

たとえばコミュニティ製のGrillMeは、曖昧な要求に対して質問を重ね、要件や設計を具体化する用途のSkillです。「社内FAQを作りたい」という要求から、利用者、PoCの範囲、検索方法、カテゴリ、データ保存方法などを実装前に整理する用途が考えられます。

GrillMeはClaude Codeの標準機能ではないため、導入時には配布元、内容、権限、更新状況を確認します。

6. 要件から設計を作る

docs/requirements.md を確認してください。

記載された要件を変更せず、FAQアプリを小規模なPoCとして実装するための設計を作成してください。

以下を整理してください。
・画面構成
・FAQのデータ構造
・ファイル構成
・JavaScriptの責務
・検索処理
・カテゴリ絞り込み処理
・登録、編集、削除処理

結果を docs/design.md に保存してください。
この段階では実装しないでください。

設計段階で仕様変更が必要になった場合は、設計担当が独自に変更せず、変更理由を要件側へ戻す運用にします。

7. 設計を実装担当へ渡す

以下を確認してください。

docs/requirements.md
docs/design.md

内容に従ってFAQアプリを実装してください。
実装対象は src/ 配下です。
要件に存在しない機能は追加しないでください。

完了後に、
・変更したファイル
・実装した機能
・未実装事項
・判断が必要な事項
を報告してください。

実装担当の責任は、確定した要件と設計をコードへ変換することです。仕様上の問題を発見した場合も、独自判断で変更せず報告させます。

8. 実装担当とレビュー担当を分ける

あなたはコードレビュー担当です。

以下を確認してください。
docs/requirements.md
docs/design.md
src/ 配下の実装

次の観点からレビューしてください。
1. 要件を満たしているか
2. 設計との食い違いがないか
3. 不具合につながる処理がないか
4. 不要な機能が追加されていないか
5. 不必要に複雑になっていないか
6. 保守しやすい構造か

この段階ではコードを変更しないでください。
問題を重要度別に整理し、対象箇所と理由を報告してください。

レビューと修正を別工程にしておくと、何が問題で、なぜ変更されたのかを追跡できます。

9. テスト担当も要件から確認する

あなたはテスト担当です。

docs/requirements.md を基準として、現在の実装に必要なテスト項目を作成してください。

FAQ一覧、キーワード検索、カテゴリ絞り込み、FAQ登録・編集・削除、FAQが0件の場合、検索結果が0件の場合、空または不正な入力を確認してください。

正常系だけでなく想定外の操作についても確認し、テスト内容と結果を tests/ に記録してください。

これで、要件 → 設計 → 実装 → レビュー → 修正 → テストという小さなAI開発チームが成立します。

10. 統括エージェントを置く

工程が増えたら、全体を管理する統括エージェントを置きます。ゴール確認、タスク分解、担当への割り当て、成果物確認、依存関係の管理、未解決事項の把握、最終的な整合性確認を担当します。

このプロジェクトの統括担当として作業してください。

ゴールは社内FAQ WebアプリのPoC完成です。

作業を、要件整理、設計、実装、コードレビュー、修正、テスト、最終確認に分解してください。

各工程では前工程の成果物を確認し、完了条件を満たしてから次へ進んでください。
仕様変更や重要な判断が必要な場合は、独自に決定せず報告してください。

11. Skillsは「仕事のやり方」を再利用する

AIチームでは、エージェント＝誰が担当するか、Skill＝その仕事をどう進めるかと整理すると分かりやすくなります。

要件整理、コードレビュー、テスト、デバッグ、ドキュメント作成、リリース前チェックなど、繰り返す仕事をSkillとして再利用できます。会社独自のコーディング規約やレビュー基準も候補になります。

12. 既存Skills・プラグインを利用する

汎用的な開発工程は、既存のSkillsやプラグインを利用できます。

Superpowers

Superpowersは、ソフトウェア開発の方法論を複数のSkillsとしてまとめた開発ワークフローです。ブレインストーミング、実装計画、テスト駆動開発、体系的なデバッグ、サブエージェントを使った開発、コードレビュー、Skill作成などを含みます。

Feature Dev

Claudeのプラグインディレクトリには、機能開発を段階的に進めるFeature Devもあります。既存コードの理解、要件の明確化、設計、実装、レビューといった工程を一連のワークフローとして扱います。

Code Review

コードレビューに特化したプラグインも利用できます。レビュー担当をゼロから設計する代わりに、既存の仕組みを利用する選択肢です。

Code Simplifier

Code Simplifierは、動作を維持しながらコードを整理し、可読性や保守性を改善する用途に利用できます。レビュー後のリファクタリング工程として組み込めます。

Claude Code Setup

Claude Code Setupはコードベースを分析し、Skills、Hooks、Subagents、MCPサーバーなどの活用候補を提案する用途に利用できます。

汎用的な工程は既存の仕組みを利用し、自社固有のルールや手順だけを自作Skillとして追加すると、初期構築を小さくできます。

13. Claude Codeでは仕組みを役割別に分ける

CLAUDE.md：プロジェクト共通ルール

・実装前に requirements.md を確認する
・要件にない機能を追加しない
・HTML、CSS、JavaScriptを中心に実装する
・外部ライブラリを追加する場合は理由を説明する
・破壊的操作を行う前に確認する

Skills：作業手順

コードレビューやテストなど、複数ステップからなる仕事をSkillsとして定義します。

Subagents：専門担当

設計、実装、レビュー、テストなどの役割を専門担当として分離できます。担当ごとに利用できるツールや権限を調整する設計も可能です。

Hooks：決められたタイミングで処理する

Hooksは特定のイベントに応じて処理を実行する仕組みです。コード変更後のフォーマットやテストなど、決められた工程で確実に走らせたい処理に利用できます。

14. 複数エージェントは依存関係を見て並列化する

要件 → 設計 → 実装には依存関係があるため、基本的には順番に処理します。一方、実装後のUI確認、コードレビュー、テスト項目作成など、同じ成果物を異なる観点から確認する仕事は並列化しやすくなります。

並列化の基準はAIの人数ではなく、タスク間の依存関係です。

15. Codexでも同じ設計思想を使う

会社でCodexを採用している場合も、要件整理 → 設計 → 実装 → レビュー → テスト → 統合という基本構造は共通です。

各工程について、入力、責任範囲、利用できるツール、禁止事項、成果物、完了条件を決め、その後でSkillsや複数エージェントなど利用可能な機能を割り当てます。

16. CodexのRecord & Replay

Codexでは、対象環境でRecord & Replayを利用し、人間が一度実演した操作ワークフローを再利用可能なSkillへ変換できます。

業務システムを開く → 対象画面へ移動 → データを入力 → 内容を確認 → 登録、といった定型業務を言葉だけで定義しにくい場合に利用できます。

提供OS、プラン、地域、Computer Useの利用条件などは変更される可能性があるため、利用時には最新のOpenAI公式情報を確認してください。

17. Computer Useをテスト工程に使う

Computer Useを利用できる環境では、コードを読むだけではなく、実際のアプリを操作するQAも考えられます。

今回なら、FAQアプリを開く → キーワード検索 → カテゴリ変更 → FAQ登録 → 編集 → 削除 → 問題を記録、という流れです。

コードレビュー担当と、実際にアプリを操作するQA担当を分けることで、異なる観点から確認できます。

18. 定期実行できる仕事を自動化する

AIチームが安定してきたら、変更内容の確認、テスト結果の整理、週次レポート、issueのトリアージなど、繰り返し発生する仕事の自動実行を検討できます。

CodexではAutomationsなどの仕組みを利用し、指示やSkillsをスケジュールに沿って実行する方法があります。

まず手動で安定して実行できるワークフローを作り、その後に自動実行へ移すと管理しやすくなります。

19. 外部サービスとつなぐ

MCPやプラグインなどを利用できる環境では、GitHub、Slack、Google Drive、カレンダーなどの外部サービスをワークフローへ組み込めます。

外部への書き込みや送信まで自動化する場合は、読み取り、編集、削除、外部送信を同じ権限として扱わず、必要な範囲だけ権限を与えます。

20. AI間の受け渡しは成果物として残す

requirements.md、design.md、ソースコード、レビュー結果、テスト結果などを残しておけば、別のエージェントが途中から担当しても前工程を確認できます。

人間も、なぜこの仕様になったのか、何を基準に実装したのか、どこで問題が見つかったのかを追跡できます。

21. 自動化は段階的に広げる

最初のPoCでは、要件整理後、設計後、最終テスト後などに人間の確認ポイントを残します。

何度か繰り返して安定した工程が分かったら、Skills、Hooks、Automationsなどを使って自動化範囲を広げます。

本番環境への反映、ファイルの大量削除、外部送信、機密情報へのアクセス、大きな仕様変更などは、人間による承認を残す設計が適しています。

22. 最初は小さなチームから始める

最初からすべての役割を個別エージェントとして構築する必要はありません。

実装 → レビューから始め、次にテストを追加するだけでも構いません。

繰り返す作業が見つかったらSkill化し、必ず実行したい処理はHooksなどへ移し、独立した仕事が見つかったら並列化します。

23. AIチームを構成する要素

AIチームは、ルール、Skills、専門担当、自動チェック、成果物、外部連携、自動実行といった複数のレイヤーで構成できます。

中心になるのはフォルダそのものではありません。

誰が、何を読み、どのルールで仕事をし、何を成果物として残し、どの条件を満たしたら次の担当へ渡すのか。

このワークフローを設計することが、AIチーム構築の基本です。

24. Claude CodeとCodexのどちらでも基本設計は共通

Claude CodeとCodexでは利用できる機能や実装方法が異なります。会社ですでに利用する生成AI環境が決まっているのであれば、その環境で利用可能な機能を使って同じ設計思想を実装できます。

Claude Codeなら、CLAUDE.md、Skills、Subagents、Hooks、Pluginsなどを組み合わせます。Codexなら、Skills、複数エージェント、Computer Use、Record & Replay、Automationsなどを目的に応じて組み合わせます。

既存Skillsやプラグインも利用し、足りない部分だけ自社向けに作ります。

AIチーム構築の中心は製品名ではなく、仕事を分解し、役割・ルール・手順・成果物・完了条件・受け渡し方法を設計することです。

今回のような小さなPoCから、実装とレビューを分け、テスト担当を追加し、繰り返す仕事をSkill化するところまで試すと、AIに単発の仕事を依頼する使い方から、AIが一定の開発プロセスに沿って仕事を進める仕組みへ発展させられます。

参考資料

機能名、提供条件、対応OS、利用可能なプランなどは変更される可能性があります。実際に導入する際は、各サービスの最新の公式ドキュメントを確認してください。コミュニティ製Skillについては、導入前に配布元、コード、要求権限、更新状況を確認してください。