メルカリに学ぶAI-Native開発の本質：『判断基準』のコード化がもたらす開拓

開発現場で誰もが一度は経験する、深夜の障害対応や、意図しない挙動を繰り返すスパゲッティコードのデバッグ。AIにコードを書かせれば、これらの苦痛から解放されると夢想した時期が私にもあった。しかし、現実は甘くない。プロンプトを投げれば「動くコード」は一瞬で出力されるが、それがプロダクトの文脈やアーキテクチャの思想に合致しているかは別問題だ。AIが生成したコードが、既存のシステムとデッドロックを起こすような設計になっていれば、結局は人間がその後始末に追われることになる。

私は、メルカリNFTチームがこの4ヶ月間で取り組んできた「AI-Nativeな開発」の軌跡を読み解き、彼らが辿り着いた結論に強い共感を覚えた。彼らがリソースを集中させたのは、AIを動かすための「機構（ハーネス）」ではなく、何が正しく何が誤りかを示す「判断基準」の蓄積だった。

AIエージェントは「モデル」と、それを取り囲む「機構（ハーネス）」で構成される（Agent = Model + Harness）。2026年に入り、ハーネスエンジニアリングという概念が急速に普及したが、多くの議論は「いかにAIの暴走を防ぐか」というガードレール（禁止事項）に偏りがちだ。しかし、メルカリNFTチームは、正解の提示、結果の観測、危険の抑止という3つの役割を等しく支えるためには、汎用的な機構を自作するのではなく、プラットフォームが提供する既製品（Claude Codeのhooksやサンドボックスなど）を賢く使い、その上で動く「判断基準」を自前で徹底的に研ぎ澄ますべきだと見抜いた。

なぜなら、機構の寿命は短い。モデルが進化すれば、昨日まで必要だった複雑なハーネスは一瞬で不要になる。しかし、「このプロダクトにおいて何が正しい設計か」という判断基準は、モデルの世代を超えて生き続ける。彼らは、UPSERTを禁止し、Read後にINSERT/UPDATEに分岐させるという具体的なコーディング規約から、命名規則の統一にいたるまで、判断基準をリポジトリに可搬な形で残すことに心血を注いだ。これこそが、AIに自走力を与える唯一の道であると私は確信する。

「なぜこの仕様になったのか、誰も覚えていない」――。ドキュメントの墓場と化したNotionやWikiを前に、途方に暮れた経験のないエンジニアなど存在しないだろう。人間ですら迷子になる仕様の迷宮にAIを放り込めば、AIは文脈を誤認し、幻覚（ハルシネーション）に満ちたコードを量産し始める。

メルカリNFTチームが導入した「RDR（Requirements Decision Records：要求意思決定記録）」と「ADR（Architecture Decision Records）」の分離運用は、この課題に対する極めてエレガントな回答だ。彼らは、仕様書（spec）には「現時点の仕様」のみを記述し、「なぜその仕様に至ったのか」「どの代替案を却下したのか」という意思決定のプロセスをRDRという独立したファイルに切り出した。

この分離は、AIに渡すコンテキスト（Context）のノイズを劇的に削減する。AIがコードを生成する際、過去の泥臭い議論や却下されたアイデアは不要なノイズでしかない。AIには「現在の正解」だけを渡し、仕様を変更する局面に限って、関連するRDRを引きに行かせる。このコンテキスト制御の思想は、大規模言語モデル（LLM）のトークン制限や推論精度を最適化する上で、極めて実戦的なアプローチだ。

さらに、彼らはドキュメントの「信頼の唯一のソース（Single Source of Truth）」をGitに固定した。Notionはあくまで「読む場所」「コメントを付箋のように貼る場所」と割り切り、マージされたGitのドキュメントをNotionに自動同期するパイプラインを構築した。これにより、非エンジニアであるPdMやデザイナーは使い慣れたNotionでレビューに参加でき、エンジニアはGitによる厳密なバージョン管理の恩恵を享受できる。メルカリが全社展開を進める「Claude Code」や、シャドーAI対策を支える強固なガバナンス体制の裏には、こうした「ツールごとの役割の徹底的な整理」がある。

