こんにちは。メルカリモバイル Tech Leadの@_seitauです。
この記事は、Merpay & Mercoin Advent Calendar 2025 の9日目の記事です。
先日公開された記事『pj-double: メルカリの開発生産性向上に向けた挑戦』では、メルカリグループ全体として取り組んでいる ASDD (Agent Spec Driven Development) という新たな開発手法の概念や、AIネイティブな開発への展望について解説されました。
この記事では、その実践編として、より現場の実務に焦点を当てます。 2025年3月にリリースしてからさまざまな機能追加をしてきたメルカリモバイルの開発現場において、私がどのように ASDD を運用・実践してきたか、実際のプロジェクト事例を交えて紹介します。
実践フロー：PRDから実装まで
Coding Agentの登場により、開発者は複数のタスクを並列で進めることが可能になりました。このメリットを最大化するための具体的なワークフローについて、最近リリースした メルカリモバイルの複数回線対応プロジェクトを例に解説します。図示しているタスク名は仮のものを使用しています。
Step 1: PRDをPdMが作成し、リポジトリにコミットする
まず、情報の管理方法から見直します。 PdM（プロダクトマネージャー）は、PRD（プロダクト要件定義書）をドキュメントツールではなく、Markdown形式でGitHubリポジトリに直接コミットします。
リポジトリ内に仕様が存在することで、後続のCoding Agent（Claude CodeやCursorなど）にコンテキストとして読み込ませやすくなり、エンジニアが素早く開発に着手しやすくなります。
Step 2: Coding Agentを活用してAgent Specを生成する
次に、エンジニアはCoding Agentを使用して Agent Spec（AIへの実装指示書） を生成します。
この際、単にPRDを読ませるだけでなく、Slackでの議論ログやNotion上のメモなど、散らばっている関連コンテキストにも接続して読み込ませます。これにより、人間がゼロから仕様を書き起こすことなく、文脈を考慮した精度の高いSpecドラフトをAgenticに生成することができます（この仕組みの詳細は先述の記事を参照）。
Step 3: タスクリストを作成し、依存関係を可視化する
生成されたSpecを元に、具体的な実装タスクを洗い出し、「どのタスクが独立しており、どのタスクが依存関係にあるか」 を整理します。 私は実装に着手する前に、以下のようなタスクリストを作成し、依存関係を可視化しています。
| タスクID | 機能項目 | タスク名 | 説明 | 規模 | 依存関係 |
|---|---|---|---|---|---|
| T001 | 申し込み | 回線申し込み情報取得API修正 | フィールド追加 | S | – |
| T002 | 申し込み | 回線申し込みAPI修正 | バリデーション追加 | S | T001 |
| T003 | 申し込み | 回線数制限バリデーション | 上限追加 | M | T001, T002 |
| T006 | Top画面 | 回線一覧API実装 | 回線一覧取得 | M | – |
| T009 | Default回線 | インデックス追加 | インデックス追加 | S | – |
| T008 | Default回線 | 回線切り替えロジック実装 | 申込・開通 | L | T009 |
この表において最も重要なのが 依存関係 の項目です。これを図解すると、以下のように並列実行可能なラインが見えてきます。
これにより、「Stream A, B, Cは依存関係がないため、3つのAgentを同時に稼働させて並列実装が可能である」といった判断を的確に行えるようになります。
Step 4: チームレビューとSpecの磨き込み
整理されたタスクとAgent Specは、実装を開始する前にチームメンバーによるレビューを受けます。ここで仕様の抜け漏れや認識のズレを解消しておきます。
現場で機能させる原則
このフローを運用する上で、私が重視している原則が3点あります。
粒度を小さく保つ
1タスク = 1PR を基本とします。 AIに一度に大量の変更を指示すると、意図しない挙動やバグが発生するリスクが高まります。「バリデーション追加のみ」「DBカラム追加のみ」といったレベルまで粒度を細分化することで、AIの実装精度が安定し、人間側のレビューコストも低減されます。
依存関係を明示する
前述の通り、依存関係の定義は並列化における要です。 自分が設計（Spec作成）を行っている間に、バックグラウンドで複数のエージェントが独立したタスクの実装を進めているという状態を作り出すことが重要です。
レビューの対話をコンテキストとして活用する
Agent SpecのレビューMTGは、録画または文字起こしをしておくことを強くおすすめします。
最初のSpecだけでは表現しきれていなかった背景やニュアンスが、レビュー時の対話には多く含まれています。この文字起こしログをCoding Agentに読ませてSpecを改善させることで、当初の記述では表現できていなかった文脈や設計の抜け漏れを補足し、より精度の高いSpecへと昇華させることができます。
例えば、チームメンバーに設計を説明する中で、
- 同じ時期に走っている別PJで追加される機能との整合性は？
- なぜこのカラムにIndexを追加する必要があるのか？
- どのデータが回線に紐付き、どれがアカウントに紐づくのか？
など、チームメンバーから設計をみた時の疑問点が浮き上がります。レビューMTG内でこれらの質問に対して説明し、そのログをSpecに反映することで、設計者だけでなくチーム全体で納得感のあるSpecになります。設計の意図を適切にSpecに反映するのは、Coding Agentの脱線を防ぐうえでも重要です。
導入に向けたステップ
もし、この手法を個人のタスクから試してみたい場合は、以下のステップから始めることをおすすめします。
- PRDをMarkdownで記述する: AIがコンテキストを理解しやすくなります。
- Coding Agentにドラフトを書かせる: 自分でゼロから書かず、PRDを読ませたAgentにSpecの叩き台を作らせてください。
- 依存関係リストを作成する: 実装に着手する前に、タスク一覧と依存関係を整理してください。これが並列化の指針となります。
おわりに
あらかじめSpecを書いてから実装に着手する手法は目新しいものではありませんが、この記事に書いた原則やワークフローを意識することで、Coding Agentの力をさらに引き出し、並列に素早く実装を進めることができます。
実際にAgent Specを用いて並列で開発するワークフローを実践するようになってから、1ヶ月かかる想定だったプロジェクトを1週間で終えることができた事例もあり、確実に開発速度が向上しています。
これらの定量的な開発速度の変化や、AI Native化へ向けたメルカリの開発組織の取り組みについては先日開催したmercari GEARS 2025で発表しています。ぜひ併せてご覧ください。
メルカリでは、ASDD (Agent Spec Driven Development) を含め、日々よりよい開発手法を試行錯誤しています。この記事がAIネイティブな開発スタイルについて考えるきっかけとなれば幸いです。
明日の記事はpanoramaさんです。引き続きお楽しみください。
