2025年5月、メルカリは全社で「AI-Native」な会社への転換を宣言しました。
その発信源は、グループCEOの山田進太郎（@suadd）によるSlackメッセージでした。

これは一部の部門や技術職だけの話ではなく、全社員に関わる話です。
私たちは「AIを導入する企業」ではなく、「AIを前提に再設計された組織」になります。

メッセージの投稿からわずか数週間で、社内から100名を超えるメンバーが選出され、「AI Task Force」という横断組織が立ち上がりました。中でもAI技術に精通した40名のエンジニアは、主務としてこの組織に異動しています。

この約100名が中心となり、全社の業務を棚卸し、AIを前提に再構築する取り組みをリードしていきます。

このスピードと規模感に、私たち自身も驚き、わくわくしているところです。本記事では、その「AI Task Force」のキックオフイベントをレポートします。

AI-Nativeに生まれ変わらなければならないのは、メルカリに限 った話ではありません。多くの企業にとって、これは避けられない宿命だと私たちは感じています。今回、私たちが得た気づきや学びが、少しでも皆さまの参考になれば幸いです。

@markが語った「ようやくAIにベットできるところまで来た」本当の意味

「AI Task Force」のキックオフで最初に言葉を発したのは、日本事業を統括する山本真人（＠mark）。その発言は、ただの情熱的なスローガンではなく、ここまでの葛藤と準備の蓄積を静かににじませるものでした。

「AIに本気でベットする。この言葉を、ようやく“言える状態”になった。ここまで来るのに、実は3〜4年かかっているんです。」

メルカリは以前から「テックカンパニー化」や「AI活用」を掲げてきました。しかし、それが単なるキーワードではなく、組織全体の再設計として本気で推進できるフェーズに至るまでには、技術基盤の整備、文化の醸成、そして何よりも意思の蓄積が必要でした。@markがとくに強調したのは、「私たちが変えようとしているのは、ツールや機能ではなく、働き方そのもの」であるという点です。

「僕たちが向き合うべきは、AI時代の『働き方の体験』そのものです。プロダクトのUXと同じように、ワーカーとしての体験（Work Experience, WX）も再設計していきましょう。」

“AIを使う会社”ではなく、“AIとともに働く会社”になる。この構造的な転換こそが、AI-Nativeの核心なのだと、私たちは理解しました。

@kimurasが託した「半年後に自律して動ける組織をつくる」意思

続いて登壇したのはCTOの木村 俊也（＠kimuras）。その語り口は落ち着いていながら、随所に強い問題意識と期待がにじんでいました。

「このタスクフォースの目的は、半年で棚卸しやPoC（Proof of Concept / 概念実証）を終えることではありません。その後、メルカリ全体が“自走”できる状態をつくることです。」

単なる作業支援ではなく、半年後に“AI前提で業務改善を続けていける”組織文化を根づかせる。それがこの変革の本質であり、難しさでもある。そう語ったうえで、@kimurasは具体的に3つの行動指針を示しました。

• Project Managerは、業務構造やAI技術にも踏み込み、Enabler(Engineer)的視点を持つこと
• Enabler(Engineer)は、プロアクティブに仮説やソリューションを試作し、“受け身”に陥らないこと
• そして両者とも、職能や部門の境界を越えて“巻き込み・広げる”こと

「この半年間、自分自身もAIを使いながら、働き方を変えていきたいと思っています。」

リーダー自身がそう語ったことで、メンバーの中にも「現場こそがAI活用の主役だ」という意識が静かに広がっていきました。

en.さん（Nulogic）からの学び：「AI導入」ではなく「再構築」であるということ

キックオフの後半には、外部ゲストとしてNulogicの代表であるen.さんをお招きし、「生成AI導入の実践知と勘どころ」というテーマで講演をいただきました。

en.さんは、AI技術とUXの接続を専門とし、数多くのスタートアップや事業会社で導入支援をされてきた方。その知見は、導入ツールの比較やプロンプトのテクニックにとどまらず、「なぜうまくいくのか」「どう設計すべきか」という思考プロセスにまで及ぶものでした。

はじめに：「AI導入」とは“思考と構造”の再設計である

冒頭、en.さんは「AI活用が盛り上がっているいまだからこそ、大事な問いがある」と前置きし、こんな問いを私たちに投げかけました。

「本当に、生成AIって、現場の仕事を変えてるのでしょうか？」

この問いは、特定のモデルやプロンプトの良し悪しの話ではありません。生成AIを業務に導入するとはどういうことか。en.さんは、それを「ツール選定やPoCの設計ではなく、“思考の構造をどう変えるか”の問題だ」と切り出しました。特に印象的だったのは、以下の言葉です。

「AI導入は、“何か便利なものを足す”のではなく、“考え方そのものを組み替える”行為です。」

この言葉の意味を、en.さんはいくつかの原則と10以上の具体事例を通して、具体的にひも解いてくれました。

第一原則：「入力→処理→出力」で業務を分解せよ

生成AIを業務に導入しようとするとき、多くの人が「どのツールが良いか？」「何ができるのか？」という“選択”の話から入ってしまいがちです。しかし本質は、まず自分たちの仕事を「入力（Input）→処理（Processing）→出力（Output）」の流れに分解できるかどうかにあります。

この分解ができていないままPoCを始めると、「AIに投げたらなんか返ってくるけど、それで結局何がしたかったんだっけ？」という状態に陥ってしまう。そのリスクを避けるために、業務の構造化が第一歩になるというメッセージでした。

例えば「メッセンジャーアプリの1年分のトーク履歴を“思い出”としてまとめる」という具体的なアイディアで考えてみると、以下のような分類になります。

• 入力：LINEの自然言語ログ（定型ではない、雑多なテキスト）
• 処理：Chain of Thought形式（複雑な問いや作業に対して、推論や思考のステップを明示的に記述するプロンプト設計手法）で、Geminiに“思考の流れ”を教える
• 出力：「思い出」「事件」「名言」など分類・要約されたテキスト群

ここで重要なのは、「“思い出”とは何か」という定義を、AIに渡す前に自分たちで定義しておくこと。

「AIを活かすには、先に“自分たちの曖昧さ”と向き合う必要があります。」

第二原則：プロンプトは“仕事の思考プロセス”を写す設計図である

次に、プロンプト設計の重要性です。

「プロンプトを書くこと＝自分の仕事を他人に説明すること」つまり「ゼロショットで命令するのではなく、Few-shotや先述のChain of Thoughtを使って、“考え方”そのものを渡す」ということでした。

「新人に“この仕事ってどう考えればいいですか？”と聞かれたときに、“こういう時はこう判断して、この順番でこうして…”と説明するじゃないですか。あれがプロンプトです。」

先ほどと同じLINEのトーク履歴の分類プロンプト例でいうと、

• 「敬語の文脈を重視して、ポジティブ・ネガティブのトーンを推定する」
• 「相手の名前は勝手に漢字に変換しないように指示」
• 「抽出後は、分類ラベルごとにサマリーを返す」

などです。つまり、単に“思い出を抽出せよ”ではなく、「どういう基準で思い出と定義するか」「変換のルールは何か」「出力のフォーマットは？」までをすべて指示することで、ようやく再現性ある出力になる、ということです。

第三原則：最初から“完璧な自動化”を目指さない

さらに「Human-in-the-Loop」の重要性です。

「AIは間違えます。揺らぎます。だから“人が確認する前提”で設計しないと、むしろ業務リスクが高まります。」

たとえば、レジュメのスクリーニングのように“人を見る”業務にAIを入れるときは、以下のようなプロセスが望ましいとされました。

• PDFをVision APIでOCRし、テキスト化（前処理）
• GPT-4oなどで“要件に対するマッチ度”をスコア評価
• 評価結果を一覧に出力し、最後は人間がチェック・判断

このように、“最初は部分導入でもいいから、小さく始めて改善する”ことが文化として重要になります。

「Human-in-the-Loopは、生成AI時代の“業務デザインパターン”です。」

第四原則：「巨人の肩に乗る」＝汎用ツールとテンプレートの活用

生成AI導入というと、ともすれば「社内ツールを作らなければ」と思いがちですが、生成AIのフロントは、日単位で進化します。UIもAPIもすぐ変わる。なのに自社でツールを作ったら…？

その代わりに提案されたのが、次の優先順位です。

1. ChatGPT、NotebookLM、Geminiなどの汎用ツールを“工夫して使う”
2. 社内ツールに“最小限のAI対応拡張”を加える
3. SaaS連携や自動化（N8Nなど）を活用
4. どうしても必要な場合のみ、ツール開発

この順序に従い、本質である「業務の再設計」に時間を割いていくほうが生産的とのことでした。

4つの原則を明快に説明頂いた後、講演はさらに具体的な事例に迫る後半へ。これまでに実践してきたさまざまな生成AIの導入事例を紹介いただきました。

それぞれの事例は、単なる技術導入の話ではなく、「なぜそう設計したのか」「どんな失敗や発見があったのか」といった思考の背景まで語られており、参加メンバーが自らの業務に引き寄せて考えるための実践的なヒントばかり。

講演冒頭で語られた「入力→処理→出力の構造化」や「試行速度」「再利用性」といった原則に基づいており、「AI Task Force」にとっても学びの深い事例でした。

最後に：生成AI時代の導入は“業務の言語化”から始まる

講演の締めくくりで、en.さんがあらためて投げかけた言葉は、とても静かで、それでいて深く刺さるものでした。

「生成AIを導入するというのは、“自分の仕事を、他人に説明できるようにする”ということです。
曖昧な業務、属人的な処理、空気で伝えていたもの……そうしたものを、“構造とプロンプト”に変換する作業です。」

どんな仕事も「自分しかわからないまま回している」限り、AIの力を引き出すことはできない。逆にいえば、業務を言語化し、構造化すれば、AIがレバレッジを効かせてくれるのだと気づかされ、「AI Task Force」の会場ではEnabler(Engineer)のみならず、Project Managerたちもうなずく姿が印象的でした。

「まず自分の仕事を、構造で捉え直してみる」――そんな静かな決意が、共有されたように感じられました。

これから、私たちがつくっていくこと

このプロジェクトは、華やかなプロダクトローンチではありません。膨大な業務をひとつずつ洗い出し、構造を理解し、再設計していく。そんな地道な積み重ねの上に、「AI-Nativeな会社」はつくられていきます。メルカリは、AIでなにか“特別な魔法”を起こそうとしているのではありません。自分たちの仕事と組織を、一つひとつ見直すところから、変わろうとしています。この半年間で、私たちはそれを体現していこうとしています。

メルカリのAI-Native化は、まだ始まったばかりです。

だからこそ、私たちは成功も失敗も含めて、これからも率直に発信していきたいと思っています。AI活用を始めたいけれど、どこから手をつければいいのか迷っている方。PoCを進めてみたけれど、どこかうまくいかないと感じている方。

そんな方にとって、今回の内容が少しでもヒントになれば幸いです。