企画からテスト・クラウド構築まで、4つのAIエージェントを使い分ける開発フロー

Posted at 2026-11-06

はじめに

最近は、開発業務のかなりの部分でAIエージェントを使うようになりました。

企画書を書く。
要件を整理する。
画面を設計する。
コードを書く。
テストを書く。
コードレビューをする。
クラウド環境を構築する。
操作説明の資料や動画を作る。

こうして並べてみると、開発に関わるほとんどの工程でAIを使っています。

ただ、実際に使い続ける中で感じたことがあります。

全部を1つのAIに任せる必要はない。

AIエージェントごとに、得意な領域や連携できるサービスが異なります。

そのため、現在は次の4つを開発工程に応じて使い分けています。

Microsoft Copilot
ChatGPT / Codex
Claude
Gemini

この記事では、実際の開発業務の中で、それぞれのAIエージェントをどのように使い分けているのかを紹介します。

なお、この記事は各製品の性能を比較して順位をつけるものではありません。

自分の開発フローにおける、現時点での役割分担をまとめたものです。

最初に結論

現在は、大まかに次のように使い分けています。

AIエージェント	主な役割	主な成果物
Microsoft Copilot	社内情報の検索・整理、企画、提案	企画書、提案書、社内向け資料
ChatGPT / Codex	要件整理、設計、コードレビュー	RFP、要件定義書、ワイヤーフレーム、レビュー結果
Claude	コーディング、テスト実装	アプリケーションコード、テストコード
Gemini	クラウド構築、Web調査、説明コンテンツ作成	構築手順、設定内容、マニュアル、説明動画

開発工程に当てはめると、次のようなイメージです。

社内情報の整理・企画・提案
        ↓
Microsoft Copilot
        ↓
RFP・要件定義・設計
        ↓
ChatGPT / Codex
        ↓
コーディング・テスト実装
        ↓
Claude
        ↓
コードレビュー
        ↓
ChatGPT / Codex
        ↓
クラウド環境の構築・最新情報の確認
        ↓
Gemini
        ↓
マニュアル・説明動画の作成
        ↓
Gemini

もちろん、役割を完全に分離しているわけではありません。

Codexでコードを書くこともあれば、Claudeに設計内容を確認してもらうこともあります。

それでも、作業を始めるときに「まず誰に頼むか」は、おおむねこの役割分担で決めています。

Microsoft Copilotは社内情報を使う仕事に向いている

Microsoft Copilotは、主に開発前の企画や提案で使っています。

特に便利なのが、Microsoft 365上にある社内情報を参照しながら作業してもらいたい場合です。

たとえば、次のような情報です。

SharePointに保存されている社内文書
Teamsで共有された情報
過去に作成した企画書や提案書
プロジェクトに関する資料
社内で蓄積してきた業務情報

実際には、次のような依頼をしています。

過去の提案資料を参考にして、今回の顧客向け提案書のたたき台を作成してください。

SharePointにある関連資料を確認し、企画書に必要な情報を整理してください。

Teamsと社内文書から、このプロジェクトの背景、課題、決定事項を整理してください。

生成AIに文章を書かせること自体は、珍しい使い方ではありません。

しかし、企画書や提案書を作るときに本当に時間がかかるのは、文章を書くことだけではありません。

社内のどこかにある過去の資料を探し、必要な情報を抜き出し、今回の内容に合わせて整理する作業に時間がかかります。

Microsoft 365を業務の中心にしている自分にとって、Microsoft Copilotは単なる文章生成AIではありません。

社内情報を参照しながら仕事を進めるエージェント

という位置付けです。

ChatGPT / Codexは仕様を形にするために使う

企画や提案の方向性が決まったら、次はシステムとして何を作るのかを整理します。

この工程では、ChatGPTやCodexを使っています。

主に作成しているものは次のとおりです。

RFP
要件定義書
業務要件
機能要件
非機能要件
機能一覧
画面一覧
画面遷移
ワイヤーフレーム
API設計
DB設計
テスト方針
実装方針
開発ルール

文書を作るだけではなく、構造化する

ChatGPTやCodexには、単に要件定義書の文章を書かせるだけではなく、開発で継続的に利用できる形に整理してもらいます。

たとえば、設計資料をMarkdownで作成し、次のような構成でリポジトリに保存します。

docs/
├── rfp.md
├── requirements/
│   ├── business-requirements.md
│   ├── functional-requirements.md
│   └── non-functional-requirements.md
├── screens/
│   ├── screen-list.md
│   ├── screen-transition.md
│   └── wireframes/
├── api/
│   └── api-specification.md
├── database/
│   └── database-design.md
└── testing/
    └── test-policy.md

