AIツールの導入で最初に決めるべきは、どれを使うかではなく、どう比べるかです。多くの現場では「評判がよいから」「他社が使っているから」で決まります。音声AIを手がける米Deepgramは、そこを自社のコードで比べました。Anthropicが公開している導入事例に、その比較の観点と、決めたあとに何を変えたかが書かれています。導入した結果の数字より、決める前にやったことのほうが持ち帰りやすい事例です。
この会社が置かれていた状況
Deepgramは音声AIのモデルを作っている会社です。公式サイトでは自らを「Voice AI built for real conversations」（実際の会話のために作られた音声AI）と説明しており、提供しているのはFlux STT（音声認識）、Flux TTS（音声合成）、Voice Agent API、Audio Intelligence APIです。
導入事例には、開発の対象範囲が非常に広かったことが書かれています。推論、API、SDK、課金、外部連携、インフラ、アプリ。この全部を抱えたまま、従来の進め方では速度が追いつかなくなっていたという説明です。
エンジニアリング担当のVPであるKris Eflandさんの言葉が引かれています。「競合や、まだ名前も聞いたことのないスタートアップが、いまAIネイティブで作っている」。そして、出荷の期日を落とすことの代償は顧客を失うことだ、と述べています。
具体的な詰まりも挙げられています。顧客から不具合の報告が来たとき、エンジニアが5つの異なる情報源から手作業でログと指標を集め、何日もやり取りを往復させていたという状態です。もうひとつ、社内の事情として書かれているのが、優秀なエンジニアが組織の制限を迂回するために自腹でClaude Maxを契約していたことでした。Eflandさんはこれについて「もし優秀な人が自分の財布から金を出して制限を迂回しているなら、ライセンス代よりも大きなものをすでに失っている」と述べています。
選び方：自社のコードで比べた
ここがこの事例の中心です。導入事例には、Deepgramが「実際の業務を対象とした比較検証」を行ったと書かれています。Claude Codeと他のコーディングエージェントを、自社のRust・Python・インフラ定義のコードベースの上で走らせて比べたという内容です。
デモ環境や公開されているベンチマークではありません。自分たちが毎日触っているコードの上で比べています。ここが重要で、AIの支援が効くかどうかは、対象のコードの書き方・規模・依存関係に強く左右されます。他社の結果がそのまま自社に当てはまらないのは、そのためです。
比べた観点として挙げられているのは4つです。素のモデルの品質、既存の社内ツールとの連携、自分の作業を自分で検証できるか、そしてエンジニアが摩擦なく使えるか。後ろの2つは、モデルの賢さとは別の軸です。検証できないものは人が全部読むことになり、使いづらいものは結局使われません。
結果として選ばれたのがClaudeでした。導入事例には、ある熱心な利用者の「モデルが単純に優れている。それ以外は些末な話だ」という言葉と、Eflandさんの「Claudeは、周辺のシステムが十分に良いので、我々が自分たちのインフラのほうを作り替えた唯一のフロンティアモデルだ」という言葉が引かれています。決め手として挙げられているのは、Claude Code・Cowork・MCP・スキル・サブエージェントを含む周辺環境だという説明です。
決めたあとに変えたこと
導入事例に書かれている移行先はClaude Enterpriseです。SSO、コンプライアンス管理の集約、そして組織単位でのMCP接続先の許可リストが理由として挙げられています。自腹での契約が起きていた状態を、組織として引き取った形です。
日常の進め方も書かれています。エンジニアはまずplan mode（計画モード）で作業を組み立て、正しくなるまで反復し、そのあとに実行と検証をClaudeへ渡します。いきなり書かせるのではなく、何をするかを先に固めるという順番です。
そして再利用の仕組みがあります。うまくいった解き方はSKILL.mdという形で共有リポジトリに残されます。個人の工夫を個人の中に置いたままにしない、という設計です。本番の環境にはGitHub・Grafana・Asana・SlackへのMCP接続が置かれています。
導入事例には、社内の研究用スタックの約80%が、エージェント前提の環境へ置き換わったと書かれています。ツールを足したのではなく、周りを作り替えたという表現です。
支援業務を多エージェントに置き換えた
冒頭の「5つの情報源を手で往復する」問題に対する答えが、Deephiveという仕組みです。導入事例によると、Jakeさんというエンジニアが作りました。
構造は次のとおりです。中央にOpus級のエージェントが1体いて、届いた問題を読みます。そこから並列でSonnet級の作業エージェントを立ち上げ、Slack・DevRev・Notion・GitHub・Asanaから必要な文脈を集めさせます。集めた結果をもとに対応案が組み立てられます。
すべての変更に人の承認が必要だと明記されています。調べる作業と集める作業は機械に渡し、変えてよいかどうかの判断は人が持つという分担です。これによって、顧客の不具合の切り分けが、何日もの往復から数分の作業になったと書かれています。
自社製品の側にも同じ考え方が入っています。Voice Agent APIでは、Deepgramの音声モデルと、推論の工程としてのSonnet（上位の階層）とHaiku（標準の階層）を組み合わせています。導入事例には、この構成で端から端までの遅延がおよそ700ミリ秒未満に収まると書かれています。会話が成立する速さを保ったまま、推論を挟むための階層分けです。
公表されている数値
導入事例に記載されている数値を、そのまま並べておきます。
社内のコホート調査として、Claudeを日常的に使う人と熱心に使う人は、使わない人に比べて4〜10倍の「durable code」（長く残るコード）を出しているとされています。最も生産性の高いチームでは、コードのおよそ95%がClaudeによって書かれたものだと書かれています。チーム単位の案件では3〜5倍、個人の定型的な作業では2倍を超える改善とされています。新しく入った人が6週間で40件を超える実質的なプルリクエストを出した、という記載もあります。
ここで注意しておきたいのは、これらが社内での測定値であり、測定方法の詳細は公開されていないことです。「durable code」の定義も導入事例には書かれていません。倍率そのものを目標値として持ち帰るのではなく、この会社がこう測って公表した、という形で読むのが正確です。
日本の実務者が持ち帰れる点
業種が違っても使える点が3つあります。
1つ目は、比較の場所を自社に置くことです。この事例で最初にやったのは、自分たちのコードの上で走らせて比べることでした。同じことは開発以外でも成り立ちます。記事の下書き、問い合わせの一次対応、資料の要約。どれも、自社の実物を使って比べなければ判断できません。公開されている比較記事は、比較の観点を借りるためのもので、結論を借りるためのものではありません。
2つ目は、「自分で検証できるか」を観点に入れることです。出力の質だけを見て選ぶと、確認の手間が全部人に残ります。この事例では、自分の作業を自分で検証できるかどうかが最初から選定の軸に入っていました。導入後の負担は、ここで決まります。
3つ目は、うまくいった解き方を組織に残す形を先に決めることです。この事例ではSKILL.mdという置き場所が用意されていました。置き場所がないと、成果は個人の手癖のまま消えます。
一方で、そのまま真似できない部分もあります。自腹での契約が起きていたという状況は、既に現場が強く必要としていたことを意味します。必要性が現れていない段階で同じ規模の移行を行っても、同じようには進みません。導入の順序としては、現場が実際に何に詰まっているかの把握が先です。
書かれていないこと
導入事例には、費用、ライセンスの数、移行にかかった期間についての記載がありません。比較検証で対象になった他のコーディングエージェントの名前も書かれていません。コホート調査の対象人数、期間、「durable code」の測り方も公開されていないため、倍率の再現性は確認できません。
また、公式サイトに載っている製品の仕様や提供条件は、Claudeの導入によって得られたものとして示されているわけではありません。Voice Agent APIの構成についてのみ、導入事例に記載があります。両者を混ぜて読まないよう、ここでは分けて扱っています。
この分野の実務を相談したい方へ
記事で扱っている内容は、当社が実務として支援している領域です。 自社で進めるか外部に任せるかの判断からご相談いただけます。