2025/12/25

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

Author:: kimurashunya

, 2025/12/25

こんにちは、メルカリ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が前提となる世界では、この出発点が根本的に変わります。

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

すなわち、

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

という問いからスタートし、その実現のためにAIをワークフローへ組み込み、最適な仕組み・チーム構成・役割・データのあり方などを再設計していくという考え方です。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がこうした背景を理解しているかどうかで、アウトプットの品質は大きく変わります。適切な意思決定コンテクストが提供されれば、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に与えられないことが多く発生しました。

生成コード品質のばらつき

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

使用ツールのばらつき

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

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

目指す開発プロセス

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

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

コーディングだけでなく、スペック作成、デザイン、コードレビュー、QA／テストなど、あらゆる工程でAI Agentが活用され、開発全体が最適化されていること
各プロセスに必要なコンテクストが適切に整理・提供され、AI Agentが効率よくタスクを遂行できること
前述の課題が解消され、統一された開発プロセスとして標準化され、すべてのエンジニアが安定してAgentic Codingを実践できること

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

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

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

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

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

API定義
データモデル
DBスキーマ
処理フロー
テストシナリオ
具体的な実装手順（TODO）
マイクロサービス間の依存関係

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

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

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

ASDDの活用範囲

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

開発領域:

バックエンド開発
フロントエンド開発
モバイル開発

品質保証:

QAのテストケース自動生成
AI Review

その他の領域:

カスタマーサポートのスペック調査
リスクマネジメント
コンプライアンスチェック

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活用によるプロセス改善についてお話ししてきました。これにより、プランニングからコーディング、リリースに至るまでのスピード向上が期待できます。

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

リーガルレビュー
PRレビュー
セキュリティレビュー
コンプライアンスチェック

究極的には、全社レベルでのプロダクティビティが向上しなければ、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はプロダクト開発を主に担い、リーガルやファイナンスといったコーポレート領域の業務に深く関わることは多くありません。しかし今回、そうした領域にエンジニアが入り込み、業務の棚卸しを行ったことで、次のような成果が生まれました。

エンジニアのフレッシュな視点により、現場では当たり前になっていた冗長な業務に対して、効率化のアイデアを提示できた
場合によっては、その業務自体を根本的に不要にできる可能性を示すことができた
エンジニア自身にとっても、これまでにない経験となり、新しいチャレンジへのモチベーションにつながった

このように、ロールを越えた協働は、業務改善だけでなく、人の成長や組織の活性化にも大きく寄与したと感じています。

不確実性との向き合い方

AI Task Forceでは、各領域ごとに業務の棚卸しを行い、AI-Native化に向けたビジョンやロードマップを策定してきました。しかし、無数に存在するタスクの中から大きな方針を定め、優先順位を決めることは決して簡単ではありません。実際、領域によっては、この意思決定に大きく悩み、時間を要したケースもありました。

別のADVENT CALENDAR記事の中で、@panoramaさんは次のように述べています。

しかし最終的には
「誰も正解がわからない。でも、手探りで失敗を繰り返したとしても進める価値がある」
のがAI-Native化だと考え直しました。

(参考: AI Task Forceで学んだ「不確実性との向き合い方」)

私自身、メンバーに苦労をかけてしまったのではないかと反省する気持ちもあります。一方で、たとえ時間がかかったとしても、この不確実性と真正面から向き合い、じっくり考えて答えを出すプロセスを経たことが、AIを単なるツールとして導入するのではなく、働き方そのものを見直すきっかけになったと信じています。

AI Task Forceをリードする立場として、私自身も不安を感じる場面は多くありましたが、悩みや不安を抱えながらも前に進んでくれたメンバーを、心から誇りに思っています。AI Task Forceのように不確実性の高いプロジェクトを進めることは容易ではありません。これから同様の取り組みを始める方には、ぜひ先ほどの記事も参考にしていただければと思います。

情報共有の難しさ

今回、33の領域をそれぞれ独立して進めたことで、各領域において迅速な意思決定が可能になった一方、反省点もありました。それは、各領域で得られたベストプラクティスやレトロスペクティブを、十分に共有できなかった点です。

33領域すべてで定例ミーティングを行うのは現実的ではありませんが、もし領域間でスムーズに知見を共有できる仕組みがあれば、全体の効率はさらに高められたはずです。各領域のロードマップが出揃った今だからこそ、進捗や学びをよりオープンに共有し、全社としてより洗練された進め方を模索していきたいと考えています。

同時に、この「情報共有の難しさ」もまた、Agentベースのアプローチによって効果的に解決できる課題の一つだと捉えています。

(参考: 【メルカリ本気の全社AI化】100人で2000人を改革するAIタスクフォースの全貌 / すべての仕事をAI-Native化 / 鍵は)

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

メルカリのミッションと現在地

ここまで、私たちはAI Task Forceを通じて全社のあらゆる業務をAI-Native化する取り組みを進めていること、そして並行して、特に開発プロセスにおいてはASDDを軸にしたAgent化を推進していることをお話ししてきました。では、このようにすべてをAI-Nativeへと進化させた先に、私たちは何を目指しているのでしょうか。

メルカリは、「あらゆる価値を循環させ、あらゆる人の可能性を広げる」というミッションのもと、マーケットプレイス、フィンテックサービス、そして新たな事業を展開してきました。そしてこのミッションを真に実現するために、私たちにはまだ取り組むべきことが数多く残されています。

世界展開への道

近年、メルカリは国際展開を本格的に進めており、台湾をはじめ、香港でのサービス提供も開始しました。私たちはマーケットプレイスを世界へと広げることで、より多くのモノの価値を循環させ、世界中の人々の可能性を広げていくというビジョンを掲げ、着実に国際展開の基盤を築いてきました。一方で、実際にサービスをグローバルに展開しようとすると、どれだけスケーラブルな仕組みを構築したとしても、各国ごとのローカライズ対応や日々の運用を考えたとき、現在の社員数のままでは限界があるという課題意識も持っていました。

しかし、これまでに述べてきたように、AI Agentを最大限に活用し、一人ひとりの生産性や能力を拡張できれば、現実的な人数で世界展開を本当に実現することも決して夢ではないと、今では考えています。

これはマーケットプレイスに限った話ではありません。フィンテック領域においても、グローバルに展開される金融サービスを提供し、私たち独自の与信モデルを世界に広げていくことで、世界中の人々の可能性をさらに広げられるはずだと考えています。

@deeeetさんの記事にもあるとおり、現在メルカリでは、国際展開におけるサービスリリースと並行して、基盤開発にも非常に力を入れています。AI-Native化を進めるうえで、このようなアーキテクチャ整備を同時に行うことは、AI前提の開発プロセスをより効率的かつ持続可能なものにするために極めて重要です。

先日の事業戦略発表会において共有しましたが，今後更にメルカリの海外展開を加速させるためにグローバル版のメルカリアプリを先日リリースしました．このアプリは現在提供してる日本版・アメリカ版のメルカリとは異なる新しいアプリであり，またアプリだけではなくその裏側のバックエンド基盤も新たに再構築しています．

(参考: グローバル展開にむけたアプリと基盤の再構築)

新たな価値の創造

そして、世界中の人々の可能性をさらに広げていくためには、既存のサービスにとどまらず、これまでにない新たな価値を提供するサービスを生み出し続ける必要があります。

これまでは、新規プロジェクトや新規事業を立ち上げる際、まず人的リソースが大きな制約となり、構想段階で断念せざるを得ないケースも少なくありませんでした。しかしこれからは、そうした前提となっていた限界を一度手放し、「実現したい価値」から発想し、次々と形にしていける世界へと変わっていくと考えています。

その中で、新しい事業づくりにおけるAI Agent の活用は、今後ますます重要なテーマになります。すでに私たちは、並行してさまざまな実験的な取り組みを進めていますが、その成果については、来年のメイントピックとして改めてお伝えしたいと思います。ぜひ楽しみにしていてください。

Customer-Centricの究極形

そして、先ほども触れたとおり、AI-Centricな組織を築いていくことで、私たちはより多くの時間とエネルギーを、「お客さまに提供したい本質的な価値」に向けられるようになります。これは単なる効率化ではなく、Customer-Centricをさらに突き詰めていくための進化だと考えています。

AIを前提に、より深くお客さまの価値に向き合う。それこそが、私たちが目指す「AI-Native Company」の姿です。

今後に向けて

メルカリでは、AI-Native Companyを目指すことを全社方針として明確に打ち出しました。その取り組みの中核として、ASDDを中心にAI Agentを前提とした開発プロセスの再構築を進めています。さらに、開発領域にとどまらず、全社のあらゆる業務をAI-Native化していくために AI Task Forceを立ち上げ、組織横断での変革にも着手しました。

これらの取り組みは、まだ始まったばかりで道半ばです。しかし、不確実性と向き合いながらも一歩ずつ前進することで、人がより本質的な価値創出に集中できる組織を実現していきたいと考えています。

これは私たちに限った話ではなく、社会全体としてもAI-Native化は確実に進みつつあります。すでに多くの業務をAI Agent化している方も多いでしょう。一方で、会社の規模が大きくなるほど、全社的にAIを本質的に浸透させる難易度は高まると、個人的には感じています。だからこそ、来年は社会にとって「AI Agentをいかに本質的に定着させるか」が問われる一年になると考えています。

私たち自身も現在、AI Agentを効果的に活用するための実験を日々重ねていますが、来年はそれを一部の取り組みにとどめず、より広く、より深く浸透させていくフェーズに入ります。すでに始まってはいますが、改めて「AI-Native、すなわちAgentベースでまずプロセスを考える」という姿勢を、組織全体で言い続け、実践し続ける一年にしていきたいと思います。

また、本稿では十分に触れられませんでしたが、来年はAIに関わるセキュリティ、ガバナンス、コンプライアンスも、より重要なテーマになっていくでしょう。これらは、AIを安全かつ持続的に活用し、全社に浸透させていくうえで欠かせない要素です。

今後も、メルカリにおけるAI-Native化の進捗については、継続的に発信していきたいと考えています。最後までお読みいただき、ありがとうございました。そして今年も大変お世話になりました。どうぞ良いお年をお迎えください。

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

目次