こんにちは。ラクス フロントエンド開発課 新卒2年目の持永です。
最近AI活用が進み、コードを書く速度は以前とは比較にならないほど上がりました。
そこで私は、
「AIに並列で実装を任せれば、複数の画面/機能を"爆速"で開発できるのでは？」
と考え、複数画面・複数機能を並列で進めるスタイルに挑戦しました。
並列開発の中で、工夫してうまくいった点もありました。
ただ、期待したほどの効率化には至らず、「手戻りの連鎖」と「レビュー負荷の増大」も招きました。
今回は、並列開発で工夫した点と誤算を整理し、そこから得た気づきを共有します。
- 1. 試したアプローチと結果
- 2. 工夫した点①：AI向けの仕様書と計画書を用意した
- 3. 工夫した点②：ローカル構成の整理
- 4. 誤算①：未確定要素による「手戻りの増加」
- 5. 誤算②：並列ばかり意識して、レビューを含む全体最適を見失った
- 6. まとめ
- さいごに
1. 試したアプローチと結果
使用したAIツールはCodexとClaude Codeです。
私が担当しているプロダクトのフロントエンド開発チームは二人体制で進めていました。
試したアプローチとしては、約1ヶ月半の実装期間で主に画面単位（一覧画面、詳細画面、編集画面など）でコンフリクトが起きない範囲を見極めつつ、4〜5画面を並列で進めました。
結論から言うと、直列で進める前提で立てていた見積もりを約1週間ほどオーバーしてしまいました。
2. 工夫した点①：AI向けの仕様書と計画書を用意した
AIに正確に実装させるかつ人間側が進捗と作業範囲を把握することを目的に、AI向けの仕様書と実装計画書を用意しました。
作成の流れ
1. フロントエンド向け仕様書の作成
案件の情報（要求仕様や概要設計などの上流仕様書、Figmaのリンク、API定義）を材料に、フロントエンド実装に必要な情報だけを抽出した仕様書をAIで作成
2. 仕様書のレビュー・修正
AIが出力した仕様書を自分でレビューし、不足や誤りがあれば修正を指示して内容を整形
3. 実装計画書の作成
整形した仕様書をもとに、実装計画書をAIと共に作成
4. 計画書に沿った実装
実装計画書に沿って、AIに実装を進めてもらう
実装計画書(イメージ)
- [x] 1. コンポーネントの基本構造を作成 - [x] 2. API呼び出し処理を実装 - [ ] 3. バリデーションロジックを追加 ← 今ここ - [ ] 4. エラーハンドリングを実装 - [ ] 5. ローディング状態の表示を追加
効果
計画書をチェックリスト形式にしたことで、AIが今どこを実装しているのかが一目でわかるようになりました。
並列で複数の機能を進めていても、それぞれの計画書を見れば「機能Aは3番目のステップ」「機能Bは5番目で完了間近」といった進捗を把握しやすくなりました。
結果として、作業を切り替えるたびに私が進捗を思い出したり確認したりする手間が減りました。
3. 工夫した点②：ローカル構成の整理
AIへの参照範囲の説明コストを下げつつ、並列開発の作業切り替えを分かりやすく素早く行うことを目的に、ローカルの資材配置を整理していました。
git worktree などで複数ブランチを同時に触ると、作業ディレクトリが増えていきます。
その状況でAIに、「案件や機能ごとに、現状のフロントエンド実装がバックエンド実装やAPI仕様と整合しているか」を確認させるとき、参照させる範囲や前提（どのブランチ/どの資材なのか）を的確に渡すための手間が増えてしまいます。
そこで、案件/機能ごとにフロントエンド/バックエンド/API仕様の資材をひとまとまりにしつつ、別途「バージョン確定時点の固定セット」も置く、という形にしていました。
この構成自体もAIに指示して組んでもらいました。
ローカルディレクトリ構成(イメージ)
＊ 担当プロダクトはポリレポ構成（フロントエンド・バックエンド・API仕様がそれぞれ別リポジトリ）で開発されています。
workspace/
├── vX.Y.Z/
│ ├── epic-1/ # 案件ごと
│ │ ├── feature-a/ # 主に機能/画面ごと
│ │ │ ├── AGENTS.md # ブランチ指定、役割等の説明
│ │ │ ├── CLAUDE.md # ブランチ指定、役割等の説明
│ │ │ ├── plan.md # 実装計画書
│ │ │ ├── frontend/
│ │ │ ├── backend/
│ │ │ └── api-spec/ # API定義
│ │ ├── feature-b/
│ │ │ └── ...
│ │ └── spec-epic-1/ # 案件の仕様
│ └── fixed-vX.Y.Z/ # 確定資材（ブランチ/コミット固定）
│ ├── frontend/
│ ├── backend/
│ └── api-spec/
└── templates/
└── spec_template.md #仕様書のテンプレート
ポイント
各feature直下に配置したAGENTS.mdやCLAUDE.mdにて、「このブランチで作業すべき」「このディレクトリ内のapi-specは今回開発したい案件の確定済みのAPI定義である」といった前提情報をAIに伝えるようにしていたことで、AIによる意図しないブランチ変更や誤った参照を減らすことができました。
効果
この構成にしたことで、AIに依頼するときに「どこを見てほしいか」を一言で指定しやすく、横断的な参照もしてもらいやすくなりました。
例えば「このバージョンのこの範囲で、フロントエンド/バックエンド実装とAPI仕様の不整合箇所を見てほしい」といった依頼を、細かいブランチなどの指定を毎回することなく依頼できるようになりました。
結果として、開発中のAPI仕様や実装との整合性チェックや、バージョンごとの不具合調査における原因切り分けといった場面での横断的な分析で、この整理が役に立ちました。
4. 誤算①：未確定要素による「手戻りの増加」
開発段階では、画面の文言や共通仕様が完全には確定していないこともあります。
その状態で複数の機能を並列で進めていき、次のような事態が起きました。
何が起きたか
- 実装途中で「文言の変更」や「仕様の微調整」が発生
- 文言が少し変わるだけでも、実装計画書の該当箇所をすべて修正する必要があった
- 並列で実装していた他の機能にも同じ変更が関係する場合、そちらの計画書も修正が必要に
「資料の修正 → AIへの再依頼 → 生成物の差分確認」という往復が複数の作業で同時に発生し、手戻りが連鎖していきました。
なぜ起きたか
AIになるべく正確に実装させようと実装計画書をAIと共に調整していく際に、細かく書きすぎていたことが主な原因でした。
並列で動かしているほど、確定していない要素の影響が広がりやすくなります。
細かすぎる実装計画書を作成したために小さな変更が入るだけで周辺資料の調整コストが積み上がり、結果として全体の効率が落ちてしまいました。
どうすべきだったか
並列開発そのものが悪いのではなく、「後で変わりやすいもの」と「早めに固めたいもの」を切り分けるべきだったと考えます。
具体的には、以下の点が挙げられます。
- 文言のように後で直せるものは差分を小さく保つか、Figma上の文言を正として計画書にはリンクのみを記載して参照先を分離しておく。
- 変更されやすい要素を最初から細かく指定しすぎず、揺れにくい部分（ロジックや設計）から先に積み上げる計画にする。
5. 誤算②：並列ばかり意識して、レビューを含む全体最適を見失った
もう一つの問題は、並列で進めることに意識が向きすぎて、レビューまで含めた「全体としての進めやすさ」を考えきれていなかった点です。
何が起きたか
- 複数を並行して進めていたため、最初のPRを出すまでに時間がかかった
- その間、レビュワーはレビューできる対象がない状態が続いた
- 複数のレビュー依頼がほぼ同時期になり、レビュワーへの負荷が集中
- 指摘対応も同時期に重なる
- 自分以外から見ると進捗が把握しづらい状態に
なぜ起きたか
自分としては「手を止めない」ことを優先して作業を積み上げがちになっていました。
AIを活用することで自分の実装ペースだけは維持できてしまうため、レビュワーとのペースのズレに気づきにくくなっていました。
どうすべきだったか
並列で進めるなら、なおさらPRの粒度・順番・レビュー依頼のタイミングを「自分の都合」だけで決めず、レビュワーと認識合わせした上で進めるべきでした。
具体的には、以下の点が挙げられます。
- 先に固めたいロジックや設計だけを小さく切って早めに見てもらうことを留意して、並列で進める優先順位を決める。
- レビューが走っている間に次の作業を進めつつ、指摘対応が滞らない余白も確保する。
6. まとめ
工夫した点
- AI向けの仕様書と計画書（チェックリスト形式）を用意したことで、並列で進めていても各機能の進捗状況が一目で把握できた。
- AIが参照しやすいようにローカル構成を整理したことで、開発中のAPI仕様や実装との整合性チェックや、不具合の原因切り分けがやりやすくなった。
誤算
- 細かすぎる実装計画書を作成して並列で進めた結果、「資料修正 → AIへの再依頼 → 差分確認」の往復が連鎖した。
- PRの粒度やタイミングが極端になり、レビュー負荷と待ちが増えた。
気づき
今回の経験を振り返ると、「手戻りを減らす計画」「レビュワーとの連携の意識」といった内容は、基本的なことばかりでした。
AIによって上がった実装スピードを過信して、その「当たり前」を見失っていたことに気づきました。
今回の挑戦を踏まえた反省点は以下の通りです。
- 計画書に変わりやすい要素を細かく書きすぎない
文言はFigmaを参照させるように指定したり、仕様に絡む部分は仕様書側に記載することで、仕様変更時の「資料修正 → 再依頼 → 差分確認」の往復を減らす。 - 並列で進める上での優先度を留意する
レビューも含めて、どの粒度・順序で進めるべきかを着手前に計画/認識合わせしておく。
さいごに
AIのおかげで、実装自体は確かに速くなりました。
ただ、「速く作れる」ことと「全体が早く終わる」ことは別だと、今回改めて実感しました。
仕様が揺れやすい部分は揺れる前提で切り分け、レビューが滞らない粒度と優先度で小さく出して、確実にマージしていく。
結果的にチーム全体の進みが良くなるような進め方を考える力は、AIで開発を行っていく上でも変わらず求められていくものだと考えます。
同じようにAI活用×並列開発を試している方の参考になれば幸いです。
