Coinbase Wallet、IDE 削除実験でエージェントファーストへ

多くのエンジニアリングチームにとって、AI の導入は IDE や CLI 内で始まります。しかし Coinbase Wallet は、より破壊的な実験に踏み切りました。約3週間開発を一時停止し、エンジニアたちに IDE を削除させたのです。

この中断は、エージェントファーストへのリセットを強制的に行うための設計でした。Coinbase Wallet のプロダクトエンジニアリングを統括する Chintan Turakhia 氏は、Arize Observe 2026 でこの実験の意義を説明しました。彼が指摘したのは、最も難しいのは技術ではなく文化だということです。コード生成エージェントはすでに意味のあるソフトウェアを生み出すのに十分な能力を持っていました。しかし、チームには「コード作成にコストがかかる」という前提で構築されたプロセスやインフラ、そして習慣を置き換える必要がありました。

Chintan 氏によると、その結果は劇的なものでした。以前なら20〜25日かかっていた単純なモバイルのバグ修正や機能追加が、現在は約1.8日で完了します。Slack へのリクエストからプルリクエストとテスト可能なビルドまでわずか12分、セキュリティレビューも従来3日かかったものが、今は5分で実行可能です。

しかし、最も教訓となったのは、その後に何が崩壊したかという点です。コード生成が加速すると、プルリクエストのレビュー、CI、ビルドインフラ、検証、そして最終的にはプロダクトの意思決定自体がボトルネックとなりました。

意図から本番環境までの時間をどう測るか

Chintan 氏の最重要指標は、「意図（Intent）から本番環境（Production）までの時間」です。

誰かがバグを特定し、機能の提案を行い、あるいはプロダクトの仮説を検証した瞬間にこの計測は始まります。そして、ユーザーがその結果を実際に体験できる時点でクロックは停止します。

この指標は、チームが局所的な最適化を称賛するのを防ぎます。生成されたコード量やプルリクエスト数、エージェントの実行回数がどれだけ増えても、変更がビルド待ち、レビュー待ち、テスト環境の準備、承認待ちで数日かかるのであれば、意味はありません。

コーディングエージェントを導入するチームは、以下の指標を測定すべきです。

• アイデアから実行可能なプロトタイプまでの時間
• プロトタイプから検証済みのビルドまでの時間
• CI（継続的インテグレーション）、インフラストラクチャ、セキュリティ、人間のレビューに費やす待機時間
• 実装において人間が介入する頻度

Coinbase では、コード生成の高速化が直ちに下流工程への圧力として転嫁されました。以前は 30〜40 分かかっていたビルド時間をキャッシュされたクラウド環境に移行し、1 分未満に短縮しました。このボトルネックが解消されると、チームは検証プロセスにより注力できるようになりました。Chintan 氏によれば、現在では制限要因は次第に入力側、つまり「何を構築するか」「なぜそれが重要なのか」を決定する段階へと移りつつあるそうです。

Coinbase の製品開発における AI エージェントハネスの内部構造

すべてのエンジニアに AI コーディングアシスタントを提供することは第一歩に過ぎませんでした。Coinbase Wallet は、計画から実装、レビュー、テスト、リリースまで一貫して作業を担う社内エージェントハネスを構築しました。

• ワークフロー：開発ループにおける役割 / 人間がレビューする内容
• Forge：Slack からのリクエストをコード、プルリクエスト、テスト可能なモバイルビルドに変換 / 動作中のプロダクト
• Sail：セキュリティ上の問題について変更点をレビューし、リスクレベルを割り当て / リスクのホットスポットと高インパクトな変更

トレーサー・バレット

仕様から実装、シミュレーターテスト、検証、そして内部リリースへと進め、最終結果が当初の意図と合致しているかを確認する仕組みです。

これらのシステムを組み合わせることで、エンドツーエンドのフィードバックループが構築されます。エージェントは文脈を収集し、計画を立て、複数のリポジトリにまたがって作業を行い、プルリクエストを作成します。さらにモバイルシミュレーターを起動し、その結果の動作を仕様と比較して証拠を Slack に返送することも可能です。従来のように差分（diff）から始めるのではなく、エンジニアは動作するビルド、リスク評価、ログ、そして変更前後の録画映像から作業を開始できます。

ただし、重大な変更については人間のレビューが依然として中心です。Coinbase は規制環境下で運営されており、資金移動に関わる事項には引き続き徹底的な人間によるテストと承認が必要です。リスクの低い変更はエージェントによる審査会議を経ることで処理でき、エンジニアは失敗が最も深刻な影響を与える部分に集中して注力できます。

AI コーディングエージェントへの作業計画の立て方

Coinbase Wallet のワークフローにおける第一原則はシンプルです。「プロンプトするのではなく、計画を立てる」ことです。プロンプトはエージェントにタスクを実行させるものですが、プラン（計画）は成果物、制約条件、実装の文脈、そして作業完了を証明するための証拠を定義するものです。

Chintan 氏はこのプランを「契約」と表現しました。実装が失敗した場合、エンジニアは IDE を開いて手動でコードを修正するのではなく、その契約を更新してワークフローを再実行することが推奨されます。プランを修正することで、将来のエージェント実行における学習成果を保持できるのです。