AIに開発を任せる上で、最大のボトルネックとなるのが「テスト」だ。AIにブラウザを直接操作させてE2Eテストを実行させるアプローチは一見魅力的だが、私はこれに強い技術的懸念を抱かざるを得ない。なぜなら、AIの推論には常に「ゆらぎ」が伴うからだ。テストを実行するたびにAIの解釈が変わり、テスト結果がパスしたり失敗したりするようでは、CI/CDパイプラインは崩壊し、デプロイのたびに無限ループのような不確実性に悩まされることになる。

メルカリNFTチームはこの罠を回避するため、極めて確実な境界線を引いた。テストの「定義（シナリオ作成）」にはAIの創造性を活用するが、テストの「実行」からはAIを完全に排除し、Playwrightを用いた「決定論的（デターミニスティック）なスクリプト」に落とし込んだのだ。これにより、テストは「同じ入力に対して常に同じ出力を返す」という本来の信頼性を取り戻す。CI環境でもローカル環境でも、テストの失敗はAIの気まぐれではなく、プロダクトのコードに「本物のバグ」が混入したことを意味するようになる。

また、AIにコミットやPR作成、Jiraチケットの起票までを自律的に行わせる中で、避けて通れないのが個人情報（PII）の漏洩リスクだ。彼らはこれを「Pre-commit hooksでの検知」「CIでのスキャン」「漏洩時の自動復旧手順」という三段構えの多層防御で解決した。さらに、AIがレビューコメントなどで個人情報を引用する際は、先頭の数文字だけを残して自動マスキングするルールを徹底している。

1月末に開発チームを一度解散し、エンジニア2人、PM1人、デザイナー1人という極小体制に移行したにもかかわらず、チーム全体のPR流量が増加し、かつ修正系PRの割合が低く抑えられているという定量的な成果は、この「決定論的テスト」と「多層防御」がもたらした圧倒的な安心感の証明にほかならない。

メルカリが全社を挙げて推進するAI変革は、仕事効率「1.9倍」という驚異的な数値を叩き出している。しかし、我々エンジニアが直面している本質的な問いは、生産性の向上そのものではない。AIがコードを書き、テストを定義し、デプロイまでを自律的に行う「AI-Native」な世界において、人間のエンジニアの存在価値はどこにあるのか、という痛烈な問いだ。

メルカリNFTチームの挑戦は、その答えの輪郭を鮮明に描き出している。彼らは「コードを書く作業」をAIに委ね、人間は「判断基準（ルール、ADR、RDR、レビュー観点）」を言語化し、システムに注入する役割へとシフトした。これは、従来の「プログラマー」から「価値基準の設計者」への越境を意味する。

メルカリが実践した「やさしいメル﨑」の事例に見られるように、ファクトとデータは事業側が持ち、絵作りはクリエイティブパートナーが担うという、AIを介した「共創」の形は、エンジニアリングの現場にもそのまま適用される。エンジニアはもはや、コードのシンタックスに悩む必要はない。代わりに、ビジネス要件をいかに厳密な「判断基準」としてAIに解釈可能な形で記述できるか、という超高度な抽象化能力が求められるのだ。

明日から我々が取るべき具体的な処方箋は明確だ。自らのリポジトリに、特定のAIツールに依存しない「可搬なルールファイル（CLAUDE.mdなど）」を今すぐ作成し、チーム固有の設計思想や「なぜこの技術を選んだのか」という判断の歴史を言語化し始めることだ。

AIに仕事を奪われることを恐れるな。むしろ、AIを最も優秀な「ジュニアエンジニア」として使い倒すための「冷徹なメンター」になれ。我々は、コードの書き手であり続けるのか、それともシステムの意思決定者へと進化するのか。その決断の刻限は、すでに迫っている。