設計資料をリポジトリに置いておけば、実装を担当するAIエージェントも同じ情報を参照できます。

要件、設計、コードの距離を近づけることで、後工程での認識違いを減らしやすくなります。

Astroでブラウザから確認できる設計資料を作る

設計資料によっては、Markdownだけでは完成形をイメージしにくいことがあります。

特に画面設計では、文章だけで画面構成を共有するのは簡単ではありません。

そこで、ChatGPTやCodexを使い、Astro上で確認できるワイヤーフレームや設計資料を作成しています。

画像としてワイヤーフレームを作る方法もありますが、HTMLとして作成しておくと次の利点があります。

ブラウザですぐに確認できる
レスポンシブ表示を確認できる
ボタンや画面遷移を簡易的に試せる
レビュー時の認識を合わせやすい
その後のフロントエンド実装に流用しやすい
変更内容をGitで管理できる

最初から完成したデザインを作るのではなく、要件を確認するための動くワイヤーフレームとして使っています。

Codexは実装前の情報整理にも使える

Codexというと、コードを書くためのエージェントという印象が強いかもしれません。

しかし、自分の場合は、実装前の情報を構造化する用途でもよく使っています。

たとえば、次のような作業です。

ヒアリング内容を要件として整理する
不明点や矛盾点を洗い出す
機能要件と非機能要件を分ける
受け入れ条件を定義する
必要な設計書を作成する
実装タスクに分解する

AIによるコーディングが強力になるほど、実装前の要件整理が重要になります。

何を作れば完成なのかが曖昧なままでは、AIが高速にコードを書いても、求めていたシステムにはなりません。

Claudeはコーディングとテスト実装に使う

実際のコーディングでは、Claudeを使うことが多くなっています。

主に担当させている作業は次のとおりです。

新規機能の実装
既存機能の修正
リファクタリング
不具合修正
単体テストの実装
E2Eテストの実装
結合テストの実装
シナリオテストの実装

自分の開発フローでは、次の流れになることが多いです。

ChatGPT / Codexで要件と設計を整理する
        ↓
設計資料をリポジトリに保存する
        ↓
Claudeが設計資料を確認する
        ↓
Claudeが実装する
        ↓
Claudeがテストを実装する

いきなり「システムを作って」と依頼しない

Claudeに、いきなり次のような依頼をすることは避けています。

顧客管理システムを作ってください。

この依頼だけでは、AIが判断しなければならない範囲が広すぎます。

代わりに、先に次の情報を用意します。

システムの目的
対象ユーザー
業務フロー
機能要件
非機能要件
画面仕様
API仕様
DB設計
コーディング規約
テスト方針
受け入れ条件

そのうえで、実装対象と完了条件を明確にして依頼します。

要件定義書と画面仕様を確認し、顧客登録機能を実装してください。

実装後は、正常系、入力エラー、権限エラーを対象とした単体テストを追加してください。
既存のテストを含め、すべてのテストが成功することを完了条件とします。

AIにコーディングを任せる場合でも、人間による要件と完了条件の定義は必要です。

テストも同じエージェントに実装させる

機能コードだけでなく、テストコードもClaudeに実装させています。

テストは種類ごとに目的が異なります。

テスト	主に確認すること
単体テスト	関数、クラス、コンポーネント単位の動作
結合テスト	API、DB、外部サービスなどの連携
E2Eテスト	ユーザー操作を通したシステム全体の動作
シナリオテスト	実際の業務フローに沿った一連の動作

「テストを書いて」とだけ指示すると、必要な観点が不足することがあります。

そのため、要件や受け入れ条件に基づいて、どのテストで何を確認するのかも指定します。

Claudeが書いたコードをCodexにレビューさせる

自分が特に有効だと感じているのが、Claudeが書いたコードをCodexにレビューさせる方法です。

Claudeが実装する
        ↓
Codexがレビューする
        ↓
指摘内容を確認する
        ↓
ClaudeまたはCodexが修正する
        ↓
テストを再実行する

実装したAI自身にレビューさせることもできます。

しかし、あえて別のAIエージェントに確認させることで、実装時とは異なる視点から指摘が出ることがあります。

Codexには、主に次の観点でレビューを依頼しています。

