メルカリが挑む“AIネイティブ”な組織とプロダクト開発の裏側【Config 現地レポ#2】

世界中のデザイナーやエンジニアが集うサンフランシスコの一大テックイベント「Config2026」。このイベントに日本企業として唯一登壇を果たしたのが、フリマアプリ「メルカリ」を運営する株式会社メルカリだ。AIを活用したチームビルディングのメソッドを伝授した。

本記事では、メルカリのセッションレポートに加え、登壇したアルカティブ アブドゥラ（以下、Aki）氏と成田元輝氏への現地インタビューをお届けする。

満員の会場の中、セッションはメルカリの山本真人氏の言葉から始まった。

私たちが「AI-Native（エーアイ ネイティブ）」と言うとき、それは組織にツールとしてAIを導入することを意味するのではありません。私たちは文字どおり、すべてをAIネイティブに再構築しようとしています。たとえば、従業員のAIを使った働き方を変え、組織構造全体を変えます（山本氏）

では、すべてをAI前提で再構築する「AI-Native」へと、どのように変革を遂げていったのだろうか。その具体的なステップと現場での実践について、Aki氏と成田氏によって詳細に解説された。

コードの民主化と「デザインシステム」の役割の変化

AIの劇的な進化により、エンジニアやデザイナーに限らず、誰もがプロトタイプを作れる時代になった。しかし、誰でも作れるようになったからこそ、ブランドの一貫性を守る強固な基盤としての「デザインシステム^※」がこれまで以上に不可欠となったのだ。

メルカリではFigmaと実際のコードを直接つなぐCode Connectを活用し、AIがデザインを読み取った際に、本番環境でそのまま使える一貫したコードを生成する仕組みを採用している。

Code Connectは私たちにとってゲームチェンジャーでした。導入以前は、多くのプロトタイピングツールを試していましたが、一貫性を保つための分析・検証作業が必要で、必ずしもプロトタイプから実際のフロントエンド（コード）を生成してくれるものではありませんでした。

私たちはコードベースとキャンバス上のコンポーネントを接続できるツールを取り入れたかったのです。そして、Code Connectのおかげで、適切なプロトタイプを構築できるようになりました（成田氏）

人間とAIの双方にとってのベストプラクティス

AIと共にプロダクト開発を進めるうえで、メルカリでは人間とAIそれぞれに合わせた次のようなアプローチをとっている。

• 暗黙知の明示化：
  人間なら当然に理解している「このコンポーネントは重ねて配置しない」といったコンテキストやブランドボイスを、明確なルール（Do / Don't）として言語化・データ化してAIに学ばせている。

• 柔軟性と制限の使い分け：
  表現力を発揮させたい人間には自由度の高い要素を提供する一方、暴走しやすいAIにはあらかじめ定義されたレイアウトテンプレートを与えるなど、主体に応じた制御を行っている。

• AIのためのドキュメントをAIが生成：
  AIがコンポーネントのコードを解析・学習し、自らStorybook風のHTMLドキュメントを書き上げる独自の「スキル」を開発・運用している。

AIに自由を与えすぎると、ときどき“台本”から外れてしまいます。メルカリのデザインとはまったく似ていない新しいコンポーネントを作り始めたりします。ですから、AIにはより多くのレイアウトを与える必要があります。

一方で、人間に対してはそれほど制限したくありません。デザイナーがよりクリエイティブになれるチャンスを与えたいのです（Aki氏）

「直線的な開発」から「ループ型開発」へ

以前はメルカリでも「デザイナーがビジョンを作成→エンジニアが実装」という直線的で一方通行の（ウォーターフォール型）開発プロセスだった。しかしAIの登場により、エンジニアが自らAIでプロトタイプを作り、デザイナーがそれをブラッシュアップするといった循環（ループ）型の開発へと移行がはじまっている。

役割の境目が曖昧になるなかで、メルカリではデザイナーとエンジニアが互いの基礎知識、たとえばエンジニアからはGitHubの扱い方、デザイナーからはデザインのレイヤー構造などを学び合う相互教育を実施している。

コードを作るコストが下がった今、最大のボトルネックは「実装」から「判断」、つまり何がメルカリらしい成果物なのかを言語化し、評価することへと移行しているという。

【現地インタビュー】世界のテック企業が注目する、メルカリのデザインシステムとAI活用

セッション終了後、Aki氏と成田氏にインタビューをした。

――Figmaを使い始めたのはいつからですか？

Aki氏： 2018年ごろ、メルカリの米国法人であるMercari, Inc.で最初に導入して、その後日本にも導入しました。当時はSketchを利用していたのですが、2020年か2021年頃には全社的にFigmaに移行しましたね。自分のローカルにファイルを保存して、チームメイトにデザインを渡すときは、まずGoogleドライブにアップして、ダウンロードして、手戻りがないよう確認して……という手順がなくなりました。これは大きな変化でした。現在は同じデザインファイルを、100人ほどで共同作業できる形で運用しています。

――だからこそデザインシステムは重要なのですね。今回の登壇はどんな経緯で実現したのですか？

Aki氏： Figmaが主催するデザインシステムに特化したカンファレンス「Design Systems with Figma: Tokyo」が日本で開催され、そのイベントに登壇したとき想像以上の反響をいただき、今回の登壇もお声がけいただきました。前回の登壇後も多くの日本企業から相談が寄せられましたが、今回の登壇をSNSで発信したところ、早くも海外企業からDMで質問が届いています（笑）。デザインシステムの活用は、特に日本ではまだ一般的でなく、どの企業も迷っているんですよね。しかもAI 活用が進むなかで、ブランドデザインを守ることが以前より難しく、かつ重要になっています。メルカリが「プリンシプル」（原則）に沿ったデザインシステムをどう構築してきたか、どうメンテナンスしているかなどを知りたい方が多いようです。

――「プリンシプル」とはどのようなものですか？

Aki氏： デザインシステムの中にスペックファイルがあって、各コンポーネントの使い方やルールが書いてあります。たとえば、「ワン画面、ワンアクション」の原則などです。メルカリのコーポレートカラーの赤ボタンは、1つの画面に1つしか置かない。だからユーザーが迷わないで済む。そういった原則をチームで守っています。

――それはAkiさんが全部書いているんですか？

Aki氏： いいえ。今はClaude Codeのスキルを作って、自動でAIが書いてくれます。「AIが過去のコンポーネントのコードを自分で解析・学習してAIエキスパートになり、その視点からルールを作ってくれる」と紹介した部分です。「do／don't」まで AI が書いてくれるんですよ。

――それはすごい進化ですよね。

成田氏： 以前は「このボタンはこう使う」と人間が書かないといけなかったのが、今は生成AIに委ねられます。スペックや使用方法だけではなく、AIによってチーム全体で自然と業務変革ができるようになったのが我々の強みです。Figmaで「チェックデザイン^※」が出る前に、自分たちで作っていました。そうしたアイデアが出る理由は、やはりコラボレーションの力ですね。同じFigmaのキャンバス上で会話ができる、議論ができるという点が、エンジニアとデザイナーの距離を縮めているんじゃないかと思います。

――今回アメリカで登壇してみて、反応はいかがでしたか？

成田氏： 参加者に共感いただいているところは多いのかなと感じました。みんな、うちと同じようなチャレンジをして、同じような心配をしておられるのでしょう。ただ僕らのほうが少し早めにチャレンジをしてきて、チームができてはなくなったりして、今何代目かのデザインシステムチームで協業しているという経験があります。そこで得た気づき、教訓を共有できたのかなと。

――Figma活用のファーストペンギンとして、次に期待する機能は？

成田氏： キーノートの中で「コードをデザイン素材の1つとして扱うことで、ビジュアルデザインと制作の間のギャップを埋める」という話が出ましたが、やはり私たちにとってはコードこそが最終成果物です。今のように中間成果物であるデザインファイルをコードに反映する機能だけでなく、最終成果物であるコードのほうを「Source of Truth（唯一の出典）」として、デザインファイルを構築できる機能ができてくれたらなと、よく話しています。

Aki氏： メルカリの画面はおそらく200〜300ぐらいあるので、Figmaでマスターファイルを管理するのも結構大変なのです。それに、だいたいみんな作ったものをマスターに格納するのを忘れることが多くて（笑）。だからコードからデザインを生成する機能にとどまらず、Figmaと実際のコードをデータ連動させ、プロダクト全体を俯瞰できる環境を望んでいます。そうすれば、Figma上でマスターファイルを管理する手間もなくなります。ただ、キーノートのデモを見ていたら、多分、もうちょっとで実現できるのでは？と感じました。期待しています。