メルカリのカスタマーサービス（CS）を支えるCS Productの現在地を紹介した記事「支える組織から、ともに考える組織へ。AIでサポート体験をつくり直すCS Productの現場」。そのなかでも、新たな動きとして立ち上がったのが、CSのナレッジ基盤を再設計するKnowledge Centerです。

お客さまがメルカリを使っていて困ったとき、その解決方法はどこにあるのか。お客さま向けの「メルカリガイド」、CSのメンバーが参照するオペレーションマニュアル、チャットボットが参照するデータ。同じお困りごとについて書かれているはずのこれらは、これまで別々のものとして存在していました。

2026年7月に立ち上がったKnowledge Centerチームが取り組んでいるのは、この状態の再設計です。解決方法そのものを一箇所に集め、AIと人の両方が扱える形に整えていく。目指すのは、お客さまのお困りごとが5分で解決される状態、そしてそもそもお困りごとが起きない状態です。

前例のない領域を、どうつくっているのか。Engineering Managerの@peter、Tech Leadの@jimpei、Engineerの@fukuchanに聞きました。

なぜ今、Knowledge Centerなのか

—— まず、Knowledge Centerはどのようなチームなのでしょうか。

@jimpei: 2026年7月に正式に立ち上がった、お客さまのお困りごとを解決するためのナレッジを、AIと人の両方が扱える形に再設計するチームです。構想自体は1年半ほど前からあったのですが、お客さまにとって身近な体験の改善を優先的に進めていた関係で、なかなか実現できなくて。AIをCSにどう活かすかという議論が社内で本格化したタイミングで、ようやく動き出しました。

—— その1年半のあいだに、どんな課題が見えていたのですか。

@jimpei: 大きく3つあります。1つ目は、私たちが掲げている「Effortless CX」との距離です。世界中のお客さまのお困りごとを5分で解決する状態を目指しているのですが、問い合わせの手段がメールからチャットに移ったことで、求められるスピードと正確性の水準が上がりました。

2つ目は、チャットボットの運用です。想定される会話の流れをシナリオとして1本ずつ書き、機能が変わるたびに直していく。労力をかけた分だけ解決できるお困りごとは増えるので、体験そのものは良くなります。ただ、シナリオの作成や変更にかかる労力が大きすぎることが課題でした。

3つ目は、サービスが増え続けていることです。メルコイン、メルカリモバイル。新しいサービスや機能が立ち上がるたびに、既存のオペレーションに「これも対応してください」と依頼が届きます。この状態のまま解決のスピードを上げるには、仕組みそのものを変えるしかないと考えました。

—— それまでのナレッジは、どんな状態だったのでしょうか。

@peter: お客さまがご自身で解決方法にたどり着くための「メルカリガイド」、お問い合わせに対応するCSのメンバーが参照するオペレーションマニュアル、チャットボット用のデータ。同じお困りごとについて書かれているのに、この3つがうまく紐づいていないんです。

しかも新しい機能は入り続けるので、メンテナンスだけで手一杯になる。ガイドの読みやすさを突き詰める時間は、どうしても後回しになります。

「これがベスト」という場所をつくる

—— そこから、どう変えようとしているのでしょうか。

@jimpei: ただ、文章を出力するだけではありません。お困りごとを解決するための判断条件、それをどこで確認するのか、そして取るべきアクションまでを、そのまま実行できる状態にしています。これがあることで、チャットボットが自分で正確に判断して動いたり、CS担当者の判断を支援したりできるようになります。

さらに、使われた結果を戻します。そのナレッジで解決できたのか、うまく機能しなかったのか。利用データをマスターに返して、改善が回り続ける状態にしたいと思っています。

お客さまとの接点は、ご自身で解決していただく場合と、CSにお問い合わせいただく場合の2つです。前者は今、長いメルカリガイドを読んで理解していただかないといけない。ここを、長いテキストを読まなくても必要な情報がすぐ見つかる状態にしたい。後者は、CSにつながったあとに適切な返信を素早くお返しできるようにする。どちらもナレッジマスターがあることで成立します。

—— マスターが複数あったものを、一つにまとめるようなイメージでしょうか？

