CoinbaseがAIを1,000人以上のエンジニアに展開した方法

How I AI
enterpriseagentsproductivityinterviewbusiness

CoinbaseはいかにしてAIを1,000人のエンジニアに定着させたか

大規模なエンジニアリング組織の多くは、AIツールを試して一時的な利用増加を確認した後、定着率が横ばいになるという壁にぶつかります。CoinbaseのEngineering Senior DirectorであるChintan Turakhiaもまったく同じ「失望の谷」を経験しました――そして、実際に機能するPlaybookを引っ提げて反対側へ抜け出しました。How I AIのClaire Bellとの対談で、彼は真の定着を生み出した具体的な戦術を語っています。

定着しない理由について: “The company tried to adopt other AI tools and we saw this uptick in adoption. People opened it up, checked the box, did kind of like a hello world thing, but it didn’t stick. My biggest thing is, how do I make this damn thing stick?”(「会社は他のAIツールの導入を試みて、利用率が上がったように見えました。みんなが開いて、チェックボックスを埋めて、いわゆるHello World的なことをして、でも定着しなかった。私の最大の関心事は、どうすれば本当に根付かせるか、ということです。」)問題はツール自体にあったわけではなく、2024年末の時点でモデルの準備が整っていなかったことにあります。そして、エンジニアの1人が離脱すると、チーム全体がそのツールを見限ってしまいました。Turakhiaの考え方はこうです:基盤となるモデルは必ず改善される。だから今のうちに反復練習を積んでおけ。

リーダーが再びコードを書くことについて: Turakhiaは2025年1月から4月まで毎日Cursorを使い、自らバグを修正してPRを出し、エンジニアたちに何が可能かを示し続けました。リーダーが会議室からAI導入を宣言するだけでは、最悪の結果を招きます。“I do think that it’s really important when you’re doing this organizational transformation that you have a single person with incredible conviction at the leadership level who is also hands on the metal.”(「組織変革を進めるうえで、リーダーシップレベルに強烈な信念を持ち、かつ自ら手を動かす人間が1人いることが非常に重要だと思っています。」)彼が最初に取り組んだのは「雑務」――ユニットテスト、リンター、Gitコマンドなど、誰もやりたくない魂を削る作業でした。

PRスピードランについて: 転換点となったのは、時間制限付きのイベントでした。全エンジニアが些細なバグや文言修正をひとつ選び、Cursorを使ってPRを提出するというものです。15分間で100人のエンジニアが70件のPRを出し、GitHubのインフラが限界を迎えました。その後、全社規模に拡大:800人のエンジニアが30分で400件のPRを提出しました。「ステータス報告はここで終わり、ものを作る時代の幕開けだと感じました。」

重要な指標の測定について: Turakhiaが執着するのはひとつの指標だけです。チケットが起票されてから、変更がユーザーに届くまでの時間。これには優先順位付け、コーディング、レビュー、デプロイがすべて含まれます。PRレビューのサイクルタイムは平均150時間から約15時間へと、10倍の改善を達成しました。目標は、フィードバックを受け取り、通話が終わる前に修正をリリースすることです。

社内エージェント「Cloudbot」について: CoinbaseはSlack上に社内ボットを構築し、Linearのチケット、複数のMCP(Datadog、Sentry、Amplitude、Snowflake)、そして複数のコードベースを連携させています。ワークフローはこうです:音声でユーザーフィードバックを収集 → LLMがバグを抽出 → Linearチケットを作成 → エージェントがPRを生成 → Cursorのブランチへディープリンク → モバイルテスト用QRコードを発行。ある夜、Turakhiaはフィードバックツールからバッチで200件のバグ修正を一度に走らせました。

「スーパービルダー」という役割について: Turakhiaは新しいロールを生み出しました。スーパービルダーです。この役割の最も重要な仕事はただひとつ、さらなるスーパービルダーを育てることです。AIツールを牽引し、社内エージェントを構築し、周囲全員を加速させる人材です。彼のアドバイス:エンジニアリング組織の中でAI活用能力トップ3に入ることは、今できる最良のキャリア選択のひとつです。

コーディネーションのオーバーヘッドが消滅することについて: “My calendar is empty. Almost empty. And the reason why is because the coordination overhead of prioritizing, changing the roadmap — no, you just do things.”(「私のカレンダーはほぼ空です。なぜかというと、優先順位付けやロードマップ変更のための調整オーバーヘッドがなくなったからです――もう、ただやるだけです。」)リーダーたちはより多くのコードを書いています。フィードバックから修正までのサイクルがスプリント単位ではなく分単位で測られるようになったため、チームはスプリントプランニングの議論を省略しています。

CoinbaseのAI導入Playbookから得られる6つの教訓

  • 信念を持って手を動かすリーダーが1人必要 — 定着には、毎日コードを書くハンズオンの牽引役が必要です。上からの号令だけでは機能しません
  • まず雑務から始める — ユニットテスト、リンター、Gitコマンドなど、魂を削る作業を先に取り除けば、エンジニアは前向きに取り組むようになります
  • PRスピードランがブレークスルーを生む — 全員が一斉にリリースする時間制限付きイベントは、確信を生み出し、インフラの限界を明らかにします
  • PRレビューが10倍速くなる — フィードバックからリリースまでのパイプライン全体を圧縮することで、サイクルタイムが150時間から15時間に短縮されました
  • 社内エージェントは外部ツールを超える — Cloudbotは Linear、Slack、MCPを連携させ、ユーザーフィードバックからPRのマージまでを自律的に処理します
  • 「スーパービルダー」はキャリアパスになる — AIによってチーム全員の生産性を引き上げる人材は、今まさに最も採用価値の高い存在です

AIを導入するエンジニアリング組織への示唆

Coinbaseの事例が重要なのは、本物のスケールを持つ実際のケーススタディだからです――5人のスタートアップではなく、厳格なセキュリティとコンプライアンス要件を持つ上場企業の1,000人以上のエンジニアが対象です。このPlaybookは再現可能です:コードを書く確信に満ちたリーダーから始め、まず雑務をターゲットにし、スピードランで目に見える成果を生み出し、外部ツールでは届かない領域に社内エージェントを構築し、唯一意味のある指標――フィードバックからユーザーに届くまでの時間――を測定する。これを実現した組織は、単に出荷速度が上がるだけではありません。既存の人員で何が可能かという定義そのものが変わります。