SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine(コードジン) ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

Developers Summit 2026 Summer セッションレポート(AD)

メルカリが語るAI時代のナレッジマネジメントとは? Notion全社導入の舞台裏

【16-A-2】メルカリがAI時代にナレッジマネジメントへ投資する理由 - Notion全社導入と開発ナレッジのこれから

 AI時代の到来により、組織のナレッジマネジメントは大きな転換点を迎えている。AIネイティブな組織の実現に向け、メルカリはなぜNotionの全社導入を決断したのか。本セッションでは、株式会社メルカリ JB Engineering Engineering Office Manager 廣井智一氏と、Notion Labs Japanの斉藤杏奈氏が、Notion導入の背景、開発の現場における実践、そしてAI時代に求められるナレッジの新たな要件について語った。

AIによって向上するナレッジマネジメントの投資価値

 最初に廣井氏は、ナレッジマネジメントを、「個人が持つ情報やノウハウを組織に蓄積し、将来にわたって活用できる状態にすること」だと位置付け、その重要性を以下の3つの失敗事例で示した。

 1つ目は、1999年に起きた、火星探査機Mars Climate Orbiterの事故だ。複数の開発チーム間で、ヤード・ポンド法とメートル法の単位の違いが正しく共有されなかった結果、探査機は火星に近づきすぎて燃え尽き、多額の投資が損害となったという。2つ目はローマのパンテオンに使われた「ローマコンクリート」だ。通常のコンクリートが50~100年ほどで劣化するのに対し、自己修復機能を備えたこの素材は、建設から約2000年を経ても残っている。 その製法が現代に継承されていれば、莫大な研究費が不要になるだけでなく、コンクリート建物の修繕費を劇的に下げられたかもしれない。

 そして3つ目はメルカリ自身の経験だ。数年前にアプリの大規模リファクタリングを行った際、仕様書がほとんど残っていなかった。実際の動作を確認しながら、仕様を洗い出す作業が生じ、多大なコストがかかったという。いずれも、ナレッジマネジメントが適切に行われていれば回避できた可能性のある事例だと、廣井氏は指摘する。

株式会社メルカリ JB Engineering Engineering Office Manager 廣井 智一氏
株式会社メルカリ JB Engineering Engineering Office Manager 廣井 智一氏

 しかしナレッジマネジメントは面倒な作業だ。蓄積された情報から、目的のものを探し出すのは難しい。仮に見つかっても、内容が長すぎる、難解である、情報が古いといった理由で活用されない。また、情報の更新が個人の自主性に依存しているため、メンバーの交代を機に管理が滞ってしまうリスクもある。さらに、現状で困っていなければ情報を記録しようという動機が生まれにくい。ナレッジマネジメントは将来への投資という性質を持つ。そのため、緊急性が低く、今すぐ取り組むべきだと説得しづらい上に、効果を実感しにくい。廣井氏によれば、こうした要因が重なり、結果として後回しにされてしまうのだという。

 ところがAI時代の到来が、この構図を一変させた。人だけでなくAIもコンテキストを必要とするようになり、ナレッジを蓄積し、適切に受け渡すこと自体の価値が上がった。加えて、AI自体が議事録の自動作成や要約、高精度な検索によって、ナレッジマネジメントの面倒さを大幅に削減してくれる。「ナレッジの価値が上がり、同時に管理コストが下がった結果、ナレッジマネジメントの投資価値(ROI)は飛躍的に向上した」と廣井氏は強調する。

 こうした背景のもと、メルカリはナレッジマネジメント基盤としてNotionを採用した。

AIでナレッジの価値が上がり、ナレッジマネジメントの作業コストは下がる
AIでナレッジの価値が上がり、ナレッジマネジメントの作業コストは下がる

