はじめに
こんにちは！メルペイのBalanceチームの中にあるSettlementチームでインターンをしていました、somaです。
この記事は、Merpay ＆ Mercoin Tech Openness Month 2025 の10日目の記事です。
本記事では、インターンでやったことやその感想などを書いていこうと思います。
チームについて
Settlementチームは、主にメルペイの加盟店さまの売り上げを集計し、振り込みの指示を行うといった役割を担当しています。
Settlementのシステムについて詳しく知りたい方は、こちらの記事が参考になると思います。
取り組んだこと
私が担当したタスクは大きく分けて4つあります。
- 既存のAPIの分割
- 決済トランザクションのハンドラの改修
- 新規機能の設計
- お問い合わせ対応の補助をするSlack Botの開発
今回は、太字の3つについて話していこうと思います。
既存のAPIの分割
背景
Settlementサービスには加盟店さまの
- 月に何回売り上げの入金を行うか
- 売り上げの入金を次の月に繰り越すかどうか、繰り越すのであればいくら以下の場合か
などの設定を行うためのAPIが存在します。
しかし、これらの設定がすべて1つのAPIで行われているため、リクエストが重なると片方のリクエストの結果だけが反映されてしまうリスクがあります。そこで、このAPIを各フィールドを変更する複数のAPIに分割することにしました。
やったこと
各マイクロサービス間の通信にはgRPCが使われているため、まずはProtocol BuffersでAPIのインターフェースを定義しました。社内でProtocol Buffersは共通のリポジトリで管理されており、そこにマージすると、Protocol Buffersの内容に基づいて自動生成されるクライアントライブラリにGoのinterfaceなどのコードが自動生成されます。
その後、その中身をマイクロサービスのリポジトリで実装しました。
また、モックも自動生成されてE2Eテスト上で動作確認できるため、わざわざ自分でAPIを叩いて挙動を確かめなくてもテストができるのは開発がしやすいなと思いました。
新規機能の設計
やったこと
新規機能を追加するにあたって、
- どの部分にどのような変更が必要か
- その変更の実現方法の選択肢と、それぞれのメリットデメリットを考慮した上でどの方法を選択するのが望ましいか
- タスクへの切り分けと、それぞれのタスクの見積もり
- QAで確認して欲しいポイント
などを考え、設計書を作成しました。
最初に丁寧に説明をしてもらえるわけではなく、仕様書を読みながら自分でプロジェクトについて理解しながら調査をして、設計に取り掛かりました。その中で、どうしてもわからないことは質問して理解しました。それにより、わからないことを整理し、仮説を立て、調査をして検証するような働き方を身につけることができました。
お問い合わせ対応の補助をするSlack Botの開発
背景
最近のメルカリエンジニアリングブログを見てもわかるように、現在メルカリ社内ではAIをどんどん活用していこうという動きがあります。そこで、Settlementチームでも何かできることはないかと話し合った結果、他部署からのお問い合わせに対する調査や回答をしてくれるBotを作りたいという話になりました。
Settlementチームには、加盟店さまから主に振込に関するお問い合わせが届きます。それに対してエンジニアが調査を行い、回答をしたり追加で質問をしたりするなど、対応を決定します。しかし、毎回データベースやコードから手作業で調査を行って対応をするのはコストが高いです。そこで、お問い合わせに対して、データベースやコードを参照して調査を行い、回答をしてくれるようなBotを作って対応コストを削減しようという試みです。
ただ、システム内部を理解していない人でも簡単にお問い合わせに対する正しい回答を得られるようなBotを作るのは難しいです。また、回答に対してそれが本当に正しいのかを判断できる人が使わないと、誤った回答をしてしまう恐れがあります。そのため、まずはシステムをよく理解しているエンジニアが、調査をSlack上で簡単に行えるようにするBotを開発することになりました。
挑戦前の不安
このプロジェクトを計画した段階で、すでに残りのインターン期間は3週間ほどで、開発に使える日数は10日前後しかありませんでした。さらに、自分はAI Agentの構築, GKE(Google Kubernetes Engine)へのデプロイ, Slack Botの開発などの経験がありませんでした。それによって、開発の全体像が見えず、10日前後で本当に終わらせることができるのか見積もりが困難でした。また、思わぬ困難なポイントが出現する可能性も考えられました。そこで、このプロジェクトに取り組むのではなく、先ほど紹介した新規機能のプロジェクトに取り組んだ方が確実なのではないか？とも思いました。
しかし、2日ほど調査した段階で実現できるだろうと判断したため、不安はありましたがGo Boldにこのプロジェクトに取り組むことに決めました。
やったこと
AI Agentの構築
- 簡単にAI Agentが作れる
- Googleが開発しており、今後BigQueryが組み込みtoolとして導入される動きがあるなど、Google Cloudとの相性が良い
という利点があり、
- MCPサーバと連携できる
- Claudeなどさまざまなモデルを使うことができる
という要件も満たしていたため、GoogleのADK(Agent Development Kit)を使うことにしました。
また、AI Agentがプロダクションデータが同期されているBigQueryとGitHubリポジトリを参照できるようにするために、それらのMCPサーバを使うことにしました。GitHubのMCPサーバは公式のものを使用しましたが、BigQueryには公式のものがなかったので社内で実装されているものを利用しました。
コンテキストは、Markdown形式で
- BigQueryのクエリの例
- 用語と、その情報がSettlementのリポジトリのどのファイルにあるのか
- リポジトリのディレクトリ構造と、それぞれのディレクトリにどのようなファイルがあるのか
- 回答に使用したクエリやファイルを添付するようにするなど、回答のフォーマットの指定
のような情報を与えました。
また、Claudeなどのモデルを使えるようにするために、社内に用意されているLiteLLMのプロキシサーバを使用しました。LiteLLMとは、AnthropicのClaudeやGoogleのGeminiなど、さまざまなモデルをOpenAIのAPIのフォーマットで呼び出すことができるライブラリです。ADKでもLiteLLMがサポートされているため、これを使ってClaudeなどのモデルを使えるようにしました。
GKE上にデプロイ
開発したアプリからコンテナを作成するためのDockerfile, GKEにデプロイするためのKubernetesのマニフェストを作成しました。
ここでは、AI AgentのサーバとGitHubとBigQueryのMCPサーバ、MCPサーバを動かすのに必要なコマンドをコンテナに取り込み、AI Agentが標準入出力を使ってMCPサーバを呼び出せるようにしました。
Slack Botとの連携
次に、Slack BotからのリクエストをGKE上のサーバで受け取り、LLMからの返答をSlack Botにメッセージとして投稿させるようにします。
そのために、APIサーバに以下のようなミドルウェアを実装しました。
- Slackからのリクエストであることを確かめるために、署名による検証を行う
- Slackからのリクエストを受け取り、メッセージ部分を取り出す
- ADKが本来受け取るはずだったbodyの形式にリクエストを変換し、処理を行う
- レスポンスからLLMからのメッセージ部分を取り出し、Slackのメッセージとして送信する
また、インフラ部分も、IngressでHTTPS通信を受け付け、署名検証をすることでセキュアにSlackからのリクエストを受け付けるようにしました。
結果
Slack Botの導入に関する社内の審査を通さなければならないため、インターン期間中に導入まで持っていくことはできませんでしたが、代替としてWeb UIで動作確認をしたところ、お問い合わせに対して以下のように期待通りの調査を行ってもらうことができました。DBの中では数値で管理されているステータスを、きちんとソースコードを読んだ上でその意味まで説明してくれていたり、内部のプロンプトでソースを提示するように指示すると、きちんと回答に使用したSQLクエリやファイルを教えてくれています。
今後の課題
コンテキストとしてより多くのドメイン知識を与えることで、さらに多くのケースに対応できるようにしたいです。また、現在は内部のプロンプトをgitで管理しているため、より簡単に修正を行えるような仕組みにしたいです。
学んだこと
技術面
- Kubernetes
- gRPC
- マイクロサービスアーキテクチャ
- Pub/Sub
- Spanner
のような、今まで深く触れてこなかった技術を使えたのでとても勉強になりました。
特に、Kubernetesは、ずっと勉強したいと思いつつできていなかったので、これを機に本格的に勉強を開始できてよかったです。
また、Slack Botの開発を通して、今まで自分の中でブラックボックスになってしまっていた企業のインフラにしっかり触れられたのはすごく良い経験になりました。
経験面
技術選定や設計、実装の方針などを決める際に、調査〜意思決定まで自分に任せていただけたのは、すごく良い経験になりました。メルペイのインターンではタスクを任された後、基本的には自走して、わからないところがあれば質問をするような方針だったため、自分がタスクやプロジェクトを握っているんだという実感がありました。その中で、技術選定や設計におけるトレードオフなどを考慮して提案し、レビューをもらうようなプロセスを踏むことは１人前に近づくための成長につながりました。また、QAの調整やリリースの周知、他チームへの質問なども自分が行うよう求められ、本当にチームの一員として働くことができました。
タスク以外で取り組んだこと
英語
SettlementチームではGitHub上の会話は基本的に英語で、Slackのやり取りでも英語で話すことがあります。 そのように、インターンを通して英語を使う場面があったため、自分もSlackで英語で話しかけてみたり、オンライン英会話を始めてみたりなど、日常的に英語を使う機会を作る工夫をしてみました。インターン終了後も継続していきたいです。
1on1
キャリアについて考えたり視野や知見を広げる上で、人とたくさん話すのはとても重要だと考えています。そこで、一緒にランチに行った方や、インターンの一次面接をしてくださった方、そうやって話した方のお知り合いなど、いろいろな方に1on1を申し込んで、どのように技術のキャッチアップをしているのかや、なぜ今のキャリアを選んだのかなど、ざっくばらんにお話しました。自分にはなかった考え方や知らなかった知識を身につけることができ、今後の成長のヒントになりました。
突然DMで1on1を申し込んだにもかかわらず、みなさん快く受けて下さりとても感謝しています。
AIの活用
会社がAIの活用を推進しているということで、自分もCursorを使ってみました。特に既存のAPIを分割するタスクでは、基本的に元の実装に倣うため、ほぼ全ての実装をプロンプトを入力するだけで行うことができました。一方で、決済トランザクションのPub/Subハンドラの処理を改修するタスクでは、改修やテストをAgentが正しく実装することはできませんでした。ただ、テストの骨組みさえ作ってしまえば、適切なテストケースの追加はAgentに任せることができました。
また、自分もプライベートでもっとAIを活用できないか？と考えるようになりました。
技術のキャッチアップでNotebookLMを使うようになり、
今まで「名前は結構聞くけど、本腰入れて勉強するほどじゃないんだよな〜」という技術
ドキュメントがあまり好みではない技術
技術的な論文
などを効率的に学習できるようになりました。革命ですね。
また、活用だけでなく、AI関連の技術についても積極的にキャッチアップするようになりました。
社内のコードを漁る
コードを読み進めることで、開発基盤やソフトウェアアーキテクチャなどについて理解を深めることができました。マイクロサービスなので、各サービスの全体像の把握がしやすく、学びやすかったです。インターンではせっかく実際に会社で働けるので、タスクに取り組むだけでなく、自分がこのインターンで学べることは何か？を積極的に考えていくと良いと思いました。
さいごに
以上が、私がインターンで行ったことやその感想でした。
メルペイでのインターンを通して、自分の中でできることや今後のキャリアに向けた視野がグッと広がったと感じています。
２ヶ月間ありがとうございました！！
