この記事は、Merpay & Mercoin Advent Calendar 2025 の一環として、メルペイの VPoE オフィスに所属するマネージャーが執筆したもので、メルカリ における Project Double（pj-double）の経緯を語っている。このプロジェクトが掲げるミッションは、開発の体制とプロセスを AI-Native に再設計することで、プロダクト開発の生産性を倍増させることである。記事はこれを、社内における AI 支援コーディングの第一波が抱えていた問題への対応として位置づけている。個々の開発者は大きな成果を上げたものの、その手法は個人のものにとどまり、組織としての改善には結びつかなかったという問題である。
記述は時系列に沿って進む。2025 年初頭のボトムアップな試行錯誤から始まり、各プロジェクトで AI が実際にどう使われているかを 3 か月かけて調査し、2025 年 9 月に Agent-Spec 駆動開発（ASDD）を標準として提案し、10 月からは取り組みを全社へと拡大するまでを追う。後半は振り返りで、プロジェクトから得られた 4 つの教訓と、ASDD がどこで不十分だったかの分析が述べられている。
要点
- 記事は、AI の実践を共有しようとする初期の取り組みが失敗した原因を、バイブコーディング の構造的な性質に求めている。記事はバイブコーディングを、AI に段階的に指示を送り、その出力を見ながら軌道修正していくやり方と説明する。このプロセスは同期的かつ対話的であるため、生産性は各開発者のその場の判断に左右され、その判断はチャットログの中にとどまって後から説明することが難しい。そのため、透明性も再利用性もなかったという。
- pj-double は 2025 年 7 月頃、メルペイの VP of Engineering Office で立ち上げられた。個人による試行錯誤の「Divergence（発散）」フェーズから、全社的で再現可能な開発標準を確立する「Convergence（収束）」フェーズへの移行と位置づけられている。
- 最初の 3 か月間、プロジェクトはメルペイとメルカリ Mobile の 30 以上のバックエンドプロジェクトと協働し、どのフェーズでどの AI 手法が使われたかを毎週追跡した。生産性は、各プロジェクトの開始時点での従来の工数見積もりと実績工数を比較することで測定した。記事によれば、この統計は主観的なものであり、ノイズを減らすためにフェーズごとに集計したという。
- この尺度では、仕様駆動開発 が最も効果的な手法だった。これを採用したプロジェクトは、見積もりと比べて開発速度が平均 150% 以上向上し、他の AI 支援手法を用いたプロジェクトと比べても 80% 以上上回った。
- 記事によれば、定性的に見ると、AI から最も大きな成果を引き出した開発者は、他の開発者と 3 つの点で異なっていた。関連する一次情報を最初に AI に与えていたこと。タスクの目的、手順、完了条件を明示していたこと。そして、たとえば実装を別々の会話に分けたり Claude Code のサブエージェント機能を使ったりして AI の作業コンテキストを小さく保ち、コンパクションによって AI がタスクを見失わないようにしていたことである。
- ASDD は、これら 3 つの実践を仕組みとして定着させるために 2025 年 9 月に提案された。エージェントがまず実装計画（Agent Spec）を生成し、次にそれを実装するという 2 ステップの手法である。
- 品質と保守性について、記事は AI の利用がトレードオフにはなっていないと報告している。QA の自動化やその他のガードレールによって機能面のチェックがプロセスに組み込まれており、チームは開発者体験ツール DX を使って revert 率と MTTR を監視しているが、品質低下の兆候は見られないという。AI が書いたコードの可読性や拡張性の問題については、その原因の大半をモデルではなくコンテキストの欠如に帰している。
- レビューのボトルネック について、記事は、レビューの負荷は AI が書いたコードであることではなく、プルリクエストのサイズに起因していたと結論づけている。AI のスピードによって巨大な差分が 1 つの PR に詰め込まれていたのである。Agent Spec の生成時に作業を妥当な最小の作業単位に分割し、1 タスク 1 PR にしたことでその負荷は解消され、現時点での記事の結論は、AI が書いたコードと人間が書いたコードとでレビューの手間に有意な差はないというものである。
- QA では、チームはまずワークフローを自動化するためにリッチな UI を持つツールを構築したが、記事はこれを典型的な「ビルドトラップ」と呼んでいる。変更のたびにアプリケーションコードの変更も必要になるため、そのアプリによってプロンプトや手法の改善がかえって難しくなったのである。記事の教訓は、手法の洗練に焦点を当てた最小限の構成から始めること、そしてツールへのフィードバックを求めるのではなく、プロセスの変革にチームを巻き込むことである。
- 記事は、標準化と陳腐化のジレンマと記事が呼ぶものから抜け出す方法として、バックキャスティングを主張している。つまり、エージェントが自らコンテキストを収集し、コーディングルールに従って実装し、QA を実行する未来から逆算して考えるということである。今日の制約を前提に作られたツールは数か月で陳腐化してしまうからだ。
背景
記事は ASDD の限界について率直に述べている。開発者からは次のような声が寄せられた。Agent Spec はすでに合意済みの仕様と設計を前提としているが、最も時間がかかっていたのはその合意形成そのものだったこと。自動生成されたドキュメントには判断の根拠が記されておらず、合意のための媒体として機能しないこと。そして、毎回ゼロから再生成される長い Agent Spec をレビューするのは、手で書くよりもコストがかかり、とりわけ一次情報と出所の分からない生成コンテンツが混在している場合にそうであることである。チーム自身の診断は、AI と一緒に考え、決めることで行うべき作業を、AI に任せる作業として設計してしまったというものである。
ここから記事は、同期的な協働である「AI と考える」「AI と決める」と、非同期的な協働である「AI に任せる」とを区別し、要件定義や設計のような上流の作業には同期的な協働が必要だと主張している。上流の作業の価値は、それが生み出すドキュメントではなく、そこに記録される比較、決定、合意にあるからである。記事はこれを成果としてではなく、現在も探索・検証中のプロジェクトの今後の方向性として示している。
記事中の数値はすべて同社自身の社内計測によるものであり、とりわけ生産性の数値は、見積もり工数と実績工数の主観的な比較に基づいている。