タイトルのとおり、正解のない時代に AI-Native を選ぶにあたってメルカリが選んだ指針を述べるこの記事は、メルカリ の CTO が同社のエンジニアリングイベント mercari GEARS 2025 で行った基調講演を文章にしたものである。記事は、同社が AI-Native Company と呼ぶもの(社長の言葉として引用される、プロダクト、働き方、組織を AI を中心に作り直すという目標)に、エンジニアリング部門だけでなく会社全体でどのように近づいていくつもりかを示している。著者はこれらの指針を暫定的なものとして提示している。AI による生産性向上はまだ非常に不確実だとされ、記事自身も、新しい技術が現れるにつれて内容の更新が必要になると見込んでいる。
記事の主張は 3 つの部分からなる。AI-Native な仕事のための同社の前提条件はナレッジマネジメントである。エージェントにはコンテキスト、とりわけ意思決定の履歴が必要だが、それが現在は複数のツールに散らばっているからである。開発においては、その手段は Agent-Spec 駆動開発(ASDD)である。開発以外では、AI Task Force が会社の残りのワークフローを転換しつつある。法務、セキュリティ、コンプライアンスのチェックが依然として人を待っているのであれば、コーディングが速くなるだけではリリースは速くならない、という理由からである。
要点
- 記事によれば、メルカリの従業員の 95% が AI ツールを使い、コード生成の約 70% を AI が占め、開発スピードは前年比で 64% 向上した。それでも同社は自らをまだ AI-Native だとは考えていないと述べている。コーディングの生産性だけでは組織全体の生産性は上がらないからである。
- 記事の中心的な捉え直しは、人間の限界を中心に仕事を設計することから、AI を中心に仕事を設計することへの転換である。1 日 8 時間、8 人のチーム、週次の会議といった規範は、人間の時間、注意、能力に合わせて最適化されたものだと説明されている。記事は、知見としてではなく可能性として、1 人が複数の役割を担えるならより小さなチームのほうが多くを達成できるかもしれないこと、AI が定型作業を取り除くなら、より短く集中度の高い労働時間のほうが生産的になりうることを示唆している。新しい仕事はむしろ、提供すべき価値から逆算して設計されるべきだとしている。
- 記事は、AI コーディングアシスタントによる生産性向上が当初は期待外れだった原因を、欠けていた前提条件、すなわちコンテキストに帰している。コーディングについては、マイクロサービスの依存関係、コーディング規約、設計ドキュメント、関連する作業の過去の意思決定ログ、コードレビューでの議論を特に有用なコンテキストとして挙げている。そして、意思決定に関する情報(プロジェクトの狙い、何が許容され何が許容されないか、過去の議論で何が優先されたか)を最も重要なコンテキストの一つとし、しかもそれは、議論が Slack、GitHub、議事録に散らばっていて、整理されていないことが多い種類のコンテキストだとしている。
- 情報を記事が言うところの「AI-Readable」にするため、同社は情報を中央のナレッジベースとして Notion に集約し、AI が生成する議事録の標準化を含め、情報の記録方法を再設計している。
- 記事によれば、ASDD 以前、AI コーディングアシスタントは広く使われていたものの、その使い方にはばらつきがあった。プロンプトの質は人によって異なり、適切なコンテキストを集めるのは難しく、生成されるコードの質はまちまちで、エンジニアはそれぞれ異なるツールを使っていた(当初は Cursor が全社に展開され、その後 Claude Code のような新しいアシスタントが登場した)ため、ベストプラクティスを集約することが難しかった。記事はこの 4 つすべてを、AI の使い方に関する共通のレギュレーションがなかったことに起因するとしている。
- ASDD は開発の柱として提示されており、生産性を倍にするという目標にちなんで名づけられた Double プロジェクトの中で進められている。記事はこれを、API 定義、データモデル、データベーススキーマ、処理フロー、テストシナリオ、具体的な実装手順、サービス間の依存関係を定める、AI フレンドリーで実装志向の仕様テンプレートと説明しており、エージェントを使う人が誰であっても同じ品質と規約で実装できるようにするものだとしている。記事は、ASDD の品質は Agent Spec を書く際に与えるコンテキストの質に大きく左右されると強調している。また、このプロジェクトに関するメルカリの記事を引用し、一方のエージェントが一次情報から実装計画を起草し、もう一方のエージェントがそれをコーディング規約とセキュリティ基準に照らしてチェックし、残った不確実な点が開発者に問われるまで両者が交互に作業する様子を紹介している。
- 同じ Agent Spec は、開発(バックエンド、フロントエンド、モバイル)全体にわたるエージェント、さらには開発以外のエージェント(QA のテストケース生成、AI レビュー、カスタマーサポートのための仕様調査、リスク管理、コンプライアンスチェック)の基盤になると説明されている。また、同社の社内デザインシステムを使う UI 生成エージェントである PJ Aurora の仕様にもなっており、生成された UI をデザインルールに照らしてチェックするエージェントも併せて使われている。
- AI Task Force は 2025 年 7 月に始動し、会社を 33 のドメインに分け、各ドメインに 1〜2 名のエンジニアと 1〜2 名のプロジェクトマネージャー、さらにドメインオーナーを割り当て、約 100 名の規模にまで拡大した。エンジニアは、AI の分野だけからではなく、意図的に多様な分野から集められた。執筆時点までに、33 のドメインすべての業務(約 4,000 のワークフロー)を棚卸ししてロードマップを策定し、それらのためのエージェント開発に入りつつあった。
- Task Force が報告している教訓は次のとおりである。法務や財務といったコーポレート部門の中で作業したエンジニアが冗長な作業を見つけ、場合によっては業務そのものを不要にできる可能性を示したこと。不確実性の高い状況で優先順位を決めることは、一部のドメインでは難しく時間がかかったこと。そして、33 のドメインを独立して運営したことで意思決定は速くなったが、ベストプラクティスや振り返りがドメイン間で十分に共有されなかったこと。
背景
この記事は、同社自身の技術リーダーシップによる方針表明であり、その数値は同社自身のものである。記事は AI-Native を、顧客に届ける価値により多くの時間を使えるよう人々を解放するという、同社の顧客中心の価値観の延長として位置づけ、同社の海外展開とも結びつけて、エージェントによって現実的な人員規模で新しい市場に対応できるようになりうると論じている。
記事は、AI をめぐるセキュリティ、ガバナンス、コンプライアンスを、翌年にかけて重要性が増すと見込むテーマとして挙げているが、ここではそれらにほとんど踏み込んでいない。