Notion全社導入がもたらした変化 95%のAI活用率を支えた仕掛け

 Notion導入前のメルカリでは、ボトムアップの文化を重視し、部門ごとに異なる複数のツールが併用されていた。各現場の個別最適化の観点では効果的だったが、部門間の連携や協業が増加している状況にはそぐわなかったという。もちろん現場がこの課題を認識していなかったわけではない。エンジニア向けのサーベイでも、ドキュメンテーションは評価の低い項目の上位3つに継続的に入っていた。またAI時代以前に、管理コストを削減するため、小さいツールを統合する試みも行われた。しかし、各チームにとって愛着のあるツールを廃止するのは、利用者の数が少なくても、一筋縄ではいかなかった。

 転機となったのは、当時のCTOによる発案だ。同社の経営層は組織のAIネイティブ化を推進しようとしていた。トップダウンの動きがあれば、現場側からも納得を引き出しやすい。ナレッジ基盤の刷新を進める絶好の機会だと判断し、移行に踏み切ったと、廣井氏は振り返る。

 Notionを選んだ理由は、次の3点だ。第1に、議事録のようなフロー情報と仕様書のようなストック情報の両方を一つのプラットフォームで扱える点だ。第2に、AI機能の充実度だ。複数ツールでPoCを行ったところ、メルカリではNotionのAI機能が最も活用される結果となったという。第3に、現場にNotionのファンが多かったことだ。社内勉強会には300人以上が参加するなど、熱狂的な支持者の存在は導入推進の大きな追い風となった。

メルカリがNotionを採用した3つの決め手
メルカリがNotionを採用した3つの決め手

 Notionの導入は、さまざまな効果をもたらした。一つは、部門を越えたナレッジ共有だ。同じ基盤を使うことで、エンジニアが他部門へAIの使い方を伝えたり、逆に他部門の知見をエンジニアが学んだりする機会が増えた。単に情報が一つの場所にまとまっただけでなく、部門間の学習を促す接点としても機能したという。もう一つは、AIネイティブ化の促進だ。ドキュメント作成という日常的に行う業務をNotionへ移すことで、その延長線上にあるAI機能に触れる機会が自然と増えた。全社的な利用促進施策を進めた結果、Notion利用者の約95%がNotion AIを利用するまでになった。課題だったサーベイ上でのドキュメンテーション面の低評価も改善したという。

Notion Labs Japan合同会社 カスタマーサクセスマネージャー 斉藤 杏奈氏
Notion Labs Japan合同会社 カスタマーサクセスマネージャー 斉藤 杏奈氏

 ここでNotion Labs Japanの斉藤氏が、利用者の95%がNotion AIを活用しているという数字を「驚異的だ」と評し、具体的な普及施策について尋ねた。廣井氏の答えは、以下の3つの施策だ。

(1)経営トップからの徹底的なメッセージ発信

 さまざまなミーティングの場で繰り返しNotionへの移行を宣言し、同時に旧ツールからのマイグレーション方針も明確に打ち出した。旧ツールが残っていれば利用者はそちらを使い続け、運用コストも発生し続けるためだ。 廣井氏はこれを「メッセージのシャワー」と表現する。

(2)「Central Knowledge Management Committee」の設置

 ITチーム、セキュリティチーム、Engineering Officeによるバーチャルチームを組成し、ナレッジマネジメントに関する責任をこのチームに集約した。これにより、問い合わせ対応の窓口が一本化され、現場からの協力も格段に得やすくなったという。

(3)「Agent Day」の実施

 全社員が丸一日を使い、Notion AIやスキル機能を含む、複数のAI製品を利用し、エージェントを実際の業務で体験する機会を設けた。

 同社では、AIを使う人の割合だけでなく、スキルを利用する人、さらにスキルを自ら作成する人の割合まで計測しているが、現在ではスキル作成者が40%を超えているという。「単にAI利用者が増えただけでなく、自らエージェントを作るなど、より高いレベルの取り組みが増えているのは良い傾向だ」と、廣井氏は評価する。

AI時代のナレッジ設計 コード以上に重要なコンテキストをどう残すか

 後半のテーマは、開発現場におけるナレッジマネジメントのポイントと課題だ。廣井氏はまず、現在メルカリの開発現場で起きている3つの変化を紹介した。

(1)技術領域と職務領域の越境

 従来のAndroidエンジニア、iOSエンジニアといった専門領域での縦割りから、プロダクトエンジニアとしてフルスタックに責任を持つ形へのシフトが進んでいる。加えて、エンジニアがプロダクトマネージャーと共に機能要件の検討に関わるなど、職能の壁を超えた協業も広がっている。

