AIネイティブという選択肢 ― 正解のない時代におけるメルカリの指針

AI-Nativeという選択 ー 正解のない時代に、メルカリが選んだ指針

こんにちは、メルカリCTOの木村(@kimuras)です。今年は、ついに開催されたメルカリ主催のエンジニアイベント「mercari GEARS 2025」にて、Keynoteを担当しました。本記事では、その内容を改めて文章としてまとめ、皆さんにお伝えしたいと思います。メルカリがAI-Native Companyになることを宣言して以来、エンジニアリング組織に限らず、全社としてどのようにAI-Native化を進めていくのか、その指針についてお話しします。

ご存じのとおり、AI活用による生産性向上は、まだまだ不確実性の高い領域です。さらに新たな技術が次々と登場することで、今日述べる内容も、近い将来には更新が必要になるかもしれません。しかし、だからこそ「現時点で我々がどこを目指し、どのような方向性で進んでいるのか」を言語化し、共有しておくことは、この変革期において非常に重要だと考えています。

AI-Native化の推進は決して簡単ではありませんが、本記事の内容が、同じように挑戦されている皆様の一助になれば幸いです。

全社をあげたAI-Native化とは

現状: 確かな変化、しかし「まだ道半ば」

発想の転換:「人間前提」から「AI前提」へ

AI-Native化の前提条件:Knowledge Management

AI-Centricな開発:Agent-Spec Driven Development(ASDD)

全社的なAI化:AI Task Force

未来のビジョン:AI化の先にあるもの

全社をあげたAI-Native化

「プロダクト、仕事のやり方、組織すべてをAI中心に再構築し、AIの進化を最大限に活用することで、これまでにない成果を目指す」

(参考: 新年度のテーマは「Back to Startup」と「AI-Native」。12周年を迎えたメルカリが目指すこれからの姿 | mercan (メルカン))

これは、社長である山田からの強い決意表明でした。 AIへの対応が遅れれば、競争環境の中で後れを取るリスクは避けられません。同時に、私たち一人ひとりの成長においても、大きな変化が求められています。AIによる生産性向上は、従来の評価基準では実現が難しかった新たな価値創造を可能にします。変化を柔軟に受け入れ、成長し続けられる人にとって、これは自身の価値を飛躍的に引き上げる絶好の機会でもあります。

そして、AI-Nativeな働き方を全社に浸透させるということは、単にAIツールを一律に導入することではありません。これまでの働き方をゼロベースで見直し、業務そのものをAIを前提とした形へ抜本的に進化させていくことが重要だと考えています。

現状: 確かな変化、しかし「まだ道半ば」

メルカリではすでに、社員の95％がAIツールを活用し、コード生成の約70％をAIが担うまでに進化しています。開発スピードも前年比で64％向上しました。数字だけを見れば、AIは確実に浸透しているように思えるかもしれません。

しかし、私たちは現在の状態を"AI-Native"だとは捉えていません。むしろ、ここからこそ本当の変革が始まると考えています。

最近よく議論されているように、「本当に生産性は飛躍的に向上したのか？」という問いに対して、私自身もまだ改善の余地は大きく残っていると感じています。そして、コーディングの生産性が向上しただけでは、組織全体の生産性は十分には高まりません。同じくらい重要なのは、コーディング以外の業務プロセスも含めて、AI 前提の働き方に転換していくことです。

発想の転換:「人間前提」から「AI 前提」へ

前述のとおり、AI を前提とした働き方を実現するためには、単にツールを導入するだけでは不十分です。私たちは、仕事に対する考え方そのものを根本から塗り替える必要があると考えています。

これまで私たちが直面してきた限界は、「人が行うこと」を前提に組み立てられたプロセスや仕組みによって生じていました。AI-Native な働き方とは、そうした前提条件そのものを問い直し、業務を“人が実行するタスク”から“AI と人が最適に協働するタスク”へと再設計していくことにほかなりません。

これまでの仕事や組織のデザインは、多くが“人間前提”で設計されてきました。

つまり、人間の時間・集中力・処理能力といった制約を起点に、「その条件の中でどう成果を最大化するか」を軸に最適化されてきたのです。

たとえば、1 日 8 時間労働、週休 2 日、1 チーム 8 名構成、週次の定例会議、こうした組織の“当たり前”はすべて、人間の能力と限界を前提として形づくられてきました。現在も一般的な働き方であり、私たち自身もその枠組みの中で働いています。

しかし、AI を前提とした働き方とは本来どういう姿なのか。

そこを抜本的に考え直し、AI 活用を進めながら、これまでの常識を一つひとつ疑い、新しい標準をつくっていく必要があります。

1 人が複数ロールを効率的にこなせるようになれば、チームは 8 人よりも少ない人数のほうが、むしろ高い成果を出せるかもしれません。

AI によって単純作業が減り、人はより連続的で深い思考に集中できるようになると、脳の疲労はこれまで以上に高まる可能性があります。その場合、1 日 8 時間労働ではなく、短時間で高集中の働き方のほうが高い生産性を生み出すことも考えられます。

このように、AI 前提の働き方は、従来の“当たり前”を根本から再設計することを意味します。

では、AI を前提とした働き方とは、どのような発想の転換なのでしょうか。

これまで新たなプロジェクトや事業を立ち上げる際には、前述のような「人間の限界」を前提として設計するのが一般的でした。特に人的リソースは最も大きな制約であり、どれだけ人を確保できるかが計画の起点になっていました。

しかし、AI が前提となる世界では、この出発点が根本的に変わります。

仕事や組織のあり方を、“人の限界から逆算する”のではなく、ビジョンや提供したい価値から逆算して設計することが重要になります。

「何を実現し、どんな価値をお客さまに届けたいのか」

という問いからスタートし、その実現のために AI をワークフロー (workflow) へ組み込み、最適な仕組み・チーム構成・役割・データのあり方などを再設計していくという考え方です。AI はミッションを前進させる創造的なパートナーであり、チームの一員として存在します。

これこそが、私たちが目指す“AI-Native”の世界です。

AI-Native 化の前提条件：Knowledge Management

なぜ Knowledge Management が重要なのか

私たちも AI Coding Assistant をはじめ、さまざまな AI ツールを導入してきましたが、当初想定していたほど生産性が向上しないという課題がありました。

その背景には、AI 化を進める前に取り組むべき、より本質的な要素が欠けていたことがあります。それが、適切な情報、すなわちコンテクストの整備です。

特に AI Agent は、十分なコンテクストが与えられなければ期待どおりに機能しません。単純な指示だけでは精度の高い成果物を生成できず、手直しが何度も発生し、かえって時間がかかってしまうことすらあります。最終的には品質が低いアウトプットになってしまうケースも少なくありません。だからこそ、タスクに関わる背景知識、関連するレギュレーション（規則・規制）、過去の意思決定プロセスや議論のログなどをコンテクストとして適切に提供することが不可欠です。

そうすることで AI Agent は、状況や歴史的文脈、そして AI Agent 利用者が求めるゴールを正確に理解し、より期待に近い成果物を生成できるようになります。結果として、AI を効果的かつ継続的に活用できる環境が実現します。

どのようなコンテクストが必要か

必要となるコンテクストは、AI Agent に解かせたい課題によって大きく異なります。したがって、「この情報さえあればよい」という万能のテンプレートは存在しません。ただし、コーディングを例に挙げると、以下のような情報は特に有効です。

マイクロサービスの依存関係（Microservices の依存関係）

関連する開発における過去の意思決定ログ

これらのコンテクストを AI Agent に提供することで、依存関係を正しく考慮しながら、これまでの方針や意思決定と整合性のある設計やコード生成が可能になります。

最も重要なコンテクスト：意思決定情報

私たちが最も重要だと考えるコンテクストの一つが、意思決定情報です。

意思決定に関するコンテクストは本来きわめて重要ですが、実際には十分に整理されていないケースが多く見られます。Slack や GitHub、ミーティングメモなど複数のツールに議論が散在し、必要な情報を必要なときに取り出すことが困難になっているのが現状です。会議で決まった内容が適切に共有されず、後から意思決定の経緯をたどれない場合も少なくありません。