要件を満たしているか
設計との不整合がないか
バグになりそうな箇所がないか
例外処理が不足していないか
セキュリティ上の問題がないか
認証や認可に漏れがないか
入力値の検証が十分か
テストが不足していないか
既存機能への影響がないか
過剰実装になっていないか
可読性や保守性に問題がないか

レビューを依頼するときは、単に「レビューしてください」と伝えるのではなく、要件定義書や設計資料との差分も確認させます。

このブランチの変更をレビューしてください。

以下の観点を必ず確認してください。

1. 要件定義書と画面仕様を満たしているか
2. 認証・認可の漏れがないか
3. 入力値検証と例外処理が十分か
4. 既存機能への影響がないか
5. 単体テスト、結合テスト、E2Eテストに不足がないか

問題点は重要度を「高・中・低」に分け、対象ファイル、該当箇所、理由、修正案を示してください。

人間の開発チームでも、実装者とレビュアーを分けます。

AIを使う場合も、同じAIにすべてを任せるのではなく、実装とレビューの役割を分けることで品質を確認しやすくなります。

Geminiはクラウド構築とWeb調査に使う

Geminiは、主にクラウド環境を構築するときに使っています。

対象となるのは、次のようなクラウドサービスです。

Google Cloud
AWS
Microsoft Azure

クラウド環境の構築では、現在の公式ドキュメントや管理画面を確認しながら作業する必要があります。

クラウドサービスは変更が多く、以前の手順がそのまま使えるとは限りません。

たとえば、次のような変更があります。

管理画面の構成が変わる
設定項目の名称が変わる
推奨構成が変わる
新しいサービスや機能が追加される
古い機能が非推奨になる
権限設定の方法が変わる

そのため、自分の中では、Web上の最新情報や公式ドキュメントを確認しながら進める必要がある作業をGeminiに任せることが多くなっています。

クラウド構築で依頼する内容

Geminiには、たとえば次のような作業を依頼します。

構成案の作成
利用するサービスの選定
IAMや権限の設定
ネットワークの設計
ログや監視の設定
バックアップ方針の整理
デプロイ手順の作成
公式ドキュメントの確認
エラー発生時の原因調査

ただし、AIが提示したコマンドや設定を、そのまま本番環境に適用することは避けています。

特に次の項目は、人間が確認する必要があります。

対象プロジェクトやアカウントが正しいか
リージョンが正しいか
権限が広すぎないか
外部公開の範囲が適切か
削除や上書きを伴う操作ではないか
継続的な費用が発生しないか
本番環境に影響しないか

クラウド構築では、AIによる効率化と同時に、権限、セキュリティ、コストに対する確認が欠かせません。

Geminiはマニュアルや説明動画の作成にも使う

Geminiは、システム完成後の説明資料や動画の作成にも使っています。

システムを作った後には、利用者に使い方を説明する必要があります。

開発者にとっては実装が完了した時点が一区切りですが、利用者にとっては導入後がスタートです。

そのため、次のようなコンテンツもAIで作成します。

操作マニュアル
システム説明資料
管理者向け手順書
利用者向けFAQ
説明用の台本
操作説明動画

たとえば、画面ごとの操作手順から動画用の台本を作り、利用者向けの説明コンテンツにします。

ログインから顧客登録までの操作手順を、初めて利用する担当者向けの説明動画の台本にしてください。

動画は3分程度とし、次の構成にしてください。

1. この操作でできること
2. ログイン方法
3. 顧客情報の入力方法
4. 入力時の注意点
5. 登録完了の確認方法

開発でAIを使うというと、コーディングに注目が集まりがちです。

しかし、納品、導入、教育、運用まで含めてAIを活用すると、開発以外の負担も減らせます。

1つのAIに統一しない理由

以前は、「結局どのAIが一番優秀なのだろう」と考えることがありました。

しかし、現在はどのAIが一番かよりも、次のように考えています。

この作業は、どのAIエージェントに任せるのが適切か。

人間の開発チームにも、さまざまな役割があります。

営業
プロジェクトマネージャー
要件定義担当
システム設計者
プログラマー
テスト担当
コードレビュアー
インフラエンジニア
マニュアル作成担当

通常、これらすべての役割を1人に任せるとは限りません。

AIエージェントも同じです。

それぞれの強みや接続できる情報を考え、適した仕事を任せるほうが効率的です。

AIをツールではなくチームとして考える

現在の感覚としては、4つのAIツールを個別に使っているというより、AIで開発チームを作っている感覚に近くなっています。

役割に置き換えると、次のようになります。

