Agent-Spec 駆動開発（Agent-Spec Driven Development、ASDD）は、メルカリ が、自社向けに最適化した 仕様駆動開発 の一形態と位置づける開発手法に付けた名前である。この手法は 2 つのステップからなる。まず、エージェントが関連資料を読み、技術を調査し、コードベースを分析して、Agent Spec と呼ばれる実装計画を作成する。次に、エージェントがその Agent Spec に基づいて実装を行う。Agent Spec はタスクを列挙し、それぞれについて詳細設計、すなわちどの既存実装を参考にするか、どのファイルを変更し、どのような変更を加えるかを記したものであり、AI にとって曖昧さがなく、かつ人間にとっても読みやすいことを目指している。同プロジェクトの記録はまた、ASDD を、SDD の仕様さえも自動生成することを目指す手法として特徴づけている。
用法
この用語はメルカリの pj-double プロジェクトに由来し、同プロジェクトは 2025 年 9 月に ASDD を全社標準として提案した（pj-double: メルカリの開発生産性向上に向けた挑戦 — AI-Native化が辿り着いたASDDとプロセス変革の全貌）。社内の 2 つの記録は、Agent Spec を異なる力点で説明している。プロジェクト自身の記録は、Agent Spec をエージェントが生成しチェックする計画として説明している。同社の CTO は AI-Nativeという選択 ー 正解のない時代に、メルカリが選んだ指針 で、ASDD を AI フレンドリーな仕様フォーマット、つまり既存のコードベースとプロジェクトの規約に適合する、実装志向の設計書のテンプレートとして説明している。計画生成のステップでは、社内のナレッジベースに合わせて調整されたエージェントが一次情報を収集して計画の草案を作り、2 つ目のエージェントが、その計画がサービスのコーディング規約に従っているか、定められたセキュリティ基準を満たしているかをチェックする。2 つのエージェントは修正と評価を交互に繰り返し、要件や仕様に残った不確実な点は質問として開発者に投げかけられる。実装のステップでは、実装を担うエージェント、テストと静的解析を実行するエージェント、そして結果を Agent Spec と照らし合わせて検証するエージェントが、タスクが完了するまで協働する。
同プロジェクトの記録は 4 つの利点を挙げている。AI は計画または実装に必要な情報だけを保持するため、コンテキストが密に保たれること。計画をレビューできるため、結果が予測可能になること。実装は計画から宣言的に導かれるため、再利用可能で透明性が高くなること。そして各ステップへの貢献が全社的な知識として蓄積されること。実装が AI に委任でき非同期に実行できるプロセスになるため、同記録は生産性向上の源泉とみなすスケーラビリティを ASDD にもたらすものとしている。タスクは Agent Spec の生成時に、合理的に動作する最小の単位に分割され、1 タスクにつき 1 つのプルリクエストとなる。これを採用した開発者は、AI が書いたコードのレビューにストレスを感じなくなったと報告しており、プロジェクトの現時点での結論は、AI が書いたコードと人間が書いたコードの間で、レビューの負担に有意な差はないというものである。
CTO の記録では、テンプレートは API 定義、データモデル、データベーススキーマ、処理フロー、テストシナリオ、具体的な実装手順、そしてマイクロサービス間の依存関係を定める。その目的は、誰がどのタスクを、どのファイルで、どのコードスタイルで実装するかを明確にし、AI エージェントを使う誰もが同じ品質と規約で実装できるようにすることである。エージェントが正確にコーディングできるよう、小さなタスク粒度がテンプレートに組み込まれている。同記録はまた、Agent Spec をコーディング以外のプロセスにわたるエージェントの基盤として提示している。バックエンド、フロントエンド、モバイルの開発、QA のテストケース生成、AI レビュー、カスタマーサポートの仕様調査、リスク管理、コンプライアンスチェックである。また、UI を生成するエージェントである PJ Aurora の仕様としても使われている。CTO は ASDD を直感的な バイブコーディング と対比させている。その要点は、誰にでも再現可能な開発の規律を与えるエージェント型のアプローチであることであり、Agent Spec は社内で収集されたベストプラクティスから継続的に育てていくものとされている。
適用される場面
ASDD は、仕様と設計が固まった後のフェーズ、pj-double の記録が実装という下流の作業と呼ぶものに向けて設計されている。エージェントが必要とする一次情報がエージェントから利用可能であることを前提としており、メルカリの場合、それは計画生成エージェントが最適化されているナレッジベースを意味する。また実際には、作業を Agent Spec の生成時に、実行可能な合理的に最小の単位へと分割する。CTO の記録はこの前提を明示している。ASDD の品質は、Agent Spec を書く際に供給されるコンテキストの品質に大きく依存し、適切なコンテキストがなければ期待どおりには機能しない。だからこそ同社は、過去の仕様や意思決定の履歴を整理するナレッジマネジメントの取り組みを並行して進めている。
pj-double の記録は、上流で何がうまくいかなかったかを報告している。ASDD は、誰も合意していない確度の低い要求からでも実装を生成してしまうため、AI が隙間を自ら埋め、「技術的には正しいが誰も合意していない」成果物を生み出す。開発者からは、関係者間の合意形成に最も時間がかかったこと、自動生成された文書には根拠が書かれていないため合意のための媒体として機能しないこと、そして毎回ゼロから書き直される Agent Spec をレビューするほうが、手で書くよりも時間がかかりうることが報告された。記事の著者は自身の分析として、生成された長い Agent Spec は開発者の認知負荷を超えており、一次情報と正確さの不確かな生成内容とが混在していることが多い、と付け加えている。プロジェクト自身の診断は、AI とともに考え決めることが必要な作業を、AI に引き渡す作業として扱ってしまっていた、というものであった。
どの程度確立されているか：ASDD は 1 社の社内手法であり、それを構築したチームと同社の CTO によって説明されている。提示されている証拠はそのチーム自身の測定で、ASDD の土台である仕様駆動開発を採用したプロジェクトでは、工数見積もりに対して平均 150% を超える速度向上が見られたというものである。この数値は見積もり工数と実績工数の主観的な比較から集められたものであり、開発者からの定性的なフィードバックと合わせて示されている。ASDD そのものについての個別の数値は示されていない。