「Claude Code 企業 導入事例」で検索すると、79%短縮・4〜10倍・95%といった数字が並んだ事例ページに行き着く。だがこの数字を見て「うちでもこれくらい効果が出るはずだ」と期待値を作ってしまうと、たいてい外れる。事例に出てくる数字は、その企業の規模・体制・対象業務という前提の上で成立したものであって、前提を共有していない企業がそのまま真似できる保証はない。Anthropic公式の事例ページから、規模も業種もまったく違う2社——Rakuten（大企業・Eコマース）とDeepgram（スタートアップ・音声AI）の事例を読み比べ、何が数字を成立させている前提で、中小企業にとって何が実際に持ち帰れる部分かを整理する。

事例1：Rakuten——巨大OSSライブラリの一点突破

公式事例ページによると、Rakutenの機械学習エンジニアはClaude Codeを使い、1,250万行規模のOSSライブラリ「vLLM」で特定の活性化ベクトル抽出方法を実装させた。Claude Codeは7時間の単一実行で全ジョブを完了し、参照方法との比較で99.9%の数値精度を達成したという。この個別事例とは別に、Rakuten全体の実績としては、機能の市場投入までの期間が24営業日から5日に短縮された（79%減）という数字も同じ事例ページに挙げられている——ただしこちらはvLLMの事例と紐づけて書かれた数字ではなく、会社全体の成果として並記されている点には注意がいる。AI for Business担当のGM、Yusuke Kaji氏は「5つのタスクを並列実行できる。4つをClaude Codeに委譲し、残り1つに集中できる」という運用の仕方に触れている。

この数字を成立させている前提は、事例ページに明記されてはいないが構造から読み取れる。vLLMの事例は仕様が固まった巨大な既存OSSライブラリへの機能追加という、比較的スコープが明確な一回性のタスクだ。24営業日→5日という会社全体の数字も、どの業務・どの期間を集計したかという算出方法は開示されていない。加えて、AI活用を専任で推進するGM職が置かれ、複数タスクを並列で管理できる体制があることも、この事例の前提として効いている。つまりどちらの数字も「特殊で一回性の高いタスクや、専任の推進体制のもとで出た成果」であり、日々の細々とした開発業務すべてにそのまま当てはまる数字ではない。

事例2：Deepgram——スタートアップの日常的なエンジニアリング全体

一方、Deepgramの公式事例は毛色が違う。音声AIのスタートアップであるDeepgramは、Claude CodeをRust・Python・インフラコードにまたがる全面的な再構築プロジェクト「DG2」に使い、インシデント対応スキルの構築や、Slack・GitHub・Grafanaと連携するマルチエージェント顧客サポートシステム「Deephive」の開発にも活用している。事例が挙げる数字は、Claude利用者は非利用者と比べて耐久性のあるコードを4〜10倍多く出力し、最も生産性の高いチームでは生成されたコードの比率が95%に達し、研究チームは従来型のスタックの80%を置き換え、チームプロジェクトの効率は3〜5倍、顧客インシデントの原因特定は数日単位から数分単位に縮んだという。

Rakutenの事例との違いは、対象が「一回性の大きなタスク」ではなく「日常的なエンジニアリング業務全体」である点だ。そしてもう一つ見逃せない違いが、Deepgramの数字の作り方にある。「Claude利用者と非利用者の差が4〜10倍」という比較は、Rakutenの「24営業日→5日」のような単発の実績報告ではなく、社内で利用の有無を比較できる計測を継続的に行っていないと出せない数字だ。スタートアップという小さな体制でも、この比較を仕組みとして持っていたことが数字の土台になっている。

共通点と、中小企業が実際に持ち帰れる部分

規模も業種もタスクの性質もまったく違う2社だが、共通点が一つある。どちらも「導入した」で終わらせず、before/afterや利用者/非利用者の差を具体的な数字として追っていることだ。Rakutenは期間短縮と精度、Deepgramは利用者と非利用者のコード品質の差という形で、それぞれ自社の業務に即した指標を持っている。

ここが中小企業にとって実際に持ち帰れる部分だと考える。「79%短縮」や「4〜10倍」という数値そのものを目標に置くのではなく、自社の開発業務のどこかに、利用者と非利用者を比べられる指標を先に用意しておくという進め方の方を真似るべきだ。数字を真似ようとすると、対象タスクの性質も体制の厚みも違う自社では再現できず「思ったより効果が出なかった」という評価で終わりやすい。仕組みを真似れば、自社の実際のタスクに即した自社なりの数字が出てくる。この計測の立て方は以前の記事で、公式の分析ダッシュボードが「保守的な過小評価」であることを前提に、自社でベースラインを作る手順として扱った内容がそのまま使える。

もう一つ付け加えておきたいのは、これらの数字がAnthropicの公式事例ページに掲載された、各社自身の報告に基づく数字だという点だ。第三者による監査を経た数字ではなく、成果を強調する事例紹介という性質上、うまくいった部分が選ばれて紹介されている前提でも読む必要がある。

自社で判断する基準

導入事例を探すときは、「自社と同じ業種・同じ規模の会社を探す」よりも、「自社と同じように、特殊で一回性の大きなタスクに使いたいのか、日常的なエンジニアリング全体に広げたいのか」で事例を選んだ方が実態に近づく。前者ならRakutenのように対象タスクを明確に絞り込んで専任の体制を組む必要があり、後者ならDeepgramのように利用者・非利用者の比較を継続的に測る仕組みが先に要る。社内展開の進め方や組織のAI導入成熟度で扱った「一人が使いこなせても組織全体は変わらない」という論点とも重なるが、事例の数字を輸入する前に、自社がどちらの型で導入を進めたいのかを先に決めておく方が、結果的に事例との比較もしやすくなる。

自社の業務内容・体制でどちらの型が現実的か、計測の仕組みをどう設計すべきか整理したい場合は、パイロット・構築のフェーズで一緒に検討できる。まずは30分の無料診断から相談してほしい。