AIで生産性が上がった事例を集めている方へ

社内でAI導入を提案するために、他社の成果を探している。あるいは、ベンダーから示された倍率をどう受け取ればいいか決めかねている。そういう段階の方に向けて書いています。

大きな数字が出ました。ただし、そのまま持ち帰ると使えません。

決算説明会で出た数字

メルカリが2026年8月5日、2026年6月期の通期決算説明会を開きました。山田進太郎CEOが提示した数字はこうです（ITmedia ビジネスオンライン）。

「エンジニア1人当たりの開発量は2年前の7.6倍に達し、業務プロセスの変革により49.5万時間分の生産性向上を実現した」

業績も伴っています。売上収益2292億円で前年比19%増、コア営業利益441億円で同60%増。期中に2度実施した上方修正後の予想も上回り、過去最高を更新しました。全従業員のAIツール利用率は100%です。

数字が出ていて、業績も動いている。事例としては強い部類です。

同じ指標が1.9倍とも報じられています

ただし、比較の基準に注意が要ります。

日経クロストレンドは同じ「エンジニア1人当たりの開発量」を前年比1.9倍として報じています。決算説明会の7.6倍は2年前比です。

どちらも間違いではありません。起点が違うだけです。

これは測定範囲を示さない倍率をどう読むかで書いた話の、実例そのものです。メルカリは基準時点を明示しているので誠実な部類ですが、報道が二次流通する過程で「7.6倍」だけが独り歩きします。自社の稟議に貼るなら、倍率と一緒に基準時点を書かないと後で説明できません。

半年前、当の本人が違うことを書いています

ここからが本題です。

同社CTOの木村氏が2025年12月25日に公開した記事に、こう書かれています（AI-Nativeという選択）。

社員の95%がAIツールを活用し、コード生成の約70%をAIが担い、開発スピードは前年比64%向上した。そのうえで——

「しかし、私たちは現在の状態を“AI-Native”だとは捉えていません」

さらに踏み込んで、こうも書いています。

「私たちもAI Coding Assistantをはじめ、さまざまなAIツールを導入してきましたが、当初想定していたほど生産性が向上しないという課題がありました」

成功事例として語られている会社が、半年前に「思ったほど上がらなかった」と自分で書いている。ここを読まずに倍率だけ持ち帰ると、順序を取り違えます。

上がらなかった理由として挙げられているもの

では何が足りなかったのか。挙げられているのはツールではありません。コンテクストです。

AIエージェントは十分な文脈がなければ期待どおりに動かず、手直しが繰り返されてかえって時間がかかる。だから背景知識、規約、過去の意思決定プロセスや議論のログを渡す必要がある、と説明されています。

そして最も重要なコンテクストとして名指しされているのが、意思決定情報です。

SlackやGitHub、ミーティングメモなど複数のツールに議論が散在し、必要な情報を必要なときに取り出すことが困難になっている

「なぜその判断に至ったのか」という背景が抜け落ちる。この課題認識は、要件定義AIエージェントが「長期記憶」で解こうとしている問題と同じです。ツールを売る側と、自社で使い倒した側が、別々の経路で同じ場所に着いています。

棚卸しは約4000本ありました

そこで動いたのがAI Task Forceです。2025年7月に発足し、全社を33のドメインに分け、各領域にエンジニアとPjMを配置して総勢約100名。約2000人の会社で、100人を張っています。

責務は3つ。全業務の棚卸し、AI化のロードマップ策定、その実行。

棚卸しの結果、定義されたワークフローは約4000本でした。

すべてをAI化するわけではない、と断ってはいます。それでも、4000本を数えるという作業が先にあった。開発プロセス側でも「Double」プロジェクトが動き、AIエージェント向けの仕様フォーマット（ASDD）を整備しています。プロジェクト名は生産性を2倍にする目標に由来します。

7.6倍は、この後ろに出てきた数字です。

持ち帰れるのはどちらか

倍率は真似できません。事業構造も、人数も、扱っているプロダクトも違います。

真似できるのは順序のほうです。**ツールを配る前に、業務を数えて、決定の経緯を残せる場所を作る。**メルカリはナレッジをNotionへ集約し、議事録の作り方から再設計しています。派手ではありませんが、ここが効いたと当事者が書いている。

使っているかではなく何を決めたかで差が出るという話とも重なります。利用率100%は通過点で、そこから先は業務側の設計です。

他社の生産性向上事例を自社に当てはめる4つの質問

  • その倍率は、いつと比べた数字ですか: 前年比か、2年前比か、導入前比か。同じ取り組みでも起点を変えれば数字は変わります。基準時点が書かれていない倍率は稟議に貼れません
  • 何を1単位として数えていますか: 開発量、開発スピード、コード生成量、削減時間。指標が違えば比較になりません。自社で同じものを測れるかも確認します
  • その会社は、うまくいかなかった時期を公開していますか: 成功だけが書かれている事例は、手前でやったことが抜けています。つまずいた記録がある事例のほうが、順序を写せます
  • ツールの前に何を整備しましたか: 業務の棚卸し、規約の統一、意思決定ログの集約。ここが書かれていない事例は、自社で再現したときに同じ結果になりません

社内のAI導入提案書や、他社事例を検討する会議の評価軸にそのまま転記して使えます

現場メモ

私たちがAI前提で開発を進めるとき、最初に時間を使うのは、その案件で何が決まっていて何が決まっていないかの棚卸しです。仕様書の有無、判断した人が今もいるか、変更の経緯が文書に残っているか。

これは提案の場では地味です。**「まず数えましょう」は、期待されている返答ではありません。**すぐ動くものを見せたほうが話は早い。

それでもこの順序を変えないのは、飛ばした案件の後半で何が起きるか見てきたからです。決めた経緯が残っていない箇所は、必ずもう一度議論になります。そのとき前回と違う結論が出ると、作ったものが無駄になる。

メルカリのような規模の会社が、ツールを全社に配ったうえで「思ったほど上がらなかった」と書き、そこからナレッジの整理に戻っている。この順序が規模を問わず同じだったことは、正直なところ心強く読みました。

何を持ち帰るか

7.6倍という数字は本物です。基準時点も開示されています。それでも、この事例の使いどころは倍率ではありません。

**利用率100%に到達した会社が、その状態を「まだAI-Nativeではない」と言い、業務4000本の棚卸しに戻った。**ここが持ち帰る部分です。

自社で今日から数えられるものがあります。決定の経緯がどこに残っているか。残っていない業務がいくつあるか。AIが上流工程に入ってくるほど、この整備の有無が効きます。

自社の業務のうち、どこまでが文書として存在し、どこから人の記憶に頼っているのかを整理したい段階でしたら、お問い合わせからご相談ください。ツールの選定ではなく、数えるところから入ります。