CursorとOriginを使ってEC-CUBEプラグインをマイグレーションしてみた話

コード改修は約1分、でもGit操作は意外と時間がかかった

最近、EC-CUBEプラグインのマイグレーション作業で、CursorとCursor Originを使ってみました。

対象は、

• EC-CUBE 4.0系 → 4.1系

• EC-CUBE 4.1系 → 4.2系

• EC-CUBE 4.2系 → 4.3系

といった、バージョンアップに伴うプラグインの改修です。

これまでもAIによるコーディング支援は使っていましたが、今回は単純にコードを書かせるだけではなく、

• 改修プランの作成

• 実際のコード修正

• Gitリポジトリ作成

• main / developブランチ運用

• Pull Request作成

• コードレビュー

まで、かなり広い範囲をAIエージェントに任せてみました。

結論から言うと、

コード改修そのものは驚くほど速い

一方で、

GitやOriginまわりの操作は思った以上に時間がかかる

という、かなり対照的な結果になりました。

Cursorによるマイグレーションはかなり速かった

今回、Cursorでは、

• 思考モード：High

• 速度：Fast

で作業しました。

Highは上から2番目の思考モードです。

この設定で、EC-CUBEプラグインのマイグレーションを依頼したところ、

• 改修プランの提示：約2分

• 実際の改修：約1分

ほどで完了しました。

もちろん、プラグインの規模や変更内容によって結果は大きく変わると思いますが、今回のケースではかなり速かったです。

特に印象的だったのは、

人間が「どこを直す必要があるか」を調査する時間よりも、AIに既存コードを読ませて改修プランを出してもらう方が圧倒的に速い

という点でした。

2つのプラグインをマイグレーションして、Usageの消費も約1％程度でした。

少なくとも今回の規模では、

「AIにたくさん考えさせるとUsageをかなり消費するのでは？」

という心配は、そこまで大きくありませんでした。

ただし、コードが速いからGit操作も速いとは限らない

ここが今回、一番意外だったところです。

コード改修は数分で終わった一方で、Cursor Originを使ったGit操作にはかなり時間がかかりました。

今回行ったのは、

• リポジトリ作成

• mainブランチ作成

• First Commit

• developブランチ作成

• 改修済みソースのPush

• Pull Request作成

• コードレビュー

という流れです。

このあたりをAIエージェントに任せると、

「ソース修正よりGit操作の方が長い」

という、少し不思議な状態になりました。

ただし、これは必ずしも悪いことではありません。

今回は、

• Gitコマンドを実行前に提示させる

• Commit前に確認する

• Push前に確認する

• PR作成前に確認する

• Mergeは勝手に行わせない

という形で、人間が随時承認する運用にしています。

そのため、安全性を優先した結果として時間がかかっている部分もあります。

個人的には、

AIエージェントにGit操作まで任せるなら、多少時間がかかっても、人間が途中で確認できる方が安心

だと感じました。

ここまでは、CursorとOriginを使ってみた全体的な感想です。

ここから先では、

• 実際に各Git操作にどれくらい時間がかかったのか

• main / developをどう運用したのか

• PR作成とレビューにどれくらい時間がかかったのか

• Cursorのコードレビューは本当に使えるのか

• 実際にレビューで不具合を見つけられたのか

• AIにどこまでGit操作を任せるべきか

について、実際の作業結果を交えて紹介します。