当社でも Design Doc にアーキテクチャや意思決定事項をまとめていますが、その判断に至るまでの議論は依然としてさまざまなツールに分散しています。その結果、「なぜその判断に至ったのか」という重要な背景が抜け落ちるリスクがあり、散在した情報を後から統合するには非常に大きな手間がかかります。

しかし、こうした意思決定情報はプロジェクトを適切に進めるうえで不可欠であり、AI Agent にとっても極めて重要なコンテクストです。AI Agent は、今後コーディングだけでなく、仕様書作成、デザイン、QA（品質保証）、リーガルチェック、セキュリティチェックなど、より広範な領域で活用されるようになります。その際に必要なのは、次のような情報です。

このプロジェクトの目的・狙いは何か

何が許容でき、何が許容できないのか

過去にどのような議論があり、何を重視して意思決定してきたのか

AI Agent がこうした背景を理解しているかどうかで、アウトプットの品質は大きく変わります。適切な意思決定コンテクスト（decision-making context）が提供されれば、AI Agent は状況を正確に把握し、より高品質で一貫性のある成果を生成できるようになります。

この後に紹介する AI Agent Spec Driven(ASDD) でも Spec を決定した議論を録音しておき、それをコンテクストとして Spec に提供することで、より高性能に AI Agent を活用できると紹介されています。

最初の Spec だけでは表現しきれていなかった背景やニュアンスが、レビュー時の対話には多く含まれています。この文字起こしログを Coding Agent に読ませて Spec を改善させることで、当初の記述では表現できていなかった文脈や設計の抜け漏れを補足し、より精度の高い Spec へと昇華させることができます。

(参考: Agent Spec で小さく素早く回すメルカリモバイル開発現場)

Knowledge Management への取り組み

現実には、こうした情報は十分に整理されておらず、多くが暗黙知のまま埋もれてしまっています。そこで私たちは、議論の記録や意思決定をできる限り構造化し、いつでもコンテクストとして活用できる状態にするため、Knowledge Management の強化に取り組んでいます。

AI を前提とした働き方をつくると同時に、情報管理のあり方そのものを抜本的に見直しているところです。これが実現すれば、トップダウンの意思決定と、現場からの学びや提案といったボトムアップの動きがよりスムーズにつながり、全社としての意思決定速度も大きく向上します。

こうした AI-Readable(本稿では、データが整備されており、AI エージェントが容易にコンテクストとして参照できる状態のデータを「AI-Readable」と定義します) なデータマネジメントを実現するため、私たちは現在、Notion に情報を極力集約する取り組みを進めています。

散在している情報を一つの文書管理基盤に集約し、必要なときにコンテクストを簡単に取り出せる状態にすること

情報の残し方そのものを再設計し、AI による議事録作成の標準化や、多様な情報資産の構造化などを通じて、AI が扱いやすいナレッジ体系をゼロから構築すること

これにより、人間にとっても AI Agent にとっても理解しやすく再利用しやすい組織の記憶をつくることを目指しています。

この方向性を元に、現在、メルカリは Notion を Central Knowledge Base として位置付け、ナレッジの中央管理型への移行を進めています。本記事の主旨と離れるので、細かくは記載しませんが、ツール選定に関しては、フロー情報（議事録など、メンテしない情報）とストック情報の両方に強いという点や、AI との親和性の高さが大きなポイントでした

(参考: メルカリが、AI 時代にナレッジマネジメントに投資したわけ)

AI-Centric な開発:Agent-Spec Driven Development(ASDD)

私たちはすでに、ほぼ 100％のエンジニアが AI Coding Assistant を活用しており、コード生成量も 60％以上増加しています。しかし、冒頭でも述べたように、これはあくまでスタート地点にすぎません。

本質的に AI を活用するためには、開発プロセス全体をゼロベースで見直し、AI を前提とした開発プロセスへと再構築する必要があります。AI Coding Assistant（AI コーディングアシスタント）の活用を進める中で、利用率は大きく向上したものの、以下のような課題が明らかになりました。

