Navan、コードベースを凍結せずに1か月がかりの移行を1週間に短縮
Navanの最新の移行は8つのアプリケーションと15のライブラリに及びましたが、開発を止めることなく約1週間で完了しました。
Navanの直近の移行は8つのアプリケーションと15のライブラリに及びましたが、開発を止めることなく約1週間で完了しました。2年前には同規模の移行に1か月以上かかり、マージの失敗でmasterブランチが丸1日ロックされたこともありました。この差を生んだのが、Cursorのクラウドエージェントです。1人のエンジニアが単独で作業を進める代わりに、Navanは移行計画を一度立てるだけで、それを自社のセルフホストマシン上で8つのアプリケーションに並行して実行できるようになりました。
8つのアプリの移行が、1か月ではなく1週間で完了
2年前、Navanのコードベースを新しいバージョンのSpringへ移行した際には、Sr. スタッフソフトウェアエンジニアのRahul Popuri氏が1か月以上を費やしました。その間、不完全なプッシュとリバートが原因でmasterブランチが丸1日ロックされたこともあります。影響はロック解除後も続き、他のエンジニアは数日経っても変更の取り込みに追われていました。しかし、より大きなコストはロックそのものではありません。エンジニア1人の1か月分の時間が、機能のリリースやバグ修正ではなく移行作業に費やされたことでした。
Navanの直近の移行であるSpring Boot 4へのアップグレードは、進行中の開発への影響を抑えながら、約1週間で完了しました。Rahul氏はCursorを使ってアップグレードを事前に計画し、各コンポーネントをNavanのセルフホストマシン上で動作するクラウドエージェントに委任しました。これにより、8つのアプリケーションと15のライブラリを、1つずつではなく同時に移行できました。エージェントはNavanの内部ツール群を活用し、同じマシン上でブラウザを起動して実際にフローをクリック操作しながら、自らの変更を検証しました。
以前は、たった1回のマージの失敗で作業全体が止まってしまうこともありました。今回は、進行中の開発への影響を最小限に抑えながら、8つのアプリを同時に移行できました。
Rahul氏が見守っていたのは、1つのジョブの実行だけではありません。異なるアプリケーションを同時にアップグレードする複数のエージェントを監視していたのです。これほどの規模の並列作業は、ほんの数か月前でも不可能だったと同氏は語ります。
クラウドエージェントが実際のワークロードを実行
Rahulは、自身の業務のほぼすべてをCursorのクラウドエージェントに移行しました。GitHub関連の作業はCursorが管理するインフラストラクチャ上で実行されます。SnowflakeとSlack向けの内部MCPはNavan独自のセルフホストマシン上で実行され、エージェントはそこでブラウザを起動して自らの変更を検証することもできます。この基盤の上で自動化、スキル、メモリが動作するため、評価ループや移行は誰かが監視していなくても非同期で進み続けます。
このパターンはその後、一人のエンジニアの枠をはるかに超えて広がりました。現在、Navanでは約200人がCursorのクラウドエージェントを日常的に活用しており、2026年4月から10倍に増えています。
Cursor導入以前、Navanのエンジニアは従来のコーディングエージェントを中心に本格的なインフラストラクチャを構築していましたが、その運用には誰かが1台のデスクトップの前でセッションを開いたまま、ずっと張り付いている必要がありました。そのため、Navanが求めていた並列かつ非同期の作業は実現できませんでした。
プロダクトチームにも同じ効果が表れている
プロダクト側では、経費精算と請求を担当するスタッフソフトウェアエンジニアのElton Yangが、平易な説明文をもとに経費精算・請求ワークフロー向けの新しいエージェントを構築しています。Cursorはチームの既存のデザインパターンに沿い、エージェントのプロンプトまで自ら作成します。そのため、最初のプロンプトを何時間もかけて手作業で書く必要がなく、その日のうちにテストを始められます。
もうエージェントのプロンプトを自分たちで書く必要すらありません。Cursorは過去のデザインに沿って、その日のうちにエージェントを動く状態にしてくれます。
この変化によって、少人数のチームが担える範囲も変わりました。NavanのAIエージェント専任チームから多くのエンジニアが異動した後、以前は2〜3人のエンジニアが複数のスプリントをかけて進めていた機能開発を、1人のエンジニアが引き継ぎました。特にわかりやすい例が、手動での銀行口座連携です。このエンジニアはAngularのフォームをReactで作り直し、それにつなぐバックエンドも構築しました。タスクの必要に応じて、バックエンド専門からフルスタックへと領域を広げたのです。1人で担当するこのワークストリームは、単なる保守作業に終始することなく、新機能の開発に集中し続けられました。
Cursorは、チームメンバーの穴を埋めるときのやり方も変えました。同僚の休暇中、Eltonはよく知らない2つのコードベースを引き継ぐことになりましたが、Cursorが代わりに調査を進め、ログやデータベースのレコードを取得し、Eltonがファイルを1つも開かないうちにIssueの全体像を整理してくれました。
どちらのコードベースにもあまり詳しくありませんでした。『これがIssueだから、解決を手伝って』と伝えると、ログとデータベースを取得して、まるで何か月もそのリポジトリで作業してきたかのように順を追って説明してくれました。
これにより、2つのコードベースのキャッチアップにかかるはずだった約2日分の時間を節約できたうえ、ゼロから学ぶストレスからも解放されました。
レビューは引き続き人が担っています。Eltonはエージェントを何でも答えてくれる万能の存在ではなく、ペアプログラマーとして扱っています。エージェントの実行中はその推論を見守り、誤った前提に気づいたらすぐに修正します。生成されたコードは、他のコードと同じく人とAIによるレビュー、テスト、ステージングのプロセスを経ており、複雑な変更は本番環境に入る前にステージングで確認されます。作業の計画と実行はエージェントが担いますが、判断を下し、最終的なマージに責任を持つのはエンジニアです。
これまでチーム総出でコードベースを凍結しなければ進められなかった移行や並列ワークストリームに取り組んでいるなら、お問い合わせのうえ、Cursorのトライアルを始めてみてください。