メルカリの「AI-Native開発」とは？ツール導入で終わらせない組織変革の実践知

「AIツールは配ったが、使う人と使わない人に分かれてしまった」——多くの開発組織が直面する壁です。メルカリはこれを、ツールではなくプロセスと組織の再設計として解いています。本記事では公開された実践事例をもとに、AI-Native開発の中身を具体的に読み解きます。

AI-Native開発とは何か — 「AIツール導入」との決定的な違い

定義：ビジョン・プロセス・組織構造をAI前提で再設計すること

AI-Native開発をひと言で定義すると、「AIが使える組織」ではなく「AIがいる前提でしか成立しない業務設計」を実現することです。

ツール導入はあくまで手段であり、AI-Nativeは前提そのものの置き換えを意味します。GitHub Copilotを全員に配布して「AI活用が進んでいる」と見なすのは、AIツール導入の段階に留まっています。一方でAI-Nativeの組織では、要件定義から実装・テスト・レビューに至るまでのプロセス全体が、AIと協働することを前提に設計されています。

よくある誤解：Copilot導入＝AI-Nativeではない

AIツールを個人に配布しても、組織としての再現性は生まれません。プロンプトは属人化し、ベテランエンジニアだけがうまく使いこなし、チーム全体の生産性向上には結びつかない——こうした状況に心当たりのある方は多いのではないでしょうか。

個人の生産性向上で止まっている組織と、AI-Nativeを実現している組織の最大の違いは「組織的な再現性」にあります。特定の個人のプロンプトスキルに依存するのではなく、チームの誰もが同じ品質でAIと協業できる仕組みを整備しているかどうかが、分岐点となります。

なぜ今、開発組織にとって無視できないテーマなのか

2025〜2026年にかけて、国内の主要企業でAI活用が加速しています。「試す」フェーズから「組織能力にする」フェーズへの移行が、エンジニアリングチームにとってのリアルな課題になりつつあります。

メルカリのAI-Native Company宣言 — 数字で見るインパクト

2025年7月の公式宣言と、その後の組織体制

メルカリは2025年7月に「AI-Native Companyの実現」を公式宣言しました。その後、2026年6月にはCTO木村俊也氏がCHRO（最高人事責任者）・CAIO（最高AI責任者）・CTOを兼任する体制を構築しています。

この人事は象徴的です。AI戦略と人事戦略を同一の責任者に統合したことは、「AI導入は人事イシューである」という組織的な位置づけを示しています。テクノロジーの問題として扱うのではなく、どう人を育て、組織文化を変えるかという問いとして捉えているのです。

公開されている主要指標

指標	数値
AIツール活用社員比率	約95%
AIによるコード生成比率	約70%
開発スピード向上	前年比 +64%

（出典：メルカリエンジニアリングブログ、2026年6月30日公開）

数字の読み方 — 「70%」が意味しないこと

「コードの70%をAIが生成」という数字は、一見して衝撃的です。しかし、生成量と価値は必ずしもイコールではありません。この数字が意味するのは、レビュー・検証・意思決定の体制がしっかり整備されているからこそ、安心して委譲できる割合が増えたということです。

自社に持ち帰る際には「うちでも70%を目指そう」と設定値を目標にするのではなく、どういった仕組みがあってこの割合を実現しているのかに着目することが重要です。

中核概念①：ASDD（Agent-Spec Driven Development）

ASDDとは — SDDを組織向けに最適化した開発手法

ASDDは、メルカリが実践から生み出した開発手法です。Spec-Driven Development（SDD）をベースに、AIエージェントが実行できる形式に最適化されています。設計思想の中核にあるのは「AIの明瞭性と人間可読性の両立」です。

ステップ1｜Agent Spec 生成

資料読解・技術調査・既存コード解析をAIが行い、実装計画を自動生成します。成果物として出力されるのは、タスク一覧・詳細設計・参考実装の指定を含んだ仕様書です。

このステップの本質は、「AIの手戻りを仕様段階で潰す」 ことにあります。あいまいな指示でAIに実装させると、後工程での修正コストが膨らみます。上流で高精度な仕様を固めることが、全体の生産性を決定します。

ステップ2｜実装生成

Agent Specを起点に、AIが実装・テスト・検証を自律実行します。このフェーズは非同期で処理されるため、スケールしやすい設計になっています。人間が同期的に監視し続ける必要がなく、並列でタスクを進められます。

成果：見積比平均150%以上の開発速度

ASDDを採用したプロジェクトでは、当初見積比で平均150%以上の開発速度向上が報告されています。これは単にAIが速くコードを書くからではなく、上流の仕様定義に時間をかけることで下流の手戻りが激減するという、プロセス全体の最適化によるものです。

中核概念②：AI協業の三分類「考える・決める・任せる」

三分類の全体像

分類	役割	同期/非同期	主な適用フェーズ
AIと考える	情報提示・思考拡張	同期	要件定義・設計
AIと決める	意思決定の記録	同期	設計・技術選定
AIに任せる	自律実行	非同期	実装・テスト

上流は同期的協業、下流は非同期委譲が最適解

この三分類で重要なのは、フェーズによって最適な協業スタイルが異なるという点です。

要件定義や設計フェーズでは、AIと同期的に対話しながら思考を深め、意思決定の根拠を記録します。一方、実装やテストフェーズでは、AIに非同期で委譲することでスケールさせます。

上流で「AIに任せる」を選ぶと、判断根拠が失われます。下流で「AIと一緒に考える」を続けると、スケールしません。この使い分けの混同が、AI活用が中途半端に終わる最大の原因です。

中核概念③：ハーネスエンジニアリング

ハーネスエンジニアリングとは、AIの周囲を取り囲む「環境・制約・フィードバック」を意図的に設計する規律です。

中核となる原則は「機構は外部から調達し、判断基準は自前で用意する」というものです。AIモデルやツールは購入できます。しかし「何を良しとするか」「どのコードがこのチームのスタンダードか」は、自社・自チームにしか定義できません。

プロンプトエンジニアリングが個々の入力を最適化するのに対し、ハーネスエンジニアリングはAIが動作する環境全体を設計します。CI/CDパイプライン、テスト構造、ドキュメント管理、セキュリティスキャン——これらすべてがAIと協働するための「ハーネス」です。

実践事例：エンジニア2名のNFTチームは何をしたか

ここからが本記事の核心です。メルカリNFTチームの2名体制による実践は、大企業の数字より再現性が高く、自社に持ち帰りやすい知見の宝庫です。

① コードの一貫性を整える — AIが読む文脈量を最小化する

まず着手したのは、大規模リファクタリングによるコードの一貫性向上です。万単位の行数削減を行い、AIが参照すべきコンテキスト量を最小化しました。

これは「AIのためのリファクタリング」という新しい投資判断です。人間が読みやすいコードと、AIが高精度に解析できるコードは、必ずしも同じではありません。一貫したコーディングスタイルと命名規則が、AIの出力品質を直接左右します。

② 判断記録の分離 — RDR（Requirements Decision Records）

仕様（spec）と意思決定の根拠（decision）を分けて保存する仕組みとして、RDR（Requirements Decision Records）を導入しました。

ADR（Architecture Decision Records）との違いは、アーキテクチャに限らず要件レベルの判断も対象とする点です。「なぜこの仕様にしたのか」「どの選択肢を検討して、なぜ採らなかったのか」を記録することで、AIが文脈を正しく理解できるようになり、再設計時の手戻りも防ぎます。

③ テストの決定論化 — Playwrightで推論を排除する

Playwrightを活用し、出品から配送までのフローを自動化しました。ここでの核心的な考え方は「実行段階からAIの推論を追い出す」ことです。

AIに曖昧な判断を委ねるのではなく、テストを決定論的に設計することで、AIが確実に実行できる領域を明確に定義します。「何を自動化できるか」ではなく「何を決定論化すれば自動化できるか」という問いの立て方が重要です。

④ 多層防御セキュリティ — commit / PR / チケット作成の3段階

AIが大量のコードを生成する環境では、セキュリティリスクも比例して拡大します。メルカリNFTチームでは、commit・PR・チケット作成の3段階それぞれに個人情報スキャンを組み込みました。

ひとつの防衛線に頼るのではなく、ワークフローの複数箇所に自動チェックを埋め込む「多層防御」の考え方は、AI活用が進むほど重要度を増します。

⑤ Claude Code の skill 活用 — 過去のレビューコメントを資産化

チームに蓄積されたレビューコメントをClaude Codeのskillに反映し、AIによる一次チェックを実装しました。さらに、spec → design → plan → issueというパイプラインを自動化しています。

この取り組みの本質は「レビュー文化そのものをコード化する」という発想です。優秀なシニアエンジニアのレビュー観点は、これまで個人の頭の中に留まっていました。それをskillとして外部化することで、チーム全員がその知見を恒常的に受け取れるようになります。

⑥ Git中心ワークフロー

ドキュメントの原本をGitで管理し、Notionはコメントや議論の場所に限定するというルールを定めました。

AIが情報を参照するためには、「単一の信頼できる情報源（Single Source of Truth）」が必要です。複数のツールに情報が分散していると、AIが古い情報を参照したり、矛盾した情報を統合しようとしたりするリスクが生まれます。

成果：PR流量が数倍に、しかし修正系PRは増えていない

これら6つの施策の結果、PR流量は数倍に増加しました。特筆すべきは、修正系PRを抑えつつ新機能PRが拡大したという点です。「速くなったが品質が下がった」ではなく、「品質を維持したままの生産性向上」を2名体制で達成しています。

pj-double が明らかにした4つの学び

Vibe Coding の限界

都度AIに指示を出す同期的なアプローチ（Vibe Coding）では、判断がAI対話ログの中に閉じてしまいます。その会話が終わると知識は消え、組織として再現できる資産になりません。

学び1｜AIによる高速化は品質低下を伴わない

速くなった分のリソースを検証に再投資できるため、むしろ品質向上につながります。「AIに任せると品質が下がる」は、適切な仕組みなしに委譲した場合の話です。

学び2｜PRレビューが辛い本当の理由は「AI製」ではなく「差分の大きさ」

AI生成コードだからレビューが辛いのではありません。PRの差分が大きすぎることが本質的な原因です。この原因を取り違えると、「AIの使用を制限する」という誤った対策に向かってしまいます。

学び3｜ツール開発より、現場との検証サイクルが本質

新しいツールを作ることよりも、既存のツールを実際の現場で使いながら検証・改善するサイクルを回すことの方が価値を生みます。

学び4｜バックキャスティングでビジョンを統一する

具体的なツール名でビジョンを語ると、組織の目線が揃いません。「Claude Codeを使いこなす組織になろう」ではなく、「来るべき未来の姿から逆算して、今何を整備すべきか」を問うバックキャスティングのアプローチが有効です。

自社チームで明日から始める AI-Native 移行ステップ

メルカリの事例から抽出した、実践的なステップをまとめます。

✅ AI-Native移行チェックリスト

Step1｜現状診断 — AIが読める状態にコードとドキュメントがあるか？命名規則や構造の一貫性を確認する
Step2｜情報源の一本化 — Gitを中心に情報を集約し、ツール間の分散を解消する
Step3｜三分類の合意 — 「考える・決める・任せる」のどれをどのフェーズで使うか、チームで明文化する
Step4｜意思決定記録の運用開始 — RDRまたはADRで仕様と決定根拠を分けて記録する
Step5｜レビュー観点の外部化 — 蓄積されたレビューコメントをClaude CodeのskillやCIルールとして実装する
Step6｜テストの決定論化 — Playwrightなどで重要フローを自動化し、AIに委譲できる範囲を広げる

すべてを一度に着手する必要はありません。最初の一手として最も効果的なのは、Step2の情報源の一本化です。AIが参照できる単一の情報源を整備するだけで、その後のあらゆる施策の効果が高まります。

よくある質問（FAQ）

Q. AI-Native開発は少人数チームでも実現できますか？

A. むしろ少人数チームの方が実現しやすいケースがあります。 メルカリNFTチームの事例がまさにそれで、2名体制でPR流量数倍という成果を出しています。意思決定の速さと試行錯誤のしやすさという観点で、少人数チームはAI活用の効果が可視化されやすい特徴があります。

Q. Claude Code は具体的にどう使われていますか？

A. 主にskillの活用とパイプラインの自動化に使われています。 チームに蓄積されたレビュー観点をskillとして実装し、AIが一次チェックを担う仕組みを構築。さらにspec → design → plan → issueの流れを自動化することで、上流から下流までの工程をシームレスにつなげています。

Q. AI生成コードの品質やセキュリティはどう担保しますか？

A. ハーネスエンジニアリングと多層防御の組み合わせです。 commit・PR・チケット作成の各段階にセキュリティスキャンを組み込み、テストの決定論化によって検証の自動化を進めます。「AIを信頼する」のではなく「AIが正しく動ける環境を設計する」という考え方が基本です。

Q. 日本企業での普及状況はどうなっていますか？

A. 2025〜2026年にかけて「試す段階」から「組織能力にする段階」へ移行しつつあります。 メルカリのような先行事例が公開されることで、他企業の参照事例が増え、普及が加速する傾向にあります。

Q. 導入して最初につまずくポイントはどこですか？

A. 「考える・決める・任せる」の使い分けの混同です。 上流フェーズでAIに任せすぎて判断根拠を失うか、下流フェーズでAIとの対話にこだわりすぎてスケールしないか、そのいずれかでつまずくチームが多い傾向があります。三分類をチームで共通認識として持つことが、最初の関門を乗り越えるカギです。

まとめ｜AI-Native化の本質は「判断の資産化」にある

メルカリのAI-Native開発の事例を通じて見えてくるのは、ひとつの共通した本質です。それは「判断を資産化する」という営みです。

ツールは調達できる。しかし「何を良しとするか」の判断基準は自前で作るしかない
速度向上の裏側には、コード一貫性・テスト決定論化・意思決定記録という地道な整備がある
Vibe Codingが限界を迎える理由は、判断が対話ログに閉じてしまうからだ

AI-Nativeへの移行は、一日で完成するものではありません。しかし、今日から着手できる一手は明確です。まず情報源を一本化し、AIが読める環境を整える。 そこから始めることで、その後の施策すべての土台が整います。

「AIツールを配った」の先に何があるのか——メルカリの実践知は、その答えを具体的に示してくれています。

参考リンク

AI-Nativeな開発の実践に向けて｜メルカリエンジニアリング
pj-double: AI-Native化が辿り着いたASDDとプロセス変革｜メルカリエンジニアリング
エンジニアリングの常識をAI-Nativeに再定義｜エンジニアtype