レギュレーションがないため、人によってプロンプトの質が大きく異なり、短時間で高品質なコードを生成できるケースがある一方、指示の反復が必要で、結果として AI なしより遅くなるケースもありました。

プロンプトの書き方を理解していても、必要なコンテクスト（文脈）を正確に収集できず、適切な情報量を AI に与えられないことが多く発生しました。

一部ではレビューしやすい高品質なコードが生成される一方で、品質が低くレビューが困難だったり、バグの温床になりやすいコードが出力されるケースも見られました。

当初は Cursor を全社導入しましたが、その後 Claude Code など新たな Coding Assistant（コーディングアシスタント）が登場し、エンジニアによって利用ツールが異なる状況が生まれました。そのため、ベストプラクティスを集約し、共有することが難しくなりました。

これらの課題の根底にあるのは、AI の使い方に関する共通レギュレーションが存在しないことです。そのため、チームや個人によってアウトプットの品質が大きくばらついてしまう状況が生まれていました。

私たちが目指す開発プロセスは、先に挙げた課題を解決したうえで、すべての開発プロセスに AI のポテンシャルが最大限活かされている状態です。

具体的には、次のような姿を想定しています。

コーディングだけでなく、スペック作成、デザイン、コードレビュー、QA／テストなど、あらゆる工程で AI Agent（AI エージェント）が活用され、開発全体が最適化されていること

各プロセスに必要なコンテクスト（文脈）が適切に整理・提供され、AI Agent（AI エージェント）が効率よくタスクを遂行できること

前述の課題が解消され、統一された開発プロセスとして標準化され、すべてのエンジニアが安定して Agentic Coding（自律型コーディング）を実践できること

これらを実現することで、特定のツールに依存しない、共通化された Agentic Coding（自律型コーディング）のワークフローが全エンジニアに浸透している状態をゴールとしています。

Double プロジェクト:ASDD の実現

私たちが現在進めているのが、Double プロジェクトにおける Agent-Spec Driven Development（ASDD：エージェント仕様駆動開発）です。「Double」という名称は、生産性を“2 倍にする”というプロジェクトの目的に由来しています。

ASDD は、AI Agent（AI エージェント）に必要なコンテクスト（文脈）を正しく与え、適切なプロンプトで誰でも開発を進められるようにするための、AI フレンドリーな仕様フォーマットを整備する取り組みです。

そしてこれは、単なる仕様書ではありません。AI Agent やエンジニアが実際にコードを書けるレベルまで落とし込むための、実装指向の設計書を作成するためのテンプレートです。抽象的なアーキテクチャ設計ではなく、既存のコードベースやプロジェクトの流儀に完全にフィットした形で、以下のような具体要素を明確に定義します。

必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等)は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

このテンプレートの目的は、「誰が・どのタスクを・どのファイルで・どのコードスタイルで実装するか」を明確にし、誰が AI Agent（人工知能エージェント）を使っても、同じ品質・同じ規約で実装できる状態をつくることです。言い換えれば、ASDD はチーム全体の実装プロセスを“再現可能な工程”にするための詳細仕様テンプレートです。

また、AI Agent が正確にコーディングできるよう、タスクの粒度を小さく保つなどの工夫もテンプレートに組み込んでいます。

(参考: Agent Spec で小さく素早く回すメルカリモバイル開発現場)

ASDD のポイントは、コーディングだけの Spec（仕様）ではないということです。この Spec は全プロセスで Agent をフルに活用するためのベースとなります。

カスタマーサポートのスペック調査

PJ Aurora: UI 自動生成

さらに、この Agent Spec は、UI（ユーザーインターフェース）を自動生成するための AI Agent の仕様としても活用されます。UI 向けの AI Agent は「PJ Aurora」というプロジェクトとして開発が進められています。

Aurora は、プロンプトを与えるだけで、内製のデザインシステムを活用しながら UI を自動生成できる、非常に先進的な取り組みです。デザインの一貫性を保ちつつ、UI 作成にかかる工数を大幅に削減できる点が大きな特徴です。

