この記事は GENDA Advent Calendar 2025 シリーズ2 の9日目の記事です。
(他シリーズも並行して開催されています!)
1日目の記事 GENDA テックチーム公式Xアカウント「GENDA Tech」開設 にもある通り、チームのXアカウントが開設されました。
フォローをよろしくお願いいたします！
はじめに
株式会社GENDAのフロントエンド/バックエンド（FE/BE）開発部に所属している奥山と申します。
10月に入社し現在3ヶ月目で、直近はGENDA IDというサービスのフロントエンドとバックエンドの改修を行っています。
最近AIを活用している企業が増えてきていますが、GENDAもその一つです。
GENDAのエンジニアチームでは、Claude Code だけでなく、CursorやCodexなど複数のAIエージェントを取り入れて業務効率化を図っています。
本記事では詳述しませんが、週1で社内向けに「生成AI活用勉強会」を開催し、エンジニアが自発的に発信活動をしています。
私は過去業務でGitHub CopilotとCursorを利用していましたが、コードの予測機能くらいしか十分に使えていませんでした。
現在は実装だけでなく設計もAIに任せるようになってきたので、その過程についてまとめます。
各種AIを触って感じたこと
入社直後すぐにAIエージェントが使えるようになったので、とりあえず触ったことがなかったClaude Codeをメインで使うことにしていました。
しばらくして他のエージェントにも触れてみましたが、AIエージェントごとに思っていたより差があることに気づきました。
| AI | 利用モデル | 特徴 |
|---|---|---|
| Claude Code | Sonnet, Opus | 指示に忠実 実装を進めながら設計をする傾向あり |
| Codex | GPT-5.1-Codex | 全体設計をしてから実装に取り掛かる傾向あり 単独で既存コードから核心を突く能力が高い |
| Cursor | Composer 1 | コーディング速度の速さ |
Codexは設計能力が高いですが、コーディングについては精度や速度の面で他エージェントに劣ると感じました。
Cursorは最近Composer 1の登場で注目を浴びていますが、評判の通り作業速度は突出していました。
それでもコードの品質や安定性まで考慮すると、Claude Codeに軍配が上がると判断しました。
設計の分業
設計フェーズは基本的にCodexに任せ、残りの作業は基本的にClaude Codeを使い、好みや気分でCursorを使うというやり方を試してみました。
| 作業フェーズ | 担当AIエージェント |
|---|---|
| 要件定義から実装方針を立てる | Codex |
| 実装方針の推敲 | Claude Code (+Cursor) |
| タスクリスト作成 | Claude Code |
| 実装 | Claude Code or Cursor |
| レビュー | Claude Code or Cursor |
要件定義から実装方針を立てる
エージェントに対して要件定義を投げ、議論しながらmarkdown形式でファイルに実装方針をまとめてもらいます。
この時点で既存コードを具体的にどのように変更するかを提示してくれる場合がありますが、一旦それもそのまま記載してもらっています。
ファイルに出力しておけば後続フローで
「plan.md に記載した実装方針を理解した上で、〜〜〜 をして」
と指示するだけでよくなるので楽です。
実装方針の推敲
ある程度まとまったら別のエージェント（同じエージェントの場合は別セッションで）に
「plan.md に記載した実装方針について、この方法で実装可能か確認して」
と指示してフィードバックをもらい、内容のブラッシュアップを行います。
エージェントやセッションを変えると新しい視点でフィードバックをもらえることがあるので、私はそうしています。
タスクリスト作成
実装方針からタスクをチェックリスト形式で作成してもらいます。
この時点でコミット粒度を定めておけば巨大なコミットを防止でき、都度のテスト実行やレビュー難易度の削減につながります。
例えば、大きめのAPIを1つ作る場合でも以下のような構造で分割できると思います。
セクション1: リクエストバリデーション処理の実装
├─ タスク1: バリデーションルールの定義
├─ タスク2: エラーレスポンスの実装
└─ タスク3: バリデーション処理のテスト
→ コミット1: "feat: ユーザー登録APIのバリデーション処理を実装"
セクション2: ビジネスロジックの実装
├─ タスク4: ユーザー重複チェック処理の実装
├─ タスク5: パスワードハッシュ化処理の実装
└─ タスク6: ユーザー作成処理の実装
→ コミット2: "feat: ユーザー登録APIのビジネスロジックを実装"
セクション3: データベース処理の実装
├─ タスク7: トランザクション処理の実装
├─ タスク8: ユーザーデータの保存処理の実装
└─ タスク9: エラーハンドリングの実装
→ コミット3: "feat: ユーザー登録APIのデータベース処理を実装"
セクション4: レスポンス生成処理の実装
├─ タスク10: 成功レスポンスの実装
├─ タスク11: エラーレスポンスの実装
└─ タスク12: 統合テストの実装
→ コミット4: "feat: ユーザー登録APIのレスポンス処理を実装"
実装
実装方針とタスクリストを参考に実装させます。
タスクリストに随時チェックを入れてもらうようにすればフォールバック耐性を上げることができます。
(エージェントの機能でセッションを復帰することもできますが保険として)
レビュー
実装者とは別のエージェントで変更差分をチェックし、フィードバック内容を実装者に伝えて修正させます。
フィードバックがなくなるまでこの過程を繰り返します。
この時も review.md のようなファイルに出力してファイルを経由してやり取りできるとスムーズです。
どう変わったか
以前までは...
- 頭の中で考えていた実装を文章化してClaude Codeに伝えていた
- 既存コードに意図しない変更を入れられてしまった
- 実装後のテストのPASS率がそこまで高くなかった
新しいフローでは...
- 実装の文章化も事前に手伝ってもらっているので負担が減った
- あらかじめどこに変更を入れるか把握でき、AIエージェント側もそれをレールにして稼働できる
- 実装後のテストのPASS率が上がった
といった形で、コードの品質が上がっただけでなくエンジニア側の負担も減らすことができました。
大事なのはエージェントの使い分けではない
AIエージェントの特徴を軸に設計を分業させたわけですが、結局のところ実装前までにどこまで精度高く実装方針を立てられているかが鍵であり、AIエージェントの使い分けが本質ではないということを改めて痛感しました。
とはいえ特徴を掴み適材適所に担当させることが品質向上に繋がるのは間違いないと考えているので、今後も新しいAIエージェント(およびモデル)が登場した際にはキャッチアップをしていく予定です。
フローの発展
上記のフローをさらに発展させ、時間短縮や自動化を試みている最中です。
まだ模索している途中なので詳細は改めて別の機会でまとめたいと思いますが、簡単に紹介します。
複数の実装を並列で実行する
タスクリスト作成の際にフロントエンドとバックエンドでタスクを明確に分類し、複数エージェントに並行して実装させることでさらに作業効率化が図れます。
この時、gitのworktree機能を活用すればそれぞれ独立した環境下で作業が進められます。
Claude Code Docsにもこの方法が記載されています。
AI同士で直接やり取りさせる
AI同士のやり取りの橋渡しとしてエンジニアが命令を送信する場面がありますが、tmuxを活用することでAI同士が直接やり取りできる環境を実現できます。
~/.claude/CLAUDE.md などに具体的な方法・ルールを記載しておけば、エンジニアが介入すべき場面以外は全て自走してくれそうです。
おわりに
AIエージェントの進化は目覚ましく、今後も新しいモデルやツールが登場してくると考えられます。
実装を任せやすい環境になっている分、エンジニアにはそれらの精度を高めるためのフロー構築などを行うスキルが求められていると改めて認識しました。
本記事がAIエージェントを活用した開発の一助になれば幸いです。
Discussion