AIエージェント	チーム内での役割
Microsoft Copilot	社内情報の調査、企画、提案担当
ChatGPT / Codex	要件定義、設計、レビュー担当
Claude	実装、テスト担当
Gemini	クラウド、技術調査、説明コンテンツ担当

Microsoft Copilotが社内情報を整理し、ChatGPTやCodexが要件と設計を作ります。

Claudeが設計に基づいてコードとテストを実装し、Codexが別の視点からレビューします。

Geminiがクラウド環境の構築を支援し、最後にマニュアルや説明動画を作ります。

このように、前工程の成果物を次のAIエージェントに渡していきます。

人間が目的を決める
        ↓
Copilotが社内情報を整理する
        ↓
Codexが要件と設計を作る
        ↓
人間が内容を確認する
        ↓
Claudeが実装とテストを行う
        ↓
Codexがレビューする
        ↓
人間が重要な指摘を判断する
        ↓
Geminiがクラウド構築を支援する
        ↓
Geminiが説明コンテンツを作る
        ↓
人間が最終確認する

AIを導入するというより、AIエージェント同士の役割と成果物の受け渡しを設計している状態です。

AI同士をつなぐときに意識していること

複数のAIエージェントを使う場合、重要になるのが情報の受け渡しです。

同じチャットの中だけで作業を続けるのであれば、前後の文脈をある程度維持できます。

しかし、別のAIエージェントに作業を引き継ぐ場合は、暗黙の前提が伝わりません。

そのため、次の情報を成果物として残すようにしています。

プロジェクトの目的
対象ユーザー
用語の定義
要件
制約条件
採用技術
ディレクトリ構成
コーディング規約
テスト方針
完了条件
既知の課題
未決定事項

特に重要なのは、AIとの会話の中だけで要件を確定させないことです。

決定した内容は、Markdownなどのファイルとしてリポジトリに残します。

AIエージェントが変わっても、同じ設計資料を参照できる状態にしておくことで、引き継ぎ時の情報欠落を減らせます。

すべてをAIに任せているわけではない

ここまで読むと、人間がほとんど作業をしていないように見えるかもしれません。

しかし、実際には人間が判断すべきことが多く残っています。

自分が特に重要だと考えているのは、次の作業です。

何を作るのか決める
なぜ作るのかを明確にする
利用者と業務を理解する
どのAIエージェントに任せるか決める
AIに渡す情報を整える
成果物が目的を満たしているか判断する
セキュリティやコストのリスクを確認する
次のAIエージェントに成果物を引き継ぐ
最終的な責任を持つ

AIは、要件が曖昧でも何らかの成果物を作ってくれます。

そのため、出力されたという事実だけで完成と判断しないことが重要です。

「動くコードができた」ことと、「業務上必要なシステムができた」ことは同じではありません。

実際に使って感じている注意点

AIごとに出力形式をばらばらにしない

設計書の見出し、ファイル名、用語、コード規約がAIごとに変わると、成果物を統合しにくくなります。

プロジェクト共通のルールを用意し、すべてのAIエージェントに参照させる必要があります。

機密情報を入力してよい環境か確認する

社内文書、顧客情報、ソースコード、認証情報をAIに渡す前に、利用しているプラン、契約、データの取り扱い、社内ルールを確認する必要があります。

APIキー、パスワード、秘密鍵などの認証情報は、プロンプトやリポジトリに含めないようにします。

AIが作ったテストだけで安心しない

実装とテストを同じ前提で作ると、誤った仕様を両方が正しいものとして扱う可能性があります。

要件、受け入れ条件、実際の業務シナリオを基準にテスト内容を確認する必要があります。

レビュー結果も正しいとは限らない

別のAIにレビューさせても、指摘漏れや誤った指摘は発生します。

重要度の高い変更や、認証、認可、課金、個人情報に関わる処理は、人間が重点的に確認します。

現在の開発フロー

最後に、現在の使い分けを工程別にまとめます。

1. 企画・提案

担当：Microsoft Copilot

SharePointやTeamsから関連情報を探す
過去の企画書や提案書を確認する
顧客や案件に合わせて情報を整理する
企画書や提案書のたたき台を作る

2. 要件定義・設計

担当：ChatGPT / Codex

RFPを作る
要件定義書を作る
機能要件と非機能要件を整理する
画面一覧や画面遷移を作る
Astroでワイヤーフレームを作る
APIやDBを設計する
実装タスクに分解する

3. コーディング

担当：Claude

設計資料を確認する
機能を実装する
不具合を修正する
リファクタリングする

4. テスト