また本プロジェクトでは、生成された UI が社内のデザイン規約に準拠しているかを自動でチェックする AI Agent の開発も進行しています。これにより、Agentic なデザインプロセスによる効率化と品質担保の両立が期待されています。

(参考: PJ-Aurora が描く未来と、UI 品質評価を自動化するエージェント開発)

ここで改めて強調したい重要なポイントがあります。Agent Spec を作成する際に与えるコンテクスト（文脈）の質は、極めて重要です。ASDD の品質は、このコンテクストの品質に大きく依存しており、適切なコンテクストが与えられなければ、期待通りに機能しません。逆に言えば、質の高いコンテクストが整理・提供されてはじめて、ASDD は本来の効果を発揮します。

そのため、前述のとおり、このコンテクストを体系的に整備するための Knowledge Management（ナレッジマネジメント）プロジェクトも並行して進めています。これまでに作成された仕様書や意思決定の履歴、経営会議における意思決定情報などを整理・蓄積し、AI Agent にとっても人にとっても適切なコンテクストとして活用できる状態を整えています。

メルカリのナレッジ基盤に最適化されたエージェントが自動的に一次情報にアクセスし、詳細な実装計画を生成します。また別のエージェントが、実装計画がサービスのコーディング規約に沿っているか、計画が所定のセキュリティ観点をクリアしているかなどのさまざまな調査を行います。この 2 つのエージェントが交互に修正と評価を繰り返し、最後に要件や仕様における不確実要素が残った場合には、開発者に追加の質問を行います。このように、「AI のコンテキストに適切な一次情報を与える」ことをプロセスによって保証しました。

(参考: pj-double: メルカリの開発生産性向上に向けた挑戦 — AI-Native 化が辿り着いた ASDD とプロセス変革の全貌)

ASDD がもたらす価値 (Customer-Centric を極める)

ASDD の本質的なポイントは、いわゆる直感的な Vibe Coding ではなく、Agentic なアプローチによって、誰でも再現性のある開発レギュレーションを実現できることにあります。私たちは社内に蓄積されたベストプラクティスを継続的に収集し、この Agent Spec を育て続けることで、AI Agent のポテンシャルを最大限に引き出し続けられる開発環境を構築していきたいと考えています。

これが実現すれば、エンジニアに限らず、すべての開発に関わるメンバーが次のような状態を手に入れることができます。

より多くのタスクをこなせるようになる

Trial & Error を高速に回せるようになる

解決が難しいデザインや設計に、より多くの時間を使えるようになる

お客さまに提供すべき新しい価値について、深く考える時間を確保できるようになる

これまで私たちは「AI-Centric」という表現を使ってきましたが、人がよりお客さまの価値に集中できるようになるという意味において、これは本来私たちが大切にしてきた Customer-Centric の究極の形であると、私は考えています。

全社的な AI 化:AI Task Force

開発プロセス以外にも最適化の必要性

ここまでは主に、開発プロセスを中心とした AI Agent 活用によるプロセス改善についてお話ししてきました。これにより、プランニングからコーディング、リリースに至るまでのスピード向上が期待できます。

しかし、実際のリリースまでを見渡すと、開発以外にも複数のプロセスが存在します。全体最適ができていなければ、どこかで必ず待ちが発生し、結果としてリリース全体のスピードは改善しません。その代表例が、開発プロセスに付随して発生する関連チームによる各種チェックプロセスです。例えば当社では、プロジェクトの内容に応じて、リリース前に以下のような確認を行い、新しく開発したサービスの安全性や品質を担保しています。

究極的には、全社レベルでのプロダクティビティが向上しなければ、AI を活用してもリリース速度は頭打ちになります。そのため、開発プロセスに限らず、全社のあらゆるワークフローを Agentic なワークフローへと進化させていく必要があります。

理想的には、ASDD の Spec を活用し、これらの関連ワークフローについても AI Agent が並列に処理を担うことで、大きなボトルネックを生むことなく、高速なリリースを実現できる状態です。その実現に向けて、私たちはコーディング以外の業務にも目を向け、Agentic なワークフローを横断的に構築していかなければならないと考えています。

PJ Socrates:Agentic な働き方の先駆け