(2)HITL(Human in the Loop)からHOTL(Human on the Loop)への移行

 HITLのアプローチでは生産性向上が限定的にとどまるとされている。そのため同社では、プロセスの中に人間がいないと回らない状態を解消し、人間がいなくても回る自動化されたループを社内のさまざまな業務に広げることを目指しているという。

(3)「Build First, Discuss Early」のアプローチ

 以前は仕様駆動開発を採用していたが、仕様を精緻に書く難しさや手戻りが課題だった。現在は、不完全でも先に動くものを作り、実物を見ながら認識のずれを早期に修正し、仕様を反復的に更新しているという。メルカリでは、AIによって作り直しのコストが下がり、従来は10人ほど必要だった開発を2〜3人で進められるようになったことで、 この進め方が可能になったという。

 これらの変化を踏まえ、廣井氏は、開発におけるナレッジマネジメントを成功させる3つのポイントを提示した。ただし、これらはいずれも完成された取り組みではなく、同社にとっても今後の大きな課題だと、廣井氏は付け加えた。

(1)Intent(意図)を残す

 コードから挙動は読み取れても、「なぜその実装になっているのか」という判断の背景は、意識的に言語化しなければ失われてしまう。将来の開発者やAIがコンテキストを理解するためには、例えば「障害中のサービスへの呼び出しを止める処理は、リソースの浪費や障害の連鎖を防ぐためだ」という意図を記録しておく必要がある。

当時の「Why」はソースコードだけでは読み解けない
当時の「Why」はソースコードだけでは読み解けない

(2)不要な情報を掃除する

 開発速度が上がればリリース数が増え、それに伴って廃止される機能や不要なドキュメントも増える。古い情報が残れば、AIへ与えるコンテキストを汚染し、回答の信頼性を損ねてしまう。そこで、記録量を増やすだけでなく、不要になった情報を継続的に整理・削除する自動化の仕組みが必要になる。例えば、フィーチャーフラグで機能をオフにしたら、対応するドキュメントが自動的に無効化されるといった仕組みだ。

開発の加速には、情報のこまめな掃除が欠かせない
開発の加速には、情報のこまめな掃除が欠かせない

(3)AIへのコンテキスト提供の設計

 スキルをはじめとする各種コンテキストを、エージェント間、メンバー間、チーム間でどのように共有するかも、大きな課題だ。 その際、情報圧縮や、推論過程での中間情報の欠落、人間とAIで読みやすさの基準が異なる点など、AI特有の癖を理解することも欠かせない。さらに、モデルの進化に伴い、AIの特性は絶えず変わるので、変化に継続的にキャッチアップする必要もある。

AIとのナレッジ共有の仕組みづくりの難しさ
AIとのナレッジ共有の仕組みづくりの難しさ

 一方、AI以前から変わらず重要なのが、Single Source of Truth、すなわち「信頼できる唯一の情報源」の確立だ。しかし現状では、ナレッジの運用ルールはドメインごとに異なっている。例えば金融領域とマーケットプレイス領域とでは求められる厳格さが異なるため、一律のルールを敷くことが難しい。さらにJiraなどの開発タスク管理ツール内にも仕様に近い情報が残るなど、情報の散在も課題だという。情報の権威性や、正式情報へ昇格させるプロセスについても、活発な議論が交わされている最中だ。

 最後に斉藤氏は、参加者が明日から実践できることを廣井氏に尋ねた。廣井氏は、次のアドバイスで講演を締めくくった。

 「Intentは、開発の現場における重要なキーワードになっている。なぜその判断をしたのかを残すことが、これまで以上に重要だ。皆さんもぜひ明日からNotionを試してみてほしい」(廣井氏)

Notion Labs Japanからのお知らせ

 本セッションでご紹介したサービスにご興味を持たれた方は、ぜひお問い合わせください。

この記事は参考になりましたか?

提供:Notion Labs Japan合同会社

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/29067 2026/09/08 11:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー