新アプリ Mendy のアーキテクチャと技術選定

こんにちは、ウォンテッドリーで Visit AI Squad のリーダーと、Mendy のプロジェクトリードをしている市古（@sora_ichigo_x）です。

はじめに

2026年9月28日に、新アプリ「Mendy by Wantedly」をリリースしました。
Mendy は、転職エージェントとのやり取りを手伝う「あなた専属の転職 AI エージェント」アプリです。

あなた専属の転職AIエージェント Mendy by Wantedly

エージェントとのやりとりを1か所に。届いた求人はAIが経歴と希望条件からマッチ度を診断。返信の下書きまでおまかせ。iPhone・Android対応、無料。

https://mendy.wantedly.com/

今回は、Mendy のアーキテクチャと技術選定をお話しします。LLM を組み込んだアプリを作っている方や、これから作ろうとしている方にとって参考になれば幸いです。

Mendy の技術ストーリーは、これから領域ごとに出していく予定です。今回はその 1 本目として全体像をまとめたもので、個別の設計や各領域の詳しい話は、後続のストーリーで紹介します。

どんな要件なのか

Mendy の要件を一言で表すと「転職エージェントから届くメールを受け取り、LLM で求人を読み取って、マッチ度の診断や返信の下書きを出す」ことだと言えます。

この要件は技術的には、次の 3 つを組み合わせることで実現できます。

• メールサーバー：転職エージェントとのメールを送受信できる
• LLM の処理：メールや Web ページを読み、求人の抽出、マッチ度の判定、返信の下書きの生成を行う
• モバイルアプリ：それらを見て操作する

非機能要件はいくつかありますが、ここでは今回の構成と技術選定に関わるものに絞って紹介します。大きく分けると「少人数で速く開発する」と「安定して運用する」の 2 つで、以降の節ではこの 2 つの判断を紹介します。

少人数で速く開発する

Mendy は新規事業なので、作ってユーザーの反応を見て直す周期をできるだけ短くしたいです。少人数のチームでバックエンドとモバイルの担当を分けてしまうと、どちらかが詰まったときに開発が止まってしまいます。そのため、ある程度は技術領域を越境して開発できる状態を目指しました。

また開発では、メンバー全員が Claude Code などのコーディングエージェントを使っています。そこで、人間だけでなくコーディングエージェントにとっても書きやすいことを、技術選定の条件にしました。

さらに、非同期処理の書きやすさも条件にしました。
LLM の呼び出しやメールの送受信といった Mendy の中心となる処理は、ユーザーの操作と切り離して非同期に動かすことが想定されます。リトライや二重実行、中断再開の考慮を含めて、こうした処理を素直に書けることを重視しました。

安定して運用する

転職エージェントからのメールは、ユーザーにとって絶対に抜け漏れてはいけない情報です。受信したメールは、途中の処理で何が起きても失わないようにする必要があります。

また、LLM の呼び出しは数十秒かかることがあり、外部サービスなので失敗もします。LLM が遅くても失敗しても、アプリの操作が固まったり、処理が止まったままになったりしないようにする必要があります。障害や外部サービスの異常に、ユーザーより先に気づける状態にしておくことも大切です。

アーキテクチャ構成

全体のアーキテクチャ構成は次の図の通りです。

中心となるのは、モバイルアプリ、GraphQL の API サーバー、ジョブを処理するワーカーの 3 つです。バックエンドのプロセス（図の青い枠）は、すべて同じコンテナイメージから起動しており、起動コマンドだけを変えて役割を分けています。

この構成には、前章で挙げた要件に応えるための特徴がいくつかあります。

1. LLM の処理はすべてジョブにする
2. メールサーバーは自前で持たず、マネージドサービス（Amazon SES）に乗る
3. LLM の処理はワークフローを基本にする
4. 障害に備える（エラーは Honeybadger、メトリクスは Datadog、LLM の入出力は Langfuse ）

技術選定

前章の構成の中で特に主要な技術選定についても紹介します。

言語：バックエンド、モバイルともに TypeScript

バックエンドとモバイルは、どちらも TypeScript を採用しています。

コーディングエージェントが書いたコードの誤りを型チェックで機械的に見つけられる点やバックエンドとモバイル間で職種を越境して開発しやすくなる点が主な採用理由です。

また LLM の処理や非同期処理をはじめ、一般的な実装に必要なエコシステムが充実していることも決め手になりました。

コード管理：モノレポ

Mendy は既存プロダクトから完全に切り離すため、既存のリポジトリに実装するのではなく、新しくリポジトリを作りました。リポジトリの中は backend、frontend、mobile の 3 つのワークスペースに分け、1 つのリポジトリにまとめるモノレポ構成にしています。

apps/
  backend/   # Express + Pothos GraphQL
  mobile/    # Expo
  frontend/  # Hono + Astro

こうすることで、コーディングエージェントは同じコンテキストの中でワークスペースをまたいで作業できます。また、リリース前は破壊的変更を加えることを前提にしており、複数のワークスペースにまたがる変更を 1 つの PR にまとめるか分けるかを、状況に応じて調整しやすい点も利点でした。

API 設計スタイル：GraphQL

API 設計スタイルには GraphQL を採用しました。

GraphQL | The API language for humans and agents

GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data.

https://graphql.org/

主な採用理由は次の通りです。

• スキーマ駆動で開発できる
• • スキーマをクライアントとサーバーの間の合意として、同じ語彙と型を共有しながら開発を進められる
• 画面ごとに必要なフィールドを選んで取得できる
• • Mendy は画面とリソースが 1 対 1 に対応しないことが多いが、画面ごとに API を作り直さずに済む
• DataLoader で N+1 問題を防げる
• • 仕組みで防げるので、パフォーマンスとバックエンドの開発速度の両方に効く

また、社内での採用実績があり、新たな学習コストがかからなかったことも理由の 1 つです。

モバイルフレームワーク：Expo（React Native）

モバイルは Expo（React Native）で開発しています。

Expo は Meta の React Native チームが推奨している React Native の公式フレームワークで、React における Next.js のような位置づけにあります。

Expo - Build native apps with React

Expo is the fastest way to build native apps for iOS, Android, and the web with React.

https://expo.dev/

iOS と Android を同時に開発できるクロスプラットフォームのフレームワークの中で、React が分かるエンジニアの学習コストを抑えられる点が主な採用理由です。

実は、Wantedly Visit では 2020 年に React Native を一度導入し、その後リバートした経緯があります。

React Nativeをやめる話とKotlin Multiplatform | Wantedly Engineer Blog

Wantedlyのモバイルエンジニアの久保出です。今回は、Wantedly VisitアプリにおいてReact Nativeをやめる決断をしたこと、関連してKotlin Multiplatfor...

https://www.wantedly.com/companies/wantedly/post_articles/282562

そのため、Mendy で React Native を採用すると同じ問題の繰り返しにならないか、という点は議論になりました。結論として、Mendy では次の理由から React Native を採用しています。

• 既存のコードから切り離し、アプリ全体を React Native で作るので、ネイティブの画面と混ざることがない
• バックエンドとモバイルを同じ TypeScript で書くので、書ける人が限られにくい
• • かつ、コーディングエージェントを使えば、慣れていない技術でも学習のコストを抑えて書き始められる
• 2020 年当時と比べて、React Native およびクロスプラットフォーム技術自体が成熟している

開発を振り返って

Mendy の開発は、バックエンドエンジニア 4 名とモバイルエンジニア 2 名を中心に、最初のコミットから約 4 ヶ月でリリースしました。ほかにも、インフラエンジニア、PdM、デザイナーが協力しています。

振り返ると、言語とリポジトリを揃えた効果は大きく、バックエンドエンジニアのコミットの約 45% がモバイルのコードに及びました。React と同じ考え方で書けるので、新しい言語を覚えるコストもかかっていません。

一方で、スタイリングの土台やネイティブ機能といったモバイル固有の部分は、モバイルエンジニアがほぼ担っていました。言語を揃えれば職種の境目の手前までは誰でも書けますが、その先にはやはり専門性が必要です。

また、スピードを優先してコードレビューを必須にしなかったため、開発は速く進んだ一方で、設計の崩れや重複がたまりやすくなりました。結果的に 8 月にはリファクタリング期間を取り、整理をまとめて行っています。

さいごに

今回は、Mendy の全体像として、アーキテクチャ構成、技術選定、開発の振り返りを紹介しました。

個別の機能の設計や、バックエンド、モバイル、インフラなど各領域の詳しい話は、チームメンバーが今後のストーリーで紹介してくれる予定です。
興味があればそちらもぜひご覧ください。

ウォンテッドリーでは、一緒にプロダクト開発を行うエンジニアを募集しています。
このストーリーに興味を持ってくれた方がいれば、ぜひお話ししましょう！