Agentic な開発を実現するうえで、その働き方の方向性をいち早く示してくれたのが PJ Socrates でした。Socrates は、いわば BI 領域の AI Agent であり、社内に存在するさまざまなデータの取得や分析を支援する役割を担っています。

これまで、施策のアイデア検討やビジネス戦略を考える際には、お客さまの動向や売れ行きなどを把握するために、DB 上の複数テーブルを Join した複雑なクエリを書く必要がありました。こうした作業には職人的な知識や経験が求められ、BI や Analytics チームのサポートなしにデータを取得することは難しいのが実情でした。Socrates の導入により、必要な分析内容を自然言語で AI Agent に依頼するだけで、データ取得から分析までを自動で行えるようになりました。

当時はまだ「AI Agent」という考え方自体が明確でなかったこともあり、この体験は社内に大きなインパクトをもたらしました。AI は単なるタスクの自動化にとどまらず、データを取得し、分析し、さらには示唆を提示するところまで担える。つまり、AI Agent は自動化だけでなく、意思決定を含む高度なタスクも遂行できる存在であることが、具体的に示されたのです。

そして、これまで人が担ってきたタスクを可能な限り AI Agent に委ね、人は本来より多くの時間を使うべき領域に集中していく。そのような働き方の方向性を、全社として実感する大きなきっかけとなりました。

(参考: AI/LLM が拓くデータ活用の新時代：人間とデータ分析 AI エージェントが協業する分析基盤へ)

AI Task Force の発足

この Agentic な働き方を全社で実現するために発足したのが、AI Task Force です。AI Task Force は 2025 年 7 月に活動を開始しました。

AI Task Force では、全社を 33 のドメインに分け、それぞれの領域のワークフローを AI 化することを目的に、各ドメインへエンジニア 1〜2 名、PjM 1〜2 名をアサインしました。さらに、各ドメインにはドメインオーナーを配置し、AI 導入に向けた方向性や方針に関する意思決定を担っています。

その結果、総勢約 100 名規模のメンバーが AI Task Force に参画する体制となりました。ここでアサインされたエンジニアは、必ずしも AI のバックグラウンドを持つ人材に限定していません。あえてさまざまな領域のエンジニアを各部署から選抜し、互いに学び合いながら進める形をとっています。AI Task Force 立ち上げ時の様子については、以下の記事でも紹介しています。記事中の写真からも分かるとおり、100 名規模となると相当な体制です。

活動開始当初は、AI-Native 化という不確実性の高いテーマに取り組むことから、目的や目標の明確化・文書化を重視し、全社および Task Force 向けに All Hands での説明会を高頻度で実施することを強く意識して進めてきました。

(参考: メルカリが本気で始めた「AI-Native」化。100 名規模のタスクフォースが立ち上がるまで | mercan (メルカン))

AI Task Force の 3 つの責務

前述の参照記事にも記載されているとおり、AI Task Force には大きく分けて 3 つの責務があります。

各ドメインにおけるすべての業務の棚卸し

棚卸し結果を踏まえた、将来の AI 化に向けたビジョンおよびロードマップの策定

ロードマップに基づく AI 化の実行

AI Task Force は 7 月に発足し、現在までに 33 のすべてのドメインにおける業務の棚卸しとロードマップ策定を完了しました。そして今まさに、各領域で AI Agent（人工知能エージェント）化に向けた具体的な開発フェーズに入っています。

33 領域を横断して業務を棚卸しした結果、定義されたワークフローの数は約 4,000 にものぼりました。もちろん、これらすべてを一律に AI 化するわけではありませんが、各ドメインで策定されたロードマップに基づき、中長期的な視点で段階的に AI 化を推進していく計画です。

AI Task Force からの学び

AI Task Force はまだ道半ばではありますが、ここまでの取り組みを通じて、すでに多くの学びを得ることができました。ここでは、その中でも特に重要だと感じているポイントを振り返ります。

今回の AI Task Force では、従来の役割分担を超えた取り組みが生まれました。通常、Software Engineer（ソフトウェアエンジニア）はプロダクト開発を主に担い、リーガルやファイナンスといったコーポレート領域の業