こんにちは。メルカリモバイル iOSエンジニアでTech Leadをしています@takeshiです。
この記事は、Merpay & Mercoin Tech Openness Month 2025 の16日目の記事です。
今回は私が業務中に利用したAIエージェントの経験を紹介します。
Cursorを使って未経験のKotlinコードをレビューして、iOS/Androidの実装差分をなくした話です。
メルカリモバイルチームについて
まず私のチームであるメルカリモバイルチームの説明をさせてください。
メルカリモバイルは2025年3月4日にローンチした新しいサービスです。
iOSとAndroid両方提供しています。
現在は2つのチームに分かれていて、両チームともに少数精鋭です。
OS間の実装差分
メルカリモバイルの開発を進めていく中で、課題になっているのがOS間での実装差分です。リリース前のDogfoodingや各プロジェクトのQAフェーズでiOSとAndroidで挙動が違うことがしばしば見つかりました。
- ギガの残り残量が切り捨てなのか切り上げか
- バリデーションチェックの方法
- 画面ロジックのエラーハンドリング
これらの差分は、Specに記載があるがその記述が曖昧で実装者に委ねられていたり、そもそも情報が不足していることに起因しています。
これらの差分は見つけ次第修正していますが、そもそも起こらないようにしたいとも思っていました。
Androidのコードレビューに挑戦
今回、自分がTech Leadとして担当するプロジェクトがあり、技術的なSpecの作成やDesign Docを作りました。実装自体はチーム内の他メンバーが担当です。
Tech Leadとして、コードの品質を守る目的としても「コードレビューをしよう」と思ったわけです。
しかし、私は10数年のエンジニアのキャリアでiOS/Swiftの開発がメインです。
Androidのコードレビューができません。KotlinのコードがSwiftとあまりにも隔たりがあり、コードを読んでもどんな動作になるかの理解が難しいのです。
ただ、メルカリ社内ではAIエージェントの導入が積極的に推奨されていて、私もCursorを使える状態でした。CursorはAnysphere社が提供するAIコードエディタです。
これを使えばなんとかなるんじゃないかと思い試してみました。
Cursor でKotlinレビュー
まずはCursor Rulesで次のようなルールを作りました。
あなたはシニアAndroidエンジニアです。
私はSwift開発者でKotlinの文法に慣れていません。
KotlinやAndroidの質問にはSwiftやiOSで同様の概念を用いて説明してくださいそして、AndroidのPull Requestをチェックアウトし、差分に書かれているコードの文法でわからないことがあったらひたすらCursorに聞くというのを繰り返しました。
例えばこんなプロンプトを打ちました。
packageとimportってkotlinだとどんな意味？するとこんな回答が返って来ました。
Kotlinのpackageとimportについてですね。Swiftと比較しながら説明します。
**package**
Kotlinのpackageは、クラスや関数などのコードをグループ化し、名前の衝突を避けるための仕組みです。Swiftで言うところのモジュール（module）や、より具体的にはXcodeプロジェクト内のターゲット（target）に近い概念と捉えることができます。
**import**
Kotlinのimportは、他のpackageで定義されたクラスや関数などを、現在のファイルで手軽に利用できるようにするためのものです。これはSwiftのimportと全く同じ機能と考えていただいて大丈夫です。
まとめると、
- package: コードの所属グループを宣言する（Swiftのモジュールやターゲットのようなもの）
- import: 他のグループのコードを自分のファイルで使いやすくする（Swiftのimportと同じ）Kotlinを知っている方からすれば何でもないことですが、私はこのレベルで何も知らない状態でした。その他スコープ関数（letやapply）、data classなど、Swiftにはない文法などを聞いてました。
コードを指定して文法含めたコードの処理をCursorに質問すると、それに合わせた解説をしてくれるのでコードの理解が深まりました。
昔だったら文法のキーワードをググって解説のサイトを読み込んでからコードに戻るのを繰り返さないといけないところです。これではいくら時間があっても最終的にしたい「差分コードの理解を深める」に到達できません。
Cursorに聞くことで、時間をかけず、既存のSwiftでの知識を活用してKotlinの概念を理解しレビューを進めることができました。
発見した実装差分の具体例
レビューの過程で、APIのリクエストパラメーターがiOSと異なることに気がつきました。
他の類似した処理とパラメーターをまとめていたのですが、今回のプロジェクトにおけるBE要件としては不要なパラメーターが含まれていました。iOSではすでに、パラメーターを分けて実装していたので、Androidもそのように指摘をし、無事に分けてリクエストを送るように修正されました。
この指摘で、各画面で必要最小限のパラメーターのみを送信するようになり、iOS側の実装と整合性が取れるようになりました。
AIエージェントでレビューをする上でのポイント
レビューもAIエージェントでやればいいんじゃないかという意見があるかもしれませんが、私は反対です。コードレビューはコードの品質を保つ重要な活動で、まだチームのナレッジを100%AIエージェントに伝える手段が確立してないからです。
単純なコードの書き方ならリンターを使えばよくて、それ以上を求めるなら、チームのナレッジを知っている人間がやったほうが早いのが現状です。
また自分のレビューのスタンスとして、Specをコードがちゃんと表現しているかは重視しています。QAで見つかるよりは、レビューで指摘するほうが手戻りがなくて早いでしょう。
チーム内での反応
今回私がAndroidのレビューをAIエージェントを使って行ったことに対して、チームからは好意的なフィードバックをもらいました。Androidメンバーからは「自分もiOSに挑戦したい」という声が上がりました。ゆくゆくは実装も含めて、自分の領域を超えて担当できればいいなと思っています。
まとめ
今回の経験は私の中で、AIエージェントが自分のできる領域を増やせるツールであることを知るきっかけになりました。これまでは全く手が出なかったAndroidのコードレビューに対して、時間をかけず、やりたい成果をあげられたのは大きな進歩です。
「未経験の技術領域は手が出しにくい」と感じているエンジニアの方は多いと思います。しかし、AIエージェントという強力なツールを活用することで、これまで諦めていた領域にも挑戦できるようになります。小さいところから徐々に始めると良いと思います。
私も、次はレビューだけでなく実装にも挑戦したいと思います。
明日の記事は ntkさんによる「メルカリグループの全社的なDevEx改善の仕組みづくり」です。引き続きお楽しみください。
この記事の画像に利用されたAndroid ロボットは、Google が作成および提供している作品から複製または変更したものであり、クリエイティブ・コモンズ表示 3.0 ライセンスに記載された条件に従って使用しています。
