こんにちは！ Mercari Adsチームのインターン生の@utaです。
本記事では、フロントエンドを中心に経験してきた私が、AIを活用しながらバックエンドを含む機能開発に挑戦した3ヶ月間を振り返ります。インターン中に取り組んだ機能開発を通じて、複数のサービスにまたがる開発の難しさや、AIを活用するなかで得た学びを紹介します。
はじめに
私は2026年7月から9月末までの3ヶ月間、フロントエンドエンジニアとしてメルカリのインターンに参加しました。以前にもメルペイでインターンを経験しましたが、その後、AIの普及によって開発の進め方や日々の業務は大きく変化しました。そうした変化のなかで、メルカリの開発がどのように進められているのかを改めて知りたいと考え、今回の参加を決めました。
これまでの開発経験は主にフロントエンドでしたが、今回はバックエンドを含む機能開発に本格的に取り組みました。以前から、技術領域にとらわれずサービスに必要な開発へ取り組めるようになりたいと考えていたことに加え、AIによって未経験の技術やコードベースを理解するハードルが下がった今なら、経験の少ない領域にも挑戦できるのではないかと考えたためです。
この記事では、主に次の内容を紹介します。
- 商品グループへの価格条件追加
- 課題と実装方針
- 難しかった点
- そのほかに取り組んだこと
- インターンを振り返って
- AIと取り組んだバックエンド開発
- 経験して初めて分かったこと
- 挑戦を支えてくれたチーム
この記事が、メルカリのインターンに挑戦しようと考えている方や、AIを活用した未経験領域への挑戦に関心がある方の参考になれば幸いです！
商品グループへの価格条件追加
私が所属したAds Operationチームでは、広告主が広告の設定や運用を行うためのAds Managerを開発しています。Ads Managerでは、広告グループ作成、クリエイティブ入稿、商品情報をまとめたデータフィードの登録、配信状況や成果の確認、レポート作成など、広告運用に必要な作業を行えます。
今回のインターンでは、その中でも商品グループに価格条件を追加する機能をメインタスクとして担当しました（図1.1）。
図1.1 商品グループの価格条件設定画面
課題
Ads Managerには、商品名や価格などの商品情報をまとめた「データフィード」を登録する機能があります。商品グループは、そのデータフィード内の商品を条件に応じてまとめ、広告として配信する商品を決めるための仕組みです。
これまでは、広告主が商品に付けたカスタムラベルで商品を絞り込めましたが、価格帯では絞り込めませんでした。そこで今回、価格の下限と上限を指定し、その範囲に含まれる商品からグループを作成できるようにしました。一見すると画面に価格の入力欄を追加するだけの機能に見えますが、入力された条件を保存し、対象となる商品を判定して広告へ反映するまでの仕組み全体を変更する必要がありました。
実装方針
実装範囲は、フロントエンド、データベースのスキーマとマイグレーション、GraphQL API、広告を生成するworker、広告を更新するloaderにまたがりました。画面で入力された価格条件は、GraphQL APIを通じてデータベースへ保存されます。広告グループを作成すると、workerが保存された条件を評価して広告を生成します。その後、データフィードによって商品の情報が更新された場合は、loaderが条件を再評価して広告へ反映します（図1.2）。
図1.2 価格条件が保存され、広告へ反映されるまでの流れ
データベースは、既存のカスタムラベル条件を保存する構造を拡張し、条件の種類と価格の下限・上限を保存できるようにしました。価格条件ではカスタムラベルの値を使わないため、既存カラムについて、NULLを許容する定義へ変更しました。また、workerやloaderを含む各サービスでは、条件の種類に応じて商品が商品グループに属するかを判定できるよう、ロジックを変更しました。
難しかった点
難しかったのは、価格を比較するロジックそのものよりも、既存の仕組みをどのように拡張し、複数のサービスへ安全に反映するかを考えることでした。
実装の影響範囲を確認するなかで、ログや監視、パフォーマンス、既存の挙動を含めた動作確認の範囲など、実装時に考慮すべき観点が次々に見つかりました。データ分析用途のBigQueryへのデータ同期のように、追加で必要になる作業もありました。当初は、自分がまだ認識できていない観点や作業まで想像できず、必要な工数を十分に見積もれていませんでした。実装を進めるなかで想定外の作業が次々に見つかり、当初の見積もりが甘かったことを実感しました。リリースとロールバックの設計も、その一つです。
価格条件では、カスタムラベル条件で必須だった値がNULLになります。そのため、価格条件のデータが作成された後にworkerやloaderを以前のバージョンへロールバックすると、値が必ず存在することを前提とした処理でエラーが発生する可能性がありました。そこで、まずNULLを読み取っても処理が失敗しないよう防御的な変更を加えたworkerとloaderを先行して公開し、その後に価格条件へ対応した機能を公開する手順を検討しました。実際に利用されているサービスへ機能を追加する際は、公開までの手順だけでなく、問題が起きた場合のロールバックまで考えて準備する必要があると学びました。
実装やリリースの準備を進めるなかで、最初のデータベース設計が後段の処理に与える影響に気づきました。既存カラムをNULL許容にしたことで、値が必ず存在することを前提にしていた複数のサービスにとっては、その前提を崩す実質的に破壊的な変更になりました。バックエンドやデータベース設計の経験が少なかった私は、設計時点では既存の処理を再利用できることに注目し、後段の処理や動作確認、リリース、ロールバックへの影響まで見通せていませんでした。今振り返ると、既存構造を全面的に作り直さなくても、価格の値だけを専用テーブルへ分ける選択肢を、より慎重に検討すべきだったと思います。この経験から、データベース設計ではコード上の変更量だけでなく、既存データや各サービスが持つ前提、動作確認、デプロイ、ロールバックまで含めて影響を考える必要があると学びました。
そのほかに取り組んだこと
価格条件の追加を進める一方で、インターン期間中には、Ads Managerの利便性や開発環境を改善するタスクにも取り組みました。
広告主による計測タグの導入の手間を減らすため、Ads Managerに「計測タグ」タブを追加しました。これまではガイドを確認しながらパラメータやアカウントIDを設定する必要があり、設定ミスが問い合わせにつながることもありました。今回の対応では、ログイン中のアカウントIDを反映した導入用スクリプトと、商品詳細の表示・カートへの追加・購入といったイベントごとのコードを画面上に表示し、そのままコピー＆ペーストできるようにしました（図2.1）。
実装自体は短期間でしたが、リリース後にはSales teamへの共有、広告主への案内メールの配信、管理画面マニュアルの更新まで進みました。画面の実装だけでなく、複数のチームを通じて広告主へ機能を届けるまでの流れを見ることができました。
図2.1 Ads Managerに追加した計測タグ画面
社内の管理ツールからAds Managerへ移動するリンクを追加した際には、Ads Managerへアクセスできない場合に表示する専用画面がないことに気づき、別のチケットとしてアクセス拒否画面も追加しました。また、リリースノートの作成を支援するツールで著者情報が正しく表示されないケースを見つけ、原因を調査して修正しました。
Ads Managerのテーブル画面では、自動ルール一覧への作成日時の追加、クリエイティブ一覧への入稿日時の追加、横スクロールバーの追従表示など、広告運用時の操作性を高める改善に取り組みました。また、画面遷移や再読み込み後もテーブル画面のソート設定を維持できるよう、設定をsessionStorageへ保存し、画面へ戻ったときに復元する対応も行いました。
そのほか、インターン期間中にSales teamからProduct Managerを通じて届いた要望をもとに、テーブルのカラムに、その指標の意味を補足するツールチップを追加しました。実際の利用者に近いところから上がった要望が、Product Managerによって仕様に整理され、すぐに開発タスクとなって画面へ反映されるまでの一連の流れを経験できたことが印象に残っています。
メインタスクから日々の改善まで、規模や領域の異なる開発を経験できました。ここからは、それらの経験を通じて得た学びを振り返ります。
インターンを振り返って
AIと取り組んだバックエンド開発
今回は、既存コードの調査から実装計画の作成、コードの実装、テストケースの検討まで、開発のさまざまな場面でAIを活用しました。これにより、経験の少なかったバックエンド領域を含む機能開発も進めやすくなりました。
また、複数のサービスの役割を調べるなかで、ORMやデータベースマイグレーション、GraphQL、Pub/Sub、ポーリングなど、分からない概念や処理はその都度AIを使って確認しました。説明を実際のコードと結びつけることで、実装を進めながらバックエンドへの理解も深められました。
今回のように経験の少ないバックエンド領域へ取り組むことは、AIがなければ私には難しかったと思います。AIが実装の大部分を担い、分からない概念や処理の理解にも役立ったことで、経験の少ない技術領域へ踏み出すハードルは大きく下がったと感じました。
経験して初めて分かったこと
一方で、AIを使って実装を進められることと、その変更が十分かを自分で判断できることは別でした。実際の開発では一般的な技術知識だけでなく、既存の設計や過去の経緯、チームで共有されている前提を踏まえた判断も必要でした。価格条件の追加でも、ログ、監視、データ同期、パフォーマンス、リリースなど、チームメンバーとの会話を通じて初めて気づいた観点が多くありました。
振り返ってみると、AIを使って自分で調査を続けられるからこそ、ある程度理解を整理してから相談しようとして、相談のタイミングが遅くなることもありました。この経験から、AIで理解を深めることと、チームメンバーに方向性を確認することは、どちらか一方を選ぶものではなく、状況に応じてバランスよく組み合わせることが大切だと学びました。時間のかかる作業に入る前に方向性を確認したり、調査する時間をあらかじめ決めたりすることも、今後は意識したいです。
今回、バックエンドを含む機能開発に取り組み、実装だけでなく、影響範囲の確認やリリースまでを考える一連の流れを経験できました。この経験を通じて、次にバックエンド開発へ取り組む際は、必要な作業や確認事項を以前より早い段階で想像し、より見通しを持って進められると思います。技術的な判断の基準は、このような経験を重ねるなかで身につくものだと感じました。これからもAIを活用しながら、実装やレビュー、チームとの対話を一つずつ経験として積み重ね、少しずつ自分で判断できる範囲を広げていきたいです。
挑戦を支えてくれたチーム
今回、経験の少ない領域に挑戦できたのは、分からないことを相談したときに、丁寧に支えていただける環境があったからです。相談への回答だけでなく、同じ問題で次に困る人が出ないよう、仕組みそのものも改善してくださいました。
CIでE2Eテストが失敗した際、レポートの見方が分からず相談したところ、確認方法のドキュメントを作成していただいたうえ、失敗時のレポートを自動で公開し、Pull Requestから確認できるようCI自体も改善してくださいました。また、Datadogを使った調査がうまくいかず相談した際には、個人が持っていた知識を整理し、AIが参照できる手順書（Skill）として共有できる形に整えていただきました。
特に印象に残ったのは、困りごとを曖昧なままにせず、すぐに向き合い、個人の経験で終わらせずにチーム全体が使える改善へつなげてくださったことです。そうした姿勢から、Be a Pro、Move Fast、All for Oneが日々の開発に根づいていることを実感しました。私自身が経験の少ないバックエンド領域に挑戦できたことはもちろん、メルカリがGo Boldを実践し続けられる背景にも、互いの挑戦を支える文化があるのだと感じました。
おわりに
本記事では、Mercari Adsチームでのインターンで取り組んだ、商品グループへの価格条件追加やAds Managerの改善、そこから得た学びを紹介しました。フロントエンドを中心に経験してきた私にとって、複数のサービスにまたがるバックエンド開発へ挑戦し、実装だけでなく設計、監視、リリースまで考えた経験は、大きな学びになりました。
このような経験ができたのは、メンターの@dwjさんをはじめ、設計や実装のレビューだけでなく、日々の疑問に向き合い、学びやすい仕組みまで整えてくださったチームのみなさんのおかげです。経験の少ない領域への挑戦を支えてくださったことに、この場を借りて改めて感謝します。ありがとうございました！
現在、メルカリでは複数のインターンを募集しています。この記事を通じて、メルカリでのインターンに少しでも興味を持っていただけたらうれしいです。気になる方は、以下の募集要項もチェックしてみてください！