有用な実装計画には、以下の要素を含めるべきです。

目指すユーザー体験。

変更が必要な現状の動作。

関与するリポジトリ、サービス、またはインターフェース。

明確な受入基準（Acceptance Criteria）。

既知のエッジケースとリスク領域。

エージェントが返すべきテスト結果、ログ、スクリーンショット、または録画データ。

これらの詳細を 20 分かけて明確にしておくことは、あいまいな要件に対してエージェントの誘導に数時間を費やすことを防ぎます。また、複数のエージェントが並列で実行可能な再利用可能な成果物も生み出します。

なぜ AI コーディングエージェントには文脈、観測性、そして高速な CI/CD が必要なのか

「エージェントに任せておけばいい」という考え方が機能するのは、エージェント自身が自分の行動を観察できる場合に限られます。エージェントは、開発者が利用するのと同じ運用証拠へのアクセス権限が必要です。具体的には、アプリケーションログ、ビルド出力、テスト結果、ランタイム動作、デザインシステムのコンポーネント、そして本番環境の制約です。これらの入力がない限り、生成されたコードは検証されていない仮説に過ぎません。

Coinbase の検証ワークフローでは、異なるデバイス構成に対してモバイルシミュレータの群れを起動します。エージェントが実装を実行し、前後の動画をキャプチャして元の仕様と比較し、どのケースが成功または失敗したかを報告する仕組みです。

検証に失敗した場合、チームは仕様を更新してループを再実行します。これは評価駆動型開発と同じ構造です。つまり、「結果を指定し、結果を検証し、手動でパッチを当てるのではなく、仕様自体を変更する」というサイクルです。

これにより、観測と評価が開発プロセスそのものに組み込まれます。エージェントが実装を行い、その動作を観察し、結果を評価して人間が検証できるエビデンスを返します。通常、プロダクションチームは Arize AX 上でトレースや評価としてこのエビデンスを記録します。Chintan 氏によると、ビルドと検証環境の改善により、人間の介入なしにマージされたプルリクエストが 73% 増加したとのことです。

エージェントファーストな開発がスプリント、PRD、引き継ぎに与える影響

エージェントファーストな開発は、Coinbase にソフトウェアデリバリーを取り巻く慣習を見直すことを迫りました。チームは、必須の工程としてスプリント、デイリースタンドアップ、プロジェクトキックオフ、従来の PRD（製品要件定義）、Figma を介したデザイン引き継ぎを廃止しました。現在はアイデアや仕様から始まり、すぐに動作するプロトタイプへと移行し、可能な限り早く内部ユーザーに届けるという流れになっています。

各チームは数百ものプロトタイプを実社で試しますが、価値を示せたアイデアのみが、本番環境での運用に必要な追加のエンジニアリングとデザイン作業に進みます。このプロセスを丸ごとコピーするだけでは、より大きな教訓を見逃してしまいます。どのチームも、エージェントが生み出すボトルネックに対して既存のワークフローを見直す必要があります。

各会議、ドキュメント、承認、引き継ぎについて、以下の問いを立ててください。

• このステップは製品の意図を明確にしますか？
• エージェントに必要な文脈を提供していますか？
• 検証を改善したり、意味のあるリスクを減らしたりできますか？
• ユーザーが動作するソフトウェアをより早く評価できるように役立ちますか？

これらの条件のいずれにも当てはまらないプロセスは、もはや存在しない制約を守り続けている可能性があります。

1 日のロードマップ圧縮テストを実行する

Chintan がエンジニアリングチームに推奨するのは、ロードマップ上の最も野心的な項目を選び、それを 1 日で構築しようとする試みです。この演習の目的は、結果が本番環境に到達しなくても、潜在的な制約を明らかにすることにあります。

以下のシンプルな手順に従ってください。

• 野心的だが範囲が明確な製品成果物を選ぶ
• 受入基準と検証要件を含む詳細な計画を立てる
• 生成されたコードを手動で編集せず、エージェントを通じて計画を実行する
• 動作するビルドと、意図通りに機能していることを示す証拠を必須とする
• ワークフローが停滞または失敗した箇所をすべて記録する

1 日の終わりにボトルネックを分類します。エージェントに文脈不足があったのか、CI が遅すぎたのか、評価基準があいまいだったのか、テスト環境へのアクセスができなかったのか、あるいは製品アイデア自体が不十分だったのかもしれません。

Coinbase はこの実験のより過激なバージョンを実行しました。2 人のエンジニアに 1 週間でアプリケーションを再構築させるのです。彼らは約 85 パーセントを完了しましたが、残りの 15 パーセントが本番環境へのリリースを阻みました。信頼性、セキュリティ、検証、そして製品判断力が、作業の完成度を決定する最終的な要因だったのです。

エージェントファーストなエンジニアリングでは、実装フェーズを圧縮することで、人間は意思決定により多くの時間を割けるようになります。すると、計画こそが主たる仕事となります。そして時には、ループに役立たなくなったプロセスを削除することから始めるのが、最も価値のある第一歩となることもあります。