@jimpei: そうですね。中には現場が参照できる情報になっていないものもあり、運用が追いついていないものもあるので、「マニュアルに書かれていない、これは信用できない」と判断する必要性が発生してしまう。すると現場のメンバーが、手元に自分たちだけのナレッジを持つようになります。CSに聞くと「書かれてないけど、実はこうなんです」という知見もある。

こうした知見も含めてマスターをまとめ、「これがベストです」と言える状態にするのが私たちの仕事。人にとっても、AIにとっても読めない状態だった、ということだと思っています。

—— AIにとって読めない、というのはどういう意味でしょうか。

@jimpei: 普通のマニュアルは、文章が長く書き連ねてあるだけなんです。今のAIは表も画像もある程度は読み解けますが、膨大な文章のなかから重要なところを正確に把握してください、というのはやはり厳しい。

そこで、データ自体にラベルを付けていきます。「ここは条件1で、このパラメータを見ます」「配送種別を見ます」「配送種別には選択肢がこれだけあります」。そうやってラベルを振り、ラベル同士の関連を設定していく。これが構造化です。ラベルが振られていれば、AIにめちゃくちゃ頑張ってもらわなくてよくなる。スピードのためでもあり、正確性のためでもあります。

マーケットプレイスのCSならではの難しさ

—— 購入者と出品者、そして配送会社。関わる人が多いことによる難しさはありますか。

@jimpei: BtoCのサービスであれば、企業側が答えを持っているので、お問い合わせを適切な担当に振り分ければ解決に向かいます。でもC2Cのマーケットプレイスは、プラットフォーム上で購入者と出品者というお二人がやり取りされる。単純に考えても、お困りごとの発生源が2倍あります。

しかも「最初から壊れていたのか、届いてから壊れたのか」は、プラットフォームの立場からは本当にわからない。どちらの言い分がどれだけ正しいのか。第三者である配送会社に原因がある可能性もあります。公平性を保つために購入者と出品者は同じ人が担当しますし、一貫したオペレーションも必要です。

ただ難しいだけならまだいいのですが、C2Cではトラブルが解決できることが非常に重要です。メルカリは当初から「安心・安全な場にする」と言っていますし、そこは譲れない。重要なのに難しい。だからこそ、仕組みで支える必要があると思っています。

—— チャットボットとナレッジマスターだけで完結させる、というゴールではないんですね。

@jimpei: そこは設計するときに決めました。私たちがやりたいのはCSのコスト削減ではなく、Effortless CXでお客さま体験を上げることです。チャットボットが間違った回答をご案内するくらいなら、わからないとき、解決しないときは人につながることを前提にする。マスターとチャットボットだけで解決することが、必ずしもお客さまにとっていいことだとは思っていません。

AIに任せる領域、人が決める領域

—— エンジニアとしては、どういう点が面白いですか？

@fukuchan: 対応のルールをどう組むか、という部分です。今はほぼルールベース、つまり条件を細かく決めて判断する形になっています。リスクが少なく正しい対応ができる一方で、フローが複雑になってルールが増えていく。

ポリシーだけを決めてAIに対応させれば、フローはシンプルにしやすい。ただ正確性のリスクがあります。前例もないし、自分たちのなかでも定まっていません。おそらく二者択一ではなく、いいところ取りになると思っています。リスクの高い領域はルールで処理して、そうでないところはAIにポリシーだけを渡す。この試行錯誤が一番面白いところです。

—— 人とAIの境目も決めることになりますか。

@fukuchan: そこは大きいです。たとえばメルカリガイドは、AIで生成できるのではないかという話もあります。でも今までは、1ページつくるだけでも、専門のコンテンツマネジメントのメンバーが作成し、リーガル、オペレーション等の担当がレビューする。たくさんの人を通して、一文一文の表現を調整してきました。AI生成に切り替えたとき、そのレビューをどうするのか。一つひとつ人が見るなら、AIで生成しても効率は変わりません。

生成時のプロンプトでクオリティーをコントロールできるように調整して、どうしても人が見るべきところはどこなのかを設計しないといけない。これまでの制作フローが大きく変わる可能性があると思っています。

参考になる先行事例も、探してはいるのですがほとんどありません。ちょくちょく論文を調べていて、近いことをやっている例はあるものの、全部が公開されているわけではないし、スタンダードなやり方もない。C2C、AI、CSサポートという組み合わせで、オペレーションまで踏み込んでいるものはほぼないんです。そのなかで自分たちでやり方を考えてつくり上げていける。やはりそこが面白いところです。

マニュアルをつくる仕事から、解決体験を設計する仕事へ

—— この仕組みができると、CSの仕事はどう変わりますか？

@jimpei: これまでは、メルカリガイドをつくる人、オペレーションを書く人でした。その視点だけだと、それぞれのマニュアルやガイドしかつくらないことになります。

これからは、「お客さま視点でこう案内できるだろうか、ご自身で解決できるだろうか」と、お困りごと解決の体験を考えながらマスターをつくるように視野を広げないといけない。一つのコンテンツをつくるというより、お客さま体験を考えながらオペレーションを設計する仕事になっていく。ここはまだ、私たちのなかでも完全に定義できていない部分です。

プロダクト側に返していけることもあると思っています。たとえば取引評価を誤って「残念だった」をつけてしまった場合、お問い合わせをいただくことがあります。これをお客さまご自身で変更できるようになれば、そもそもお問い合わせが発生しません。こうした改善を、Knowledge Centerに集まったデータを使って提案できるようにしたいですね。

—— 皆さんは、なぜこの領域に取り組み続けているのでしょうか。

@jimpei: 入社以来ずっとCS領域で、ヘルプセンターの基盤をつくってきました。メルカリガイドはその先駆けです。そのなかで、コンテンツマネジメントのメンバーが「本当はもっとコンテンツを良くしたい」と思っていることを知っています。でもリソースがなくてできない。

社内のCSのメンバーが「本当はこうしたいけど忙しくてやれていない」ものを全部良くして、本当にやりたいことに向き合えるようにしたい。それが出発点です。何回も方向転換しましたが、ナレッジの形が見えてきました。これならいける、ダメだったらもう一回。フィードバックをもらって改善しながら目標に向かうところに、モチベーションを感じています。

@fukuchan: 私は、大きい話と難しい話にテンションが上がるタイプです。CSがスケーラブルでなければ、事業もスケールしません。会社全体として注力すべき領域だと位置づけられていて、しかも内容がすごく難しくて、かつ面白い。

@peter: CS領域にスポットライトが当たっているのは、私もすごく良いことだと思っています。これまでCSが抱えてきた課題が、会社として向き合うべき重要なテーマだと認識され、組織を挙げて取り組む流れが生まれている。私たちは今、CSを大きく変えていく、その潮流のなかにいます。

どんな人と働きたいか

—— では最後に、どんな人が増えればこの動きはより勢いづきますか？

@peter: 一番足りていないピースは、AIのプロダクト開発を実際にやった経験がある方です。AIはみんな使っていますが、手元で使う、裏側で使うという形が多い。特にCS領域では、AIをサービスの機能として組み込み、実際にお客さまへ届けるプロダクト開発を経験した方は、実はまだあまりいないんです。

@fukuchan: 難しい話、大きい話にテンションが上がる方だと楽しいと思います。あと、エンジニアでも会話やコミュニケーションが仕事の多くを占めます。CSのメンバーやコンテンツをつくっているメンバーと話しながら決めていくことのほうが多いくらいです。

@jimpei: AIとCSの組み合わせは、業界的にも私たちが先行事例をつくれる領域です。前例がないぶん大変ですが、自分たちの試行錯誤が、この領域の新しいスタンダードになっていく面白さがあると思っています。

最後に

マニュアルをつくる仕事から、解決体験を設計する仕事へ。Knowledge Centerがやっているのは、新しいツールの導入ではなく、お客さまのお困りごとが解決される道筋そのものを、AIと人が一緒に扱える形につくり直すことです。

その先にあるのは、必要な答えに迷わずたどり着け、困ったときには適切な支援につながる体験です。仕組みも運用も組織もゼロからつくるフェーズが、いま始まったところです。

撮影：タケシタ トモヒロ