はじめに こんにちは。2025年度のBuild@Mercariに参加して、現在はメルカリのCS Tool Teamでインターンをしている@Aokaと申します。この記事では、私がBuild@Mercariに参加した感想や成長したことについて書いていきたいと思います。 Build@Mercariって何？ Build@Mercariとは、これまでさまざまな事情で機会が巡ってこなかった方、特にSTEM分野・IT分野におけるマイノリティである性自認が女性の方々を中心として、スキルトレーニングとインターンシップの機会を提供するプログラムです。 トレーニングの話 選考 Build@Mercariの選考は書類とコーディングテストの結果で進みます。他の多くのインターンシップとは異なり、面接がないのが特徴的でした。 書類審査では、これまでの自分の経験やBuild@Mercariに参加したい理由などを記入しました。コーディングテストについては、プログラミング言語の基礎文法を理解していれば解ける問題が中心で、競技プログラミングのような高度な問題ではありませんでした。 選考は志望理由とコーディングテストの結果を総合的に判断しますが、志望理由が重要視されているそうです。 初日のオリエンテーション 初日のみオフラインでの開催で、メンターや同じチームの参加者とオフラインで交流する機会がありました。また、GitHubを使った課題をみんなで進めて、使い方に慣れることができました。オフラインで交流できたことが二週間のトレーニング期間を通じて心の支えとなり、モチベーションを維持することができました。 トレーニングでやったこと トレーニングではソフトウェアエンジニアリングに必要な基礎知識を一通り学びました。 トレーニング期間中は、5〜6人のチームにそれぞれメンターの方がついてくださる形で、各自が課題に取り組みました。課題の内容は以下の通りで、各STEPを進めながら、最終的にはメルカリのような商品を登録できるWebアプリを作りました。 STEP1 Git STEP2 Setup environment STEP3 Algorithms and Data Structures STEP4 Develop API STEP5 Database STEP6 Writing Tests STEP7 Docker STEP8 Continuous Integration(CI) STEP9 (Stretch) Frontend STEP10 (Stretch) Run multi service EXTRA1 (Stretch) Data Analysis トレーニング内容は公開されており、以下のレポジトリから確認できます。 https://github.com/mercari-build/mercari-build-training/tree/main つまづいた時にメンターの方々にSlackで質問したり、課題の各STEPごとにレクチャーをしてくださったりと、手厚いサポートのおかげで、最後まで楽しく開発を続けることができました。 学んだこと プログラム期間中はたくさんのことを学びましたが、特に以下の知識がついたと思います。 Git, Githubを使ったチーム開発の基礎 Backend開発の流れ DockerやCIなどインフラの知識 このトレーニングを通じての一番の大きな成長は、開発することに対する心理的なハードルが下がったことだと感じています。参加する前は、フロントエンドの開発しかしたことがなかったのですが、フロントエンドからインフラまでの基礎知識を身につけたことにより、新しい技術について学習する際や、開発でつまづいた時にどの領域の知識を深めていけばいいのか判断できるようになりました。 また、プログラムの参加者はUdemy Businessを1年間無料で使うことができます。はじめて学ぶ知識が多いなか、基礎から体系的に学習することができるので、非常に役にたちました。 難しかったこと 実装を始める前に、新しい概念を理解する必要があり、なぜこの技術が必要なのかというところから理解しなければならなかったことが大変でした。理解が浅いまま進めてしまうと、後でつまずくことが多かったため、基礎知識を身につけるためにUdemyの動画を視聴したり、AIとの壁打ちを通じて概念を整理したりして理解しながら進めました。 特に、STEP4のAPI開発では、Python言語を使用してRESTful APIを実装したのですが、デバッグ作業に苦労しました。エラーが発生した際に、どの部分でなぜエラーが起きているのかを特定するのが難しく感じました。しかし、この経験を通じてデバッグスキルの重要性を痛感するとともに、バグに対する耐性もついたと思います。 また、STEP7のDockerの部分が大変でした。初めてコンテナ技術に触れたため、仮想化の概念から始まり、イメージとコンテナの概念、Dockerfileの書き方まで、すべてが新しい知識でした。特に、依存関係の管理は理解するのに時間がかかり、何度もエラーと向き合いながら少しずつ実装を進めました。また、公式ドキュメントを読む大切さも学びました。はじめはとても読みづらく感じましたが、理解するのに大変役に立つことを実感しました。 自身の変化 プログラムを通して、技術力の向上はもちろんのこと、様々な方との関わりを通じて自分自身に大きな変化があったと感じています。 参加者の方々のバックグラウンドは多様で、情報系学部の人に限らず、文系学部や美術系学部の人、また高校生から社会人まで幅広い年齢層の方がいらっしゃいました。私のようにWeb開発が初心者の方も多かったです。 私がこのプログラムを修了できた最も大きな要因は、一緒に切磋琢磨し合える仲間がいたからだと感じています。お互いに教え合いながら頑張る雰囲気がとても心地よく、他の参加者の方々の進捗は良い刺激になりました。 また、プログラムの初日には社員の方々のキャリアに関するプレゼンテーションがあり、直接質問できる機会もいただきました。出産や子育てと仕事の両立、転職に関するお話など、貴重なお話を聞くことができ、自分自身のキャリアについて深く考える時間となりました。 Buildインターンの話 選考 トレーニング期間終了後、一定の基準を満たした参加者は、インターンシップへの応募資格を得ることができます。 選考プロセスでは面接が実施され、主にトレーニングを通じて得た学びや気づき、これまでの技術的な経験、そしてメルカリのバリューに対する理解や共感について質問されました。 選考通過後には、実際のインターンシップ開始前に事前面談の機会が設けられています。この面談では、配属予定のチームについての説明や、不安な点の相談などができるため、安心してインターンシップをスタートすることができました。 やったこと タスクは、カスタマーサポート業務で使用される社内ツールであるCS ToolのPHPで記述されている既存エンドポイントをGo言語とマイクロサービスアーキテクチャで再構築するというものでした。 開発の背景として、CS Toolの多くの機能は古いモノリスなアプリケーションとして運用されています。古いBackendはPHPで書かれており、現在これを保守性の観点などから、新しいマイクロサービスアーキテクチャに移行する取り組みが進められています。 現在CS Toolでは、開発方針として既存機能の移行作業を進めながら、新機能については新しいサービスで開発するというルールがあり、今回私は前者を担当しました。 学んだこと 新しい技術(Go, Kubernetes, gRPC) アーキテクチャの概念が実際のサービス運用でどのように活用されているかを理解することができました。 Test QA Releaseの工程 実際の開発現場での品質管理プロセスを経験できました。単体テストの書き方から、QAのケースの作成と実施、リリースまで一連の流れを学ぶことができました。 コードの可読性を考える 自分だけが理解できるコードではなく、チームメンバー全員が理解できるコードを書くことの重要性を学びました。変数名や関数名の命名、レポジトリ内でコードの一貫性を保つことなど実務で重要なポイントを学ぶことができました。 コードの拡張性を意識する 将来的な機能追加や仕様変更に対応しやすいコード設計について学びました。将来的に、同じエンドポイントに新しいフィルターを追加するなどする時に、コードが書きやすいか考えました。 また、自身が書く部分が既存のエンドポイントの実装と関わっていたり、使う関数が似ていたりするときに、コードを分割したり、まとめたりすることの重要性を学びました。 AIの活用 メルカリでは、AIの活用も積極的に進められており、開発にはCursorなどのAIコーディングツールを使うことができました。ただし、やみくもにAIに頼るのではなく、知識をもった上で、生成されるであろう答えを予想してから入力することで、より効果的にツールを活用することが大切だと学びました。 インターンを通じて、今まで触れる機会のなかった大規模開発ならではの知識や技術を多く学ぶことができました。特に、前述のコードの可読性の点では、コードのみならず、PRやQAシートを作成する際にも、チームの人が理解しやすく、レビューをしやすいかどうかを意識して書くことの重要性を学びました。 またコードレビューを通じて、開発に必要なコードの書き方を具体的に学ぶことができました。自分の実装がベストプラクティスかどうか、様々な視点から評価していただけました。 特に印象的だったのは、単にこの書き方の方が良いと教えていただくだけでなく、なぜその書き方が推奨されるのかという理由まで丁寧に説明していただいたことです。例えば、エラーハンドリングの実装では、ただ起こりうるエラーを処理するだけでなく、適切なログ出力やユーザーが分かりやすいエラーメッセージを考慮する必要があることを学びました。 交流を通じた学び チームでは定期的に勉強会が開催されており、チームに役に立ちそうな技術や知見を積極的に共有する文化がありました。難しい内容も多かったですが、CursorのMCP serverについての回は特に興味深かったです。 チームには地方に住んでいるメンバーも多くいましたが、普段はSlackで通話を繋いでコミュニケーションを取り、定期的に出社日を設けてオフラインでの交流機会を作ったり、チームビルディングイベントを開催したりと、チームのコミュニケーションを積極的に取ろうとされていることが印象的でした。 困った時はいつでも相談に乗っていただき、ペアプログラミングも積極的にしてくださいました。特に、課題がある時に手取り足取り教えるのではなく、私にとってよい学習機会になるようにサポートしてくださったのがとても印象的でした。 また、メンターランチや1on1での社員の方々との交流を通じ、自身のキャリアについて考えるとてもよい機会になりました。新卒入社の方のお話から、他の会社も経験された方のお話まで色々なバックグラウンドをお持ちの方との会話を通じて視野が広がりました。また、これからの大学生活に関して具体的なアドバイスをいただき、残り2年半の大学生活をどのように過ごすのか考える機会になりました。参加してくださった社員の方々に改めて感謝申し上げます。 終わりに 今回のBuild@Mercariとインターンでの経験を通じ、開発に必要な幅広い知識を身につけることができました。また、技術的な面以外でも多くの学びがありました。この半年間で得た学びを糧に、一流のエンジニアを目指して、さらに力をつけていきたいです。 このプログラム期間中、多くの方々にサポートしていただいたおかげで、ここまで成長することができました。Build@Mercariのメンターの皆さんや、インターン期間中にメンターをしてくださった @a-uki さんをはじめとするCS Toolチームの皆さんに本当に感謝の気持ちでいっぱいです。ありがとうございました。 ※この体験記は2025年度（今年度）のプログラム内容です。来年度以降のプログラムにおいては内容が変更になる可能性がありますので、ご了承ください。

はじめに 5月上旬、NATO Cooperative Cyber Defence Centre of Excellence（CCDCOE）が主催する世界最大級のサイバー防衛演習 Locked Shields 2025 が開催されました。今年は 約40 か国・約 4,000 名が参加し、17 の多国籍ブルーチームが国家レベルのICTインフラを防御するシナリオに挑みました。 昨年に引き続き、メルカリは今年もLocked Shieldsに参加しました。今回はセキュリティチームから3人のメンバーが参加しました。本記事では国際共同演習の最前線で得られた知見を共有します。 チーム構成と参加概要 今回次の3名が参加しました。 Yuto Iso:主に日本の防衛対象の全情報システムの保全および重要システムの侵害防止を担当しました。 Hiroki Akamatsu: プラットフォームおよびWebアプリケーションの脆弱性ハンティング・修正を担当しました。 Sana Okumura: 侵害兆候の分析、証跡の確認・報告を担当しました。 メルカリのメンバーは攻撃の兆候の検知・証跡確認、そして脆弱性の特定・修正を行いました。 取り組み内容 Locked Shieldsでは防衛対象の多数の情報システムが高度なサイバー攻撃を受けます。保護対象の全ての情報システムを自動的に調査する仕組みをIsoが開発し、各システムの保護・復旧にかかる労力を大きく軽減させました。これにより、脆弱性の事前特定・攻撃を受けたシステムの迅速な回復に貢献しました。 また、Locked ShieldsではAI機能を含む様々なサービス・認証基盤・ネットワーク、そしてそれらを運用するためのプラットフォームが存在していました。AIやWebアプリケーションおよびコンテナ技術に対応できる人材としてAkamatsuが複数のWebアプリケーションの堅牢化・コンテナの安全なデプロイ構築などを支援しました。 そして、攻撃者は様々な攻撃パターンで情報システムへの侵害を試みます。Okumuraは複数の証跡を確認することで正確に攻撃の影響範囲を特定・報告し、攻撃の検出から封じ込めに貢献しました。 得られた学びと成果 演習内ではそれぞれが自身の専門領域を活かしながら取り組みましたが、Locked ShieldsではOT（Operational Technology）系のシステムなど経験のない領域の攻撃に直面することもあり、学びつつ多数の攻撃からシステムを防衛しました。 また技術面以外でも、様々な専門分野の演習参加者とともに、それぞれの知識や経験を活かしながら、サイバーセキュリティ防衛における円滑なコミュニケーションと協力関係を築く方法を実践的に学ぶことができました。 さいごに Locked Shieldsは他に類を見ないほどの大規模な演習であり、今回の参加もメルカリのメンバーにとって非常に貴重な経験となりました。各メンバーがそれぞれの専門性を最大限に発揮し、各システムへの技術的な支援を横断的に行いました。自動化によるシステム調査・保全、そして複雑な環境下での迅速な脆弱性対応や影響範囲特定といった実践的なスキルを磨くとともに、新たな攻撃手法や防御戦略についても多くの学びを得ました。 特に、国境を越えた多様な専門家との連携を通じて、サイバー防衛におけるコミュニケーションと協力体制の重要性を再認識しました。刻一刻と変化する状況の中で、迅速かつ正確に情報を共有し、共通の目標に向かって協力することの難しさと、それを乗り越えた際の達成感を肌で感じることができました。 本演習で得た知見や経験は、メルカリのサービス全体のセキュリティ強化、インシデント対応能力の向上、そして将来のサイバー脅威への備えに大きく貢献するものと確信しています。メルカリは今後も、このような国際的な取り組みへ積極的に参加し、サイバーセキュリティ技術の向上と、安全・安心なサービス提供に努めてまいります。 出典: https://x.com/ModJapan_jp/status/1920770496632627647

こんにちは。SREチームの @foostan です。 弊社は2025年7月11~12日に開催された SRE NEXT 2025 に、PLATINUMスポンサーとして協賛し、ブース出展およびセッション発表を行いました。本記事では当日の様子とアンケートの収集結果をご紹介します。 ブース出展 弊社としては久しぶりのブース出展であり、私個人としては初めての経験となりました。2日に渡り200人以上の来訪者にお越しいただき、SREに関するお話をたくさんさせていただきました。ありがとうございました。このように共通の話題で盛り上がれる機会は非常に貴重であり良い経験となりました。なお我々のブースでは自由記述形式で以下の2種類のアンケートを行いました。 SREをやっていて良かった瞬間は？ SREに関する業務でAIに任せたいことは何ですか？ 詳細は後述しますが、昨今のAI利活用の盛り上がりはSREの領域でも大きな影響を受けており、当日はAIに関する話題が尽きることはありませんでした。 来訪者やアンケートに答えていただいた方向けにノベルティの配布も行っていました。特にロゴ入りのキーキャップは今回のイベント向けに用意したものでしたが高評をいただけて何よりでした。今後のイベントでも機会があれば配布しようと思いますのでその際は受け取っていただけると幸いです。 セッション発表 弊社の yakenji より、「複雑なシステムにおけるUser Journey SLOの導入」を発表させていただきました。我々がどのような経緯でUser Journey SLOを導入し、これをどのように運用しているのか、また今後の展望について共有しております。 なお本発表の内容は2024年末のブログ https://engineering.mercari.com/blog/entry/20241204-keeping-user-journey-slos-up-to-date-with-e2e-testing-in-a-microservices-architecture/ にも記載がありますので、よろしければこちらもご覧になっていただけると幸いです。 アンカンファレンスへの参加 当日のコンテンツはどれも興味深くさまざまな方の発表を聞いたり、各ブースを巡ってお話を伺うことでSREチームとして今後どうしていくか考えたり、またどのような技術の進歩があるのか考えたりと非常に楽しかったです。特に1日目の最後に行われたアンカンファレンスでは、具体的なテーマごとにグループに分かれてディスカッションを行うことで、各社のこれまでの経験や思いを知る良い機会となりました。 私は「SREとその組織類型」のグループに参加させていただきました。普段はエンジニアリングマネージャーとしてチームや組織編成について考える機会もあるため、SREが組織にどう組み込まれるべきか、過去の事例や現在抱えている問題など、自分の視点からでは見れなかった意見を知ることができました。組織の規模やフェーズ、置かれている状況に応じてSREの組織もそれぞれにあるべき姿が存在することを改めて認識しました。 アンケート結果 我々のブースで行ったアンケート結果をまとめましたのでご参照いただければ幸いです。各結果を同じような内容のグループに分類しそれぞれの割合を出しています。なお記載している内容は公開用に文章を変更しておりますのでご了承ください。 SREをやっていて良かった瞬間は？ 合計で53件の意見をいただきました。 トラブルシューティング: 24.6% 大規模アクセスとなるイベントを無事乗り切った時や障害を迅速に解消できた時の達成感が最も多く挙げられました。難しい障害やボトルネックの特定・解消、原因不明のバグ修正などの技術的な課題を解決した時の喜びも大きいようです。また、インシデント対応フローの改善や開発チームの意識向上など、組織全体の成長を実感できる瞬間も良かった点として挙げられています。 自動化/トイル削減: 21.1% インフラや運用の自動化によって手動作業が不要になったり、高速にデプロイできるようになったことに達成感を感じたという声が多く見られました。コードによるインフラ管理やオートスケーリングの導入、リリースフローの改善などを通じて、生産性向上や自律的なシステム構築を実現できた点が良かったこととして挙げられています。 開発体験向上: 14.0% 開発者から「楽になった」といった声があった時や、生産性の向上を実感できた時にやりがいを感じたという意見が多く寄せられました。開発チーム全体のキャパシティを高める取り組みや、継続的に楽しく働ける環境づくりができていることも、良かった点として挙げられています。 ビジネス貢献: 12.3% コスト削減やリソースの最適化によって、事業への具体的な貢献を実感できたという声が挙げられました。また、ビジネスへの関心・意識の高まりなど、技術面だけでなく事業視点での行動や成果を評価する動きが広がっていることも印象的です。 データ活用: 10.5% トレースやメトリクスの導入により、システムの状態を可視化・定量化できるようになったことが大きな成果として挙げられました。オブザーバビリティの強化やSLI/SLOの導入などを通じて、計測や統計的な判断を行う文化が広がり、データに基づいた改善や意思決定が可能となってきているようです。 SREに関する業務でAIに任せたいことは何ですか？ 合計で100件の意見をいただきました。 インシデントレスポンス: 22.2% インシデントの一次対応やエラー調査の自動化をAIに任せたいという声が多く見られました。またログの収集・要約や過去のポストモーテムとの類似ケースの検索、初動対応の判断支援、インシデントレポートの下書き作成といった業務など、人手による作業の負荷の軽減に期待が寄せられています。 分析/予測: 16.0% 障害やエラーの原因調査、影響範囲の把握、再発防止策の提案といった分析・改善フェーズにおいてAIの支援が期待されているようです。また、アップデートや構成変更に伴う影響調査、さらには事業計画やBillingデータからの将来予測といった業務にもAIを活用したいというニーズが見られました。 アップデート: 11.1% システムやコードの保守や改善に関してAIの活用を望む声が多く挙げられました。特にEOL対応や、アップデート作業の自動化・効率化に対する期待が高まっています。 ドキュメンテーション: 10.5% ポストモーテムや障害レポートなど、定型的かつ情報整理を要するタスクに対してAIの支援を求める声が挙げられました。また、社内向けの説明資料やダッシュボードの自動生成、ドキュメントの検索や要約といった情報の可視化・再利用性の向上に関してもAIへの期待が寄せられています。 モニタリング/アラート: 9.9% アラートのトリアージや原因調査、優先度の判断、リリース後の自動モニタリングや外部サービスの障害速報の把握など、AIによるリアルタイム性と網羅性が期待されています。判断や対応をより迅速かつ確実にし、システムの安定性を高めるための基盤が整えられることが望まれているようです。 おわりに 改めて来場してくださった皆様、また弊社のブースに立ち寄っていただいた皆様に感謝を申し上げます。また本イベントを開催し、運営していただいた皆様も本当にありがとうございました。弊社としても今後の発展に貢献していきますのでまた来年もよろしくお願いいたします。 おまけ: ノベルティーキーキャップの発注方法 今回作成したノベルティーキーキャップについてはクオリティの高いものを製作していただきました。需要は不明ですが、ノベルティーキーキャップの発注については直近ではあまり情報がないようでしたのでこちらにまとめておきます。 今回発注したのはYUZU Keycapsさん( https://yuzukeycaps.com/ )です。こちらでは昇華印刷と呼ばれる方法を利用しており、熱と圧力によって浸透させて色をつけるため耐久性が高く剥がれることもありません。この方法は境界が滲んてしまうことがあるのですがとてもきれいな仕上がりでした。 発注は以下の画面から行えます。 まずはレイアウトを選びます。ノベルティーキーキャップ用のレイアウトは用意されていないので、適当なものを選びカスタマイズしていきます。1Uサイズのものが一般的なのでOrtholinearのものを選ぶとあとの作業が多少楽になります。 「Options」 からレイアウトをカスタマイズできます。今回はすべて同じキーにしたいので 「Add/remove keys」 を選択して詳細の編集画面に移ります。 ここではすべてのキーを自由に選択することができます。各行 R1 ~ R4 も自由に選べます。ノベルティーキーキャップはEscとしてつけることを想定するためかR1であることが多いです。なお今回配布したメルカリのノベルティーキーキャップはMにつけることを想定してR4にしました。 説明用に作成したR1 10×5のものをこちらに置いておきます。 https://yuzukeycaps.com/keyboards/121dfa73-a55e-492c-870a-2b94e490d040 次にキーキャップのテンプレートを作成していきます。ひとつひとつ設定することもできますが、テンプレートを作成しておくと後の作業が楽になります。 後でロゴを配置できるように ICON タイプでテンプレートを作成します。なお、デフォルトのアイコンとしてアップロードした画像を選択することはできないようです。なのでここでは適当なものを選択しておきます。 次にキーを選択して、詳細の編集画面を開きます。「Select icon」を選択するとアイコンを選択する画面になるのでセレクトフォームの右側のアップデートボタンから利用するロゴファイルを選択します。画像の作成方法については下記に説明があります。基本的には2色のみしか使えないので注意が必要です(選べるカラーは豊富にありますが自分で自由に色を作ることもできません)。 https://fkcaps.notion.site/Custom-image-upload-e5e214dc80c047ada20d97d3418eb2de なおこの画面からロゴの位置やサイズの微調整はできますが、同じ作業をすべてのキーに対してすることになるので、ここでは何もせずに済むようにテンプレートを調整することをおすすめします。 あとはひたすらこの繰り返しです。アップロードしたデータはMy Iconsから選択できるようになっているので2回目以降は多少は楽です。なお私が発注したときはjsonファイルで入出力することができたので、jsonファイルを編集してこの繰り返し作業をもっと楽にすることはできましたが、この記事の執筆段階ではそれができなくなっていました。 データが完成したら「ADD TO CART」に進み発注して完了です。データチェック後に製造され、手元に届くのには2~3週間ほどかかりますので余裕を持って発注することをおすすめします。 以上です。ノベルティーキーキャップ作成の参考になれば幸いです。

こんにちは。メルペイQAチームの@uni0110です。 私は6月にスコットランドのエディンバラで開催された EuroSTARカンファレンス に参加しました。EuroSTARは世界的に有名なQAカンファレンスの一つで、今年は4日間にわたり60以上のチュートリアル、セッション、キーノートが行われました。約350社から1000人以上が参加した大規模なカンファレンスです。 テーマはAI on Trial 今年のカンファレンスで最も注目されたテーマはAIでした。参加者との会話でも、「あなたの会社ではAIをどのように活用していますか？」という質問が最も多く、議論が盛り上がりました。 当時、メルペイQAチームは自動化にAIを活用して、それ以外の工程ではさまざまなツールを試している段階でした。そのため、私自身もAIに関するトピックに最も期待していました。 全セッションの半分以上がAI関連のトピックで、内容はそれぞれ異なりましたが、どのセッションも共通して強調していたのは「AIがもたらす効率性や利便性よりも、AIの誤用や不確実性に対する注意」でした。初日のチュートリアルでこれを実際に体験できたので、簡単に共有したいと思います。 Test by Human vs. by AI 初日のチュートリアルでは、人間とAIがそれぞれ同じ内容のテストを実施しました。その結果、人間によるテストではシステムに潜在するバグが発見されましたが、AIが作成・実行したテストケースではバグを見つけることができませんでした。 この違いは、人間だからできる批判的な思考です。人がテストケースを作成する際には、まず仕様を把握し、「どのような改修が行われたか」、「特定のケースではどうなるか」といった疑問があったらチューターに質問し、解決しました。このプロセスを通じて、不要なケースを削除し、必要なケースを追加することで、テストケースを完成させました。 しかし、AIの場合は、どのAIツールを使用しても入力された指示に従ってテストケースを作成するだけで、バグを発見するケースは作成できませんでした。 このことから、優れたQAエンジニアになるためには、クリティカルシンキングに基づいた積極的なコミュニケーション能力が必要であると痛感しました。 QAが見るAI このチュートリアル以外にもAIが持っている以下の弱点のため、AIを使う時は十分気をつけないと行けないという内容のセッションが多かったです。 プライバシー＆セキュリティ バイアス ハルシネーション 不慣れな人による誤用 過度な自動化 ここまでの内容だと、カンファレンス全体がAIに対して批判的な見方をしているように思われるかもしれませんが、どのセッションもAIが作業に役立つツールであることを前提としていたため、Anti-AI的な雰囲気ではありませんでした。 ただ、警戒心を何度も与えた理由は、私達のロールがQAだからです。QAは他のエンジニアロールとは異なり、問題やリスクを発見する役割を担っています。そのため、AIに対しても厳しく警戒心を持たなければ、品質が損なわれる可能性があるからです。 終わりに AIに関するベストプラクティスを期待して参加したカンファレンスでしたが、最後には自分は良いQAエンジニアなのか、もっとできることはないか、といった課題ばかり持ち帰ることになりました。また、QAエンジニアとしてAIに負けない私だけの価値について考え続けています。 しかし、さまざまな場所から参加した多様なQAエンジニアと話す中で、皆が同じ悩みを抱えていることが分かり、良い刺激を受けました。 特にAIについては、単なる便利なツールであり、silver bulletではないことを念頭に置いて活用していきたいと改めて感じました。

Search Infra Teamのmrkm4ntrです。 画像検索にElasticsearchのベクトル検索(kNN検索)を活用しています。しかし、従来のキーワード検索と比較して、同等のリソースで処理できるQPS（Queries Per Second）が大幅に低いという課題がありました。そこで、Elasticsearch 8を基に、kNN検索のパフォーマンスをどこまで改善できるのかを調査しました。 kNN検索の構成と課題 今回の検証で使用したkNN検索のクエリ構成は以下の通りです。 { "size": 100, "query": { "knn": { "image_embedding": { "vector": [ 0.1, 0.2, ... (128次元のベクトル) ], "k": 100, "num_candidates": 100, "filter": { "term": { "status": "on_sale" } } } } } } このクエリは、「status」フィールドが「on_sale」に一致するドキュメントの中から、与えられたベクトル（image_embedding）に類似した上位100件のドキュメントを検索するものです。ベクトルの次元数は128です。 検証当初はElasticsearch 8.12.1を使用しており、async-profilerを用いてCPUプロファイルを取得した結果、以下の箇所がボトルネックとなっていることが判明しました。 特に目立つのは、赤枠で囲まれた jint_disjoint_arraycopy と jlong_disjoint_arraycopy です。これらのメソッドは、 OffHeapQuantizedByteVectorValues.vectorValue から呼び出されており、JVMのヒープ外（つまりファイルシステムキャッシュ上）に格納されているベクトルデータをJVMのヒープ内にコピーする処理を行っています。 Luceneでは高速なkNN検索を実現するためにPanama Vector APIを活用しています。このAPIはベクトル計算でプロセッサのSIMD命令（AVX命令）を使用し、演算効率を向上させるものです。しかし、ベクターデータを一度JVMヒープ内にコピーしてからPanama Vector APIに渡す無駄が発生しているため、パフォーマンスが大きく制約されています。 このボトルネックを軽減する可能性がある修正がLuceneに施されていることが分かりました。具体的にはhttps://github.com/apache/lucene/pull/13339 の変更で、JVMヒープ外メモリから直接Panama Vector APIに渡す実装に改善されています。 Elasticsearch 8.17.1へのアップデートとパフォーマンスの変化 上記の改善が既に含まれるElasticsearch 8.17.1にアップデートし、パフォーマンスを検証しました。 検証環境 Elasticsearch Version: 8.17.1 k: 100 num_candidates: 100 ベクトルの次元数: 128 リアルタイムなドキュメントの追加/更新/削除 フィルタリングの有無と度合いがパフォーマンスに与える影響を評価するため、以下の3つのケースで同一のスペックで捌けるQPSをパフォーマンスとして計測しました。 フィルタなし: フィルタリングなし 緩いフィルタ（loose filter）: 約50%のドキュメントがフィルタ条件に一致 絞り込みフィルタ（selective filter）: 約10%のドキュメントがフィルタ条件に一致 フィルタなしのケースにおいて、async-profilerでCPUプロファイルを再取得したところ、flame graphからPanama Vector APIの痕跡が消え、代わりに赤枠で囲んだ dot7u というメソッドが表示されるようになりました。 これは、Elasticsearch 8.15から、LuceneのPanama Vector APIではなく、より効率的なElasticsearch独自のベクトル化モジュールが使用されるようになったためです ( https://www.elastic.co/search-labs/blog/vector-similarity-computations-ludicrous-speed ) 。この独自実装では、不要なデータコピーはそもそも発生しません。 8.12.1と8.17.1のパフォーマンスの比較は以下です。 8.12.1 8.17.1 フィルタなし 350 450 緩いフィルタ（loose filter） 50 70 絞り込みフィルタ（selective filter） 30 40 Elasticsearch 8.17.1にアップデート後、全体的にパフォーマンスが改善しましたが、フィルタありのケースでは依然としてフィルタ無しのケースと比べるとパフォーマンスが低い状態です。 絞り込みフィルタリング時のHNSWグラフ探索の最適化 絞り込みフィルタ（selective filter）を適用した場合のCPUプロファイルを確認したところ、赤枠で囲まれた部分の HNSWGraphSearcher.search の処理時間が大幅に増加していることがわかりました。 これは近傍のノードをチェックする際に、類似度の計算を行わず、諦めて次をチェックする回数が増加していることを意味します。 つまり、HNSWグラフの構造上、フィルタ条件に合致するドキュメントが少ない場合、グラフのリンクを効率的に辿ることができないために発生する問題です。類似度が高い方向にグラフを探索しても、フィルタ条件に合致するドキュメントが見つからない場合、大きく迂回したり、戻ったりする必要が生じ、探索効率が低下します。 この問題を解決するために、ACORNと呼ばれるアルゴリズム( https://arxiv.org/pdf/2403.04871 ) が提案されており、様々なベクトル検索エンジンが採用しています。Luceneのupstreamでも、ACORN風のアルゴリズムが実装されているため、このPR ( https://github.com/apache/lucene/pull/14160 ) をcherry-pickして試したところ、特に絞り込みフィルタの場合に大きなパフォーマンス改善が見られました。 8.17.1 8.17.1 + ACORN フィルタなし 450 450 緩いフィルタ（loose filter） 70 80 絞り込みフィルタ（selective filter） 40 120 とはいえ、緩いフィルタ（loose filter）の場合はあまり改善されていません。 緩いフィルタリング時のBitSet合成の最適化 緩いフィルタ（loose filter）を適用した場合のCPUプロファイルを確認したところ、赤枠で囲んだ部分である AbstractKnnVectorQuery.createBitSet の処理時間が大部分を占めていることがわかりました。 フィルタが固定で、kNN検索に指定するベクトル値のみを変更している場合、フィルタの結果のBitSetはクエリキャッシュに保存されるため、フィルタ自体のコストはほぼ無視できるはずです。 コードを解析した結果、createBitSetメソッド内で、フィルタのBitSetとliveDocsのBitSetを合成した新しいBitSetを作成していることが判明しました。LuceneのSegmentはimmutableであるため、削除されたドキュメントを管理するために別のデータ構造（liveDocs）が必要になります。liveDocsもBitSetで表現されており、フィルタのBitSetとliveDocsのBitSetを合成する際に、BitSetの中身をiterateしていました。緩いフィルタの場合、フィルタ条件に合致するドキュメントが多いため、この処理に大きなコストがかかっていました。 しかし、グラフを辿る際に、見つけたドキュメントがフィルタに合致するかをチェックするだけであれば、BitSetを合成する必要はありません。また、カーディナリティ（BitSet内で1が立っているビット数）を計算する場合も、iterateして合成する必要はなく、FixedBitSetのintersectionCountメソッドを使用することで高速に計算できます。 これらの点を修正した結果、特に緩いフィルタを使用した場合のパフォーマンスが大幅に改善しました。 8.17.1 + ACORN 8.17.1 + ACORN + BitSet合成最適化 フィルタなし 450 450 緩いフィルタ（loose filter） 80 200 絞り込みフィルタ（selective filter） 120 170 この修正はLuceneのupstreamにPRとして送りました( https://github.com/apache/lucene/pull/14771 ) 。しかし、その少し前に追加されていた修正 ( https://github.com/apache/lucene/pull/14674 ) にて改善されていたためこのPRは不要でした。正確には、このPRそのものはcherry pickして試していましたが、 applyMask の非default実装は別PRで対応されていたため、それを見落としていました。 FieldExistQueryによるパフォーマンス低下の解消 改善後のCPUプロファイルを確認したところ、依然としてcreateBitSet内の Lucene99ScalarQuantizedVectorsReader$QuantizedVectorValues.advance の処理時間が残っていました。 これは、フィルタにLucene内部で追加されるFieldExistQueryによるものであることがわかりました。インデックス内のすべてのドキュメントにkNNの対象となるベクトルフィールドが存在するわけではない場合、その存在をチェックする追加の処理が必要になります。今回のケースでは、埋め込み処理でエラーが発生した場合にベクトルが存在しないドキュメントが存在していました。 これらのドキュメントをインデックスに含めないように修正したところ、パフォーマンスがさらに改善しました。 8.17.1 + ACORN + BitSet合成最適化 8.17.1 + ACORN + BitSet合成最適化 + FieldExistQueryの除外 フィルタなし 450 450 緩いフィルタ（loose filter） 200 250 絞り込みフィルタ（selective filter） 170 200 一般にFieldExistQueryは対象のドキュメントのfieldを全てチェックする必要があるため高コストです。FieldExistQueryと今回のフィルタはQuery Cacheの対象のため全てのドキュメントをチェックしているわけではないはずですが、Query Cacheの対象とならないようなサイズのセグメントのみが対象だったとしても、緩いフィルタの場合は高コストであったと考えられます。 さいごに Elasticsearch 8のkNN検索において、フィルタリング時のパフォーマンスを改善するために、以下の施策を実施しました。 Elasticsearch 8.17.1へのアップデート: Elasticsearch独自のベクトル化モジュールを使用することで、フィルタなしのケースにおけるパフォーマンスを向上させました。 ACORN風アルゴリズムの導入: 絞り込みフィルタ適用時のHNSWグラフ探索を最適化しました。 BitSet合成の最適化: 緩いフィルタ適用時のBitSet合成処理を効率化しました。 ベクトルフィールドの存在チェックの排除: ベクトルフィールドが存在しないドキュメントをインデックスから排除することで、不要な存在チェックを削減しました。 これらの改善により、フィルタリングの有無に関わらず、kNN検索のパフォーマンスを大幅に向上させることができました。以下が最終的な結果です。 改善前 改善後 フィルタなし 350 450 緩いフィルタ（loose filter） 50 250 絞り込みフィルタ（selective filter） 30 200 ベクトルフィールドの存在チェック以外の改善は将来のElasticsearchのリリース(9.0.4以降?)に含まれる予定です。 これらの改善は、ElasticsearchのkNN検索をHybrid Searchなどに活用し、より高度な検索サービスの提供に繋がるものと考えています。

こんにちは。メルペイ Payment Core Teamで2ヶ月間インターンシップをした@taichiです。 この記事は、 Merpay & Mercoin Tech Openness Month 2025 の22日目の記事です。 はじめに 私は4月の中旬から6月の中旬の間、 バックエンドエンジニアとしてメルペイのインターンシップに参加しました。今回はインターン期間中に取り組んだタスクを振り返り、 そこで得た学びをまとめたいと思います。 この記事が、 メルペイのインターンに挑戦してみたいと考えている未来のHackerの参考になれば幸いです。 取り組んだタスク 私が担当したタスクは大きく分けると3つあります。 外部パートナーへの接続に関するCredentialの管理方法の変更 Re-arch中のソースコードへのPub/Sub基盤統合 個人情報難読化ポリシーの実装 以下で1つずつ話していきます。 外部パートナーへの接続に関するCredential管理方法の変更 背景 私が所属するPayment Coreチームでは、決済基盤マイクロサービスである『Payment Service』の開発を担当しています。このサービスは、メルカリ、メルペイ、メルコインが展開する多数のマイクロサービス群から参照されており、グループ全体の決済ドメインにおけるコアな責務を担っています。 メルペイでは決済機能の一部で外部パートナーさまのAPIを活用しているため、そのCredentialを適切に管理する必要があります。 私がタスクに取り組むまでの運用では、 新しく追加したCredentialを暗号化しSpannerにSQL raw queryを叩くことで保存していました。 従来の運用方法は以下に示す危険性と面倒さを有しています。 加盟店追加のたびにSQLクエリを叩く必要がある 加盟店追加後にSQLクエリを発行し忘れる可能性がある やったこと 上記の課題を解決するために、 以下のような設計と実装を行いました。 外部パートナーの加盟店さまのパスワードの格納先をGoogle Secret Managerに変更 Spannerに直接パスワードを保存せず, SecretのKeyとVersionだけを格納する Secretの情報を入力として渡すだけで, SQLが走ってSecretのKeyとVersionをSpannerに保存するK8sのJobテンプレートを作成 SecretManagerを通して加盟店さまのパスワードを取得できるようにClientCodeを修正 最初はCLIを作ってチームに提供することも考えましたが、 メンテナンスの負荷が新たに発生すること、 K8sのJob基盤がすでにチームに存在することを理由にCLIは避けました。 K8sのJobテンプレートはこちらが参考になると思います。 インターンに参加して1週間くらいで設計を行いドキュメントを作成したのですが, 設計書のレビューが手厚くチームメンバーと技術的な議論を繰り返すことでタスクやPayment Serviceの全体像を掴むことができました。 Re-arch中のソースコードへのPub/Sub基盤統合 背景 私が所属していたPayment Coreチームが開発しているPayment Serviceは、そのソースコードが非常に複雑なため、大規模な再構築プロジェクト、通称「Re-arch（リアーキテクチャ）」が進められていました。 このRe-archプロジェクトの目的は、既存のPayment ServiceのソースコードをClean Architectureのような設計思想に基づいて書き直すことです。 現状のPayment Serviceでは、非同期処理のためにGoogle Cloud Pub/Subが利用されています。しかし、Re-arch後の新しいソースコードには、Pub/Subを利用するための基盤がまだ整備されていない状況でした。 やったこと 私はRe-arch後のソースコードのコンテキストにマッチするようにPub/Subの基盤を統合しました。 Pub/Sub基盤の設計は、 Payment ServiceがPub/SubからSubscribeしか行わないことを前提にメンターと進めました。 Subscriberに渡すHandlerのInterface設計や、 Usecaseに渡す依存関係を一括で管理するContainerとの親和性を考慮して設計する経験は非常に勉強になりました。 Re-archのPRは変更が大きいものもあるので、 Conflictの解消やContextを理解し直すのに苦労したこともありましたが、 あれほど大規模なソースコードを読むこともないのでとても良い経験になりました。 開発体験としても、 Payment ServiceではMockの生成は moq.go を使っているので、 interfaceだけ設計すればMockを簡単に生成できるので、 素早くTestableなコードを書くことができました。 個人情報難読化ポリシーの実装 背景 個人情報保護法の改正を受け、メルペイ全社で「PII Deletion（個人情報難読化）プロジェクト」が進行中です。これに伴い、Payment Serviceもこの対応を行う必要がありました。 個人情報の難読化はメルペイ全体で取り組むべき課題であるため、すでにそのためのマイクロサービス「PII Deletion Service」が構築されていました。 しかし、Payment ServiceからPII Deletion Serviceを叩きに行くことができない状態でした。 やったこと PII Deletion Serviceのアーキテクチャは下図のようになっています。 上図を解釈すると, 処理の流れとしては以下になります。(Payment Serviceは上図における右端に位置すること, 各マイクロサービスはgRPCで通信を行うことを念頭においてください) PII Deletion Managerから難読化すべき個人情報の情報がPub/SubにPushされる Payment ServiceがPub/SubからPullして難読化する対象を見つける 難読化する 難読化が成功したかのステータスをPII Deletion Managerに返す 1はすでに仕組みとして存在するので、 私は2-4を実装すれば良いことに気づきます。 以下ではステップ2についてどのように対応したかを述べます。(3、 4はそこまで難しいことがないのでスキップします。) Pub/SubからPullして難読化対象を見つける PII DeletionのHandlerはRe-arch後のソースコードに実装するので、 私が統合したPub/Sub基盤を使用すればすぐに実現できるので簡単に思えます。 しかし、 Pub/SubのSubscriberが行う処理をそのまま記述しようとすると2点好ましくない点があります。 普段慣れ親しんでいるgRPCエンドポイントと異なる体験で開発しないといけない Subscriberのロジックが他のAPIのロジックから独立しがち これらの課題を避けるために、 メルペイはPub/Sub gRPC Pusherという内製化サービスを持っています。Pub/Sub gRPC Pusherの仕組みは簡単で、 以下のようなアーキテクチャになります。 gRPC Pusherはマイクロサービスの代わりにPub/SubからPullし, gRPCリクエストに変換してマイクロサービス側のエンドポイントを叩いてくれます。 gRPC Pusherを使うことでメルペイのエンジニアは、Pub/SubのSubscriberロジックを慣れ親しんだgRPCエンドポイントとして実装でき、Pub/Subという特定のInfrastructureを意識しなくて良くなります。 今回はこちらのgRPC Pusherを利用するためのInfrastructureリソースをTerraformで作成し、 個人情報難読化を行うロジックはgRPCエンドポイントとして実装を行いました。 ただ、gRPC Pusherを使うならいろいろと考えるべきことがあります。 Pub/SubのPull型Subscriptionの大きな利点は、Pullする側のスケールやワークロードの都合に合わせて処理を実行できる点にあります。gRPC Pusherはその都合をPullするマイクロサービスの代わりに受け持っていると考えることもできます。 Kubernetesをはじめとしたスケーリング技術は、必要になった時にすぐにスケールするわけではないので、ワークロード量によってはgRPC Pusherの使用は適切でない場合もあります。しかし、PII Deletionのリクエストはスケールが追いつかないほど大量のリクエストが飛んでくることは想定し難いため、gRPC Pusherの使用を決断しました。 全ての個人情報を難読化するところまでは完了できませんでしたが、 基本的なロジックは全て実装し終えました。 学んだことと感想 ハード面 使用した技術としては以下です。 Kubernetes Terraform Google Cloud (Pub/Sub, Secret Manger, Spanner) gRPC Go どの技術も触ったことはあったものの深く触ったことはなかったので勉強になりました。 特にTerraformには興味があるので、 大学院の研究が落ちつく7月は何かしらのProviderを自前で実装するつもりです。Kubernetesに関しても基本的な概念やリソースの役割のみならず、 カスタムコントローラの実装等、 面白い部分はたくさんあるのでこれからさらに深く勉強していこうと思います。 また、 Payment Serviceのソースコードは大規模かつ複雑だったので読み解くのに苦労しましたが、 パフォーマンスと冪等性を意識した設計になっているのでとても勉強になりました。 ソフト面 インターンを通して自身の英語スキルが向上したと感じました。 Payment Coreチームでは、 チームのStandupも月曜日から木曜日は全て英語で行われます。 また、私が参加していたPII Deletion ProjectのMeetingやGitHub上のやり取りも基本全て英語ですし、最終成果発表も全て英語で行いました。普段の業務から英語と身近に触れられたことは自身の成長に大きく繋がったと感じています。 それから, チームメンバーはもちろん、他のチームの方々ともコミュニケーションを積極的にとることも心がけました。チームメンバーはもちろんのこと、他チームの方々も私に親切にしてくださり最終成果発表にも参加してくださいました。 インターンシップを通じてメルカリのカルチャーを存分に味わえて本当に楽しかったです。 メルカリグループは全社的にAI活用を推進しており、私も積極的にAIを活用しました。私は以前からAIを使ってソースコードを生成することに違和感を覚えていました。 Junior EngineerはIntermediate、 Seniorとタイトルを上げていく必要があります。タイトルはエンジニアの各ソースコードのレベルだけで決まるわけではないですが、当然相関はあります。Juniorである私がAIを使ってソースコードを書いてしまったら、成長する機会がなくなりいつまで経っても自らのスキルが伸びないのではないか？と考えていました。 ですが、Payment Serviceの莫大なドメインと複雑なソースコードを理解するには到底2ヶ月では足りないため、効率の良いキャッチアップが必要です。チームメンバーに相談してみると、彼らは皆AI（Cursor）を使って効率よくドメイン知識を吸収したり、UnitTestを書いたりしていました。彼らの助言を受けて私もインターン中にCursorを徹底的に活用し、AIと協調して、今までよりもより本質的な作業に時間を使えるようになりました。 AIを使用しても出力されるコードや価値は本人の能力にキャップされるため、依然として強くなるために勉強は必要です。 私が最初に抱いていた違和感は今でも間違っていないと思います。 しかし、成長する機会は自分でいくらでも作り出せるので、仕事と成長をイコールで結ばず両方全力で取り組めば、より早く、より大きな価値を届けられるエンジニアになれると考えを改めました。 インターンを通して最も大きく変わった部分はここだと思います。 最後に チームメンバーをはじめ、たくさんの方々にお世話になりました。 メルカリのカルチャーを存分に体感しながら技術的に難しい課題に取り組まさせていただき、本当に感謝しています。 2ヶ月間ありがとうございました。

こんにちは。メルカリモバイルのソフトウェアエンジニアの @keiitaj です。 この記事は、 Merpay & Mercoin Tech Openness Month 2025 の21日目の記事です。 概要 本記事は、2025年6月16-17日に日本で初開催されたKubeCon + CloudNativeCon 2025 Japan の参加レポートです。 この記事の内容： 日本初開催のKubeConイベントレポート 注目セッション Envoy拡張用Wasmフィルタのローカル環境上のデモ実装 執筆者の学び： EnvoyとWebAssemblyを活用したAPI管理手法を実際に実装することで、セッションで得た知識をより深く理解できました。また、参加前は技術的ハードルが高いと感じていましたが、実際は職種やレベルを問わず楽しめるイベントであることを発見しました。 目次 はじめに 参加の動機 イベントの規模と熱気 注目したKeynote & Session 参加して感じたこと おまけ：Envoy + Wasmフィルタのデモ実装 まとめ はじめに 私は普段、Platform Engineerではなく、KubernetesやCloud Nativeの技術で構成された基盤の上でサービス開発を行うエンジニアとして、Tekton、Argo、Istio、Envoyなどを使って仕事をしています。 参加の動機 技術的な興味 業務でKubernetesやCloud Nativeの技術（Tekton、Argo、Istio、Envoy、Spinnakerなど）に日々触れる中で、これらの技術の最新動向やコミュニティの活動に強い興味を持つようになりました。 また、AI技術の進化により、サービス開発エンジニアがPlatform構築により深く関わる機会が増えていくと感じました。 そのため、Cloud Nativeエコシステムの全体像を把握しておきたいという思いもありました。 日本初開催の歴史的なイベント CNCF（Cloud Native Computing Foundation）の主要イベントとして世界各地で開催されてきたKubeConが、日本で初めて開催されることも参加の大きな動機となりました。 実は、この日本開催実現までには長い道のりがあったそうです。 以前、5月に開催されたCloudNative Daysで、Linux FoundationのNoriaki Fukuyasu氏による KubeConを日本に招致するまでの経緯 についての講演を聞く機会があり、その内容がとても印象的で、今回のKubeCon参加のきっかけの一つにもなりました。 Fukuyasu氏の話によると： 2023年以前、日本はクラウドネイティブ技術後進国と言われていた 大企業での採用実績が少ない アジャイル、マイクロサービス、コンテナを知らない人が多数 Cloud Native Community Japan を立ち上げ、月に複数回のmeetupを開催 継続的なロビイング活動を通じて、ついに日本への招致に成功 このような背景を知ったことで、日本初開催のKubeConに参加することの意義をより深く感じるようになりました。 イベントの規模と熱気 会場と参加者 会場となったヒルトン東京お台場で開催されたこのイベントは、1,500枚のチケットが完売し、日本のCloud Nativeコミュニティの盛り上がりを肌で感じることができました。 ちなみに、今年ロンドンで開催されたKubeConは12,418人が参加する 大規模なイベント でしたが、日本開催はコンパクトながらも内容の濃いイベントでした。 イベントの楽しみ方 KubeConの魅力は、単にセッションを聞くだけではありません。初参加で感じた楽しみ方をご紹介します： セッション参加 ： スケジュール を見て、興味のあるKeynoteやセッションに参加 ブース巡り ：セッションの合間に、OSSパビリオンや企業ブースを訪問 OSSプロジェクトの開発者と直接話す貴重な機会 最新プロダクトのデモを体験 各社のノベルティグッズ収集 企業ブースでの発見 各企業ブースを回ることで、最新のプロダクトやサービスの動向を直接確認できました： PagerDuty AIエージェントが過去の対応履歴を基に、インシデントの原因分析や重要度判定を支援 Splunk Observability Cloudの新機能を展示、AIチャット機能による差別化を強調 Toyota コネクテッドカーの研究開発でCloud Native技術を活用し、自動車業界でもCloud Nativeが浸透していることを実感 注目したKeynote & Session Opening Keynote： Community Opening Remarks Community Opening Remarks – Chris Aniszczyk氏（CNCF CTO） 開会の挨拶では、以下の印象的な発表がありました： 1,500枚のチケットが完売したことへの感謝 CNCF、Kubernetesへのコントリビューションで日本がTOP10入り 2026年も日本でKubeConを開催することが決定！ 日本のCloud Nativeコミュニティの成長が認知されていることを実感しました。 技術セッション： Full Lifecycle API Management in Kubernetes With Envoy and WebAssembly 特に印象に残ったのは、 Full Lifecycle API Management in Kubernetes With Envoy and WebAssembly というセッションです。 セッションの概要 KubernetesにおけるAPI管理の課題に対して、EnvoyとWebAssembly（Wasm）を活用した革新的なアプローチが紹介されました： L3/L7プロキシ機能の統合 JWT認証とルーティングによる高度なAPIトラフィック管理 eBPFとOpenTelemetryを活用したオブザーバビリティの向上 WebAssemblyフィルタの活用 複数言語での開発が可能 より高速な配布時間 ランタイムでのセキュリティロジックの実装 実践的なデモ Authorizationヘッダーのチェック機能をWasmで実装 認証なしのトラフィックをブロックする仕組みの構築 技術的な洞察 このセッションで特に興味深かったのは、WebAssemblyの用途が拡大していることです。元々はブラウザ上でのパフォーマンス向上のために開発されたWebAssemblyが、今やサーバーサイドのプラグイン機構として活用され始めています。 参加して感じたこと 技術トレンドの観察 イベント全体を通じて感じた技術トレンド： OpenTelemetry + eBPF ：オブザーバビリティ関連のセッションで頻繁に言及 WebAssembly ：サーバーサイドでの活用事例が増加 AI統合 ：各種ツールにAI機能が標準装備 コミュニティの多様性 印象的だったのは、専門的な内容から初心者向けまで幅広いセッションが用意され、ライトニングトークやパネルディスカッションでは専門以外の話題（コミュニティでの友達作りやコントリビューションのモチベーションなど）も語られていたことです。 参加のハードルが高いイメージがありましたが、実際は職種やエンジニアのレベルを問わず、誰でも楽しめるイベントであると感じました。 言語の壁と対策 Keynoteやセッションは全て英語で行われるため、英語が苦手な方には少しハードルが高いかもしれません。 私がとった対策は、Google Meetのマイクでスピーカーの音声を拾い、Geminiに議事録を作成してもらって内容を把握することでした。 Google Docsの音声入力は途中で音声が途切れると入力がストップしてしまったり、AppStoreに公開されている幾つかの音声の書き起こしアプリは有料でさらに時間制限があったりしたので、色々試行錯誤した結果、この方法が一番良かったと感じました。 また、参加した仲間とセッションの内容を共有し合うことで、理解を深めていました。 効率的な参加のコツ 同一時間帯に複数のセッションが開催されるため、私は興味のあるセッションを絞って参加しましたが、複数人で参加する場合はより効率的な立ち回りができると感じました： 手分けして異なるセッションに参加 Coffee Breakで情報交換したり、お互いにセッション内容のメモを共有 おまけ：Envoy + Wasmフィルタの実装とローカル環境のデモ KubeConで紹介されたEnvoyとWebAssemblyによるAPI管理の技術についてより深く理解するため、実際にEnvoyを拡張するGolang製のWasmフィルタを実装し、ローカル環境上で動作確認を行いました。 実装の詳細やソースコードは、 GitHub で公開しています。 デモの概要 このデモでは、Bearer トークン認証を行うWasmフィルタを実装し、以下の機能を備えています： Bearer トークンによる認証機能 /health エンドポイントの認証スキップ 認証成功時のカスタムヘッダー追加 認証失敗時のJSONエラーレスポンス 実装のポイント 1. 使用技術・ツール Envoy : v1.34-latest以降 Go : 1.24以降 (wasip1/wasm target) proxy-wasm/proxy-wasm-go-sdk : Wasm plugin development SDK for Envoy 2. シンプルな認証ロジック package main import ( "github.com/proxy-wasm/proxy-wasm-go-sdk/proxywasm" "github.com/proxy-wasm/proxy-wasm-go-sdk/proxywasm/types" ) func main() {} func init() { proxywasm.SetVMContext(&vmContext{}) } type vmContext struct { types.DefaultVMContext } func (*vmContext) NewPluginContext(contextID uint32) types.PluginContext { return &pluginContext{} } type pluginContext struct { types.DefaultPluginContext } func (p *pluginContext) OnPluginStart(pluginConfigurationSize int) types.OnPluginStartStatus { proxywasm.LogInfo("plugin started") return types.OnPluginStartStatusOK } func (*pluginContext) NewHttpContext(contextID uint32) types.HttpContext { return &httpAuthContext{contextID: contextID} } type httpAuthContext struct { types.DefaultHttpContext contextID uint32 } func (ctx *httpAuthContext) OnHttpRequestHeaders(numHeaders int, endOfStream bool) types.Action { // Get path path, err := proxywasm.GetHttpRequestHeader(":path") if err != nil { proxywasm.LogErrorf("failed to get path: %v", err) path = "/" } proxywasm.LogInfof("Processing request to path: %s", path) // Skip health check if IsHealthCheckPath(path) { proxywasm.LogInfo("Health check endpoint, allowing request") return types.ActionContinue } // Get Authorization header authHeader, err := proxywasm.GetHttpRequestHeader("authorization") if err != nil { authHeader = "" } // Validate token authResult := ValidateToken(authHeader) if !authResult.IsValid { proxywasm.LogWarnf("Authentication failed: %s", authResult.Reason) return ctx.denyRequest(authResult.Reason) } // Add user type header proxywasm.LogInfof("Valid %s token", authResult.UserType) proxywasm.AddHttpRequestHeader("x-auth-user", authResult.UserType) return types.ActionContinue } func (ctx *httpAuthContext) OnHttpResponseHeaders(numHeaders int, endOfStream bool) types.Action { proxywasm.AddHttpResponseHeader("x-wasm-filter", "go-auth") return types.ActionContinue } func (ctx *httpAuthContext) denyRequest(reason string) types.Action { body := CreateErrorResponse(reason) err := proxywasm.SendHttpResponse(401, [][2]string{ {"content-type", "application/json"}, {"x-wasm-filter", "go-auth"}, }, []byte(body), -1) if err != nil { proxywasm.LogErrorf("failed to send response: %v", err) } return types.ActionPause } ローカル環境でのデモ Docker Composeを使用してローカル環境で動作確認を行えるようにしました： Client → Envoy Proxy (Wasmフィルタ) → Backend Service 以下の3つのシナリオで動作を確認できます： 認証成功 : 正しいBearerトークンでのリクエスト 認証失敗 : 無効なトークンでのリクエスト 認証スキップ : ヘルスチェックエンドポイントへのアクセス 学びと今後の可能性 このデモ実装を通じて、Envoy Wasmフィルタの実用性と多くのメリットを実感できました： Wasmフィルタの主要メリット 言語の自由度 – Go、Rust、C++など慣れ親しんだ言語で開発でき、既存のツールチェーンを活用可能 安全性 – Wasmのサンドボックス環境で実行されるため、Envoyプロセスをクラッシュさせるリスクが低く、メモリ安全性も保証 パフォーマンス – ネイティブコードに近い実行速度を実現 配布とバージョニング – 単一の.wasmファイルとして配布でき、バージョン管理やデプロイメントパイプラインへの組み込みが簡単 特に実際のプロジェクトでは、既存のGo/Rustコードベースがある場合、同じ言語でプロキシレイヤーのロジックを実装できることが大きな価値となります。 認証、ログ処理、メトリクス収集などのビジネスロジックを統一言語で管理でき、JWT検証やレート制限、OpenTelemetry連携など、より高度な機能への拡張も現実的です。 まとめ 初参加したKubeCon + CloudNativeCon 2025 Japanは、日本のCloud Nativeコミュニティの盛り上がりを実感できる貴重な体験となりました。 技術面では、EnvoyとWebAssemblyを活用したAPI管理手法が特に印象深く、実際にWasmフィルタを実装してローカル環境でデモを動かすことで、セッションで学んだ概念をより深く理解できました。また、OpenTelemetryとeBPFを組み合わせたオブザーバビリティ技術や、WebAssemblyのサーバーサイド活用、AI統合の進展など、Cloud Native技術の進化を直接体感することができました。 また、参加前は技術的なハードルが高いイメージがありましたが、実際は職種やエンジニアレベルを問わず楽しめるイベントであることも発見できました。多様な参加者との交流や企業ブースでの最新技術の体験も、魅力だと感じました。 来年2026年の日本開催も決定しており、Cloud Native技術に興味がある方にはぜひ参加をお勧めします。 本記事で紹介したセッションの動画は、 CNCFの公式YouTubeチャンネル で公開されています。興味のある方はぜひご覧ください。

こんにちは。メルペイで機械学習とAIのチームのEMをしている@hiroです。 この記事は、 Merpay & Mercoin Tech Openness Month 2025 の21日目の記事です。 メルカリ、メルペイでは生成AIの活用を非常に積極的に推進しています。今回の「Merpay＆Mercoin Tech Openness Month 2025」においても、自然発生的に多くのメンバーが生成AIをテーマに選択しており、これは会社全体でのAI活用の機運の高まりを示していると感じています。従前からAIの取り組みはありましたが、会社としてのコミットメントの深まりとエンジニアを含むメンバーたちの熱量が高くなっており、数々のプロジェクトが生まれています。 この記事ではその中から、CXOの@naricoと共に推進している「PJ-Aurora」（プロジェクトオーロラ）について共有します。 Design/Creative x AI 2024年のメルカンの記事『 「Must」を「Fun」に！メルカリCPOとCXOが語る、“AI-Led Growth Company”としてのAI活用の未来 』にも書かれていますが、以前より「pj-ai-creator」を立ち上げ、デザイン領域における生成AIの活用について実験的な取り組みを行ってきました。PJ-AuroraはAI Creatorを経て正式に立ち上がったプロジェクトです。 PJ-Auroraは生成AIの活用を通じて、メルカリ、メルペイにおけるものづくりのアプローチを変革し、よりMove Fastにアイデアを実現してお客さまに届けることができるようになることを目指しています。あしもとでは特に、アイデアからのUI生成や評価、UXシミュレーション工程のプロセスイノベーションに挑戦しています。 とはいえ、基盤モデルの性能が日毎月毎に改善されていく中、生成AIを使って達成できることは何か、という問いの答えも変わり続けています。私たちも常に学習し続け、期待値とスコープを更新し続ける必要があると認識しています。 アイデアからUIを生成する プロンプトからUIを生成するタスクは生成AIの発展とともに流行しているタスクの一つで、Figma社のFigma Makeをはじめさまざまなサービスが生まれています。メルカリでは各サービスの試験的な利用もしつつ、Agentic Workflow（複数のAIエージェントが連携して作業を進める仕組み）を構築し、独自のUI生成プロセスを構築する営みも並行して進めています。 このタスクは昨今、精度向上が目覚ましく、正直なところ、最終的には内製のシステムではなく外部のサービスを使う形になるかもしれません。しかし、この取り組みを通じて得られる知見と資産は、AI時代における競争優位性の源泉になると考えています。 AI時代のデザイン資産 たとえば、デザインシステムは人間のデザイナー/エンジニアが理解し活用するために作られていることが多いですが、AI時代においては「AIが理解し活用できる形」での資産化が重要になってくると思います。 構造化されたデザイン言語 : ブランドアイデンティティやデザイン原則をAIが解釈可能な形で体系化 AI-Friendlyなデザインシステム : コンポーネントやパターンをMCP（Model Context Protocol）等を通じてAIが参照・活用できる状態に整備 ドメイン特化の知識ベース : 特有のUXパターンやユーザー行動をAIが理解できる形で蓄積 これらの資産は、外部サービスだけでは実現困難な「メルカリらしさ」を保ちながらAI活用を進めるための基盤となります。仮に将来的に外部サービスを利用することになったとしても、これらの構造化された資産は他のAIツールとの連携や、独自のワークフロー構築において価値を持ち続けると想定しています。 一方、基盤モデルを利用するだけで高精度のUI生成が可能になった場合、外部サービスを利用するのではなく、メルカリ内部のシステムやワークフローに接続しやすいようにあえて「基盤モデルのAPIを使った内製のUI生成システム」に着地する可能性もありえるかもしれません。 UI生成の実装の概要 いくつかのコンセプトから構成されていますが、ここでは2つのAgentを紹介します。Agentic Workflowの実装は現時点では、GoogleのADK（Agent Development Kit）を使っています。 コンセプトリファインAgent UI生成Agent コンセプトリファイン UI生成ツールのユーザーが記述した機能やサービスのアイデアを、UI生成Agentに入力するためのデータ（プロンプト）に変換するための機能です。基盤モデルの性能向上によって簡単な指示でもある程度の品質のUIを生成してくれるようになりつつあります。一方で、実現したいことや作りたいもの、制約等をよく言語化し、構造化することの価値は変わらず高く、生成されるものの品質を大きく左右すると感じています。 以下は実装のイメージです。 def create_concept_refinement_agent() -> LlmAgent: """ ユーザーのコンセプト案をブラッシュアップするためのシンプルなLlmAgentを作成します。 """ return LlmAgent( name="ConceptRefinementAgent", model="gemini-2.5-pro-preview-05-06", description="ユーザーのデザインコンセプト案を受け取り、より詳細で具体的なアイデアにブラッシュアップするエージェント。", instruction=( "あなたはデザインコンセプトを具体化・洗練させるAIアシスタントです。\n" "ユーザーから与えられたコンセプト案を読み、**それを元に最大限具体的で魅力的なコンセプト案を生成してください。**\n" "生成する際は、以下の点を考慮・推測し、具体的に記述してください:\n" "- **ターゲットユーザー:** (例: 20代後半のテクノロジーに関心のある都市部在住者)\n" "- **解決する課題/提供価値:** (例: 煩雑なスケジュール調整をAIで自動化し、自由な時間を創出する)\n" "- **コア機能/体験:** (例: 自然言語でのイベント登録、参加者の都合の良い時間を自動提案、ビデオ会議連携)\n" "- **差別化要因:** (例: 業界特化のテンプレート、独自のレコメンデーションエンジン)\n" "- **雰囲気・トンマナ:** (例: ミニマルで洗練されたデザイン、直感的でスムーズな操作感)\n" "- **具体的なUI構造:** (例: イベント登録するためのフォーム、参加者の都合の良い時間を提案するカレンダー)\n" "**ユーザーに質問を返さないでください。\n" "**与えられた情報からコンセプト案を構築し、完成したコンセプト案のテキストのみを返してください。\n" "**前置きや挨拶、説明は不要です。" ), tools=[], sub_agents=[], ) UI生成 以下がプロンプトをもとにHTMLでUIを生成するAgentのサンプルコードです。 既出のセクションにも書きましたがUI生成はさまざまなサービスが生まれており、群雄割拠です。前述の通り最終的に内製のAI Agentをさらに作り込んでいくかどうかはわかりません。一方、生成ロジック以外の要素、例えば自社のデザインシステムをAIからReadableな状態にすること、デザインのアイデンティティやコンセプトを言語化・構造化すること、AIを前提としたアプリ制作のワークフローを発明すること等は、組織の資産であり、独自性であり、差別化要因になりうる点だと想像しています。 def create_page_generate_agent_v0_3(model_name: str) -> LlmAgent: """HTML生成エージェントを構築します。""" mcp_toolset = get_ds_mcp_tools() html_generation_agent = LlmAgent( model=model_name, instruction=""" ユーザーのアイデアを基にデザインを新規生成してください。 特に指示されない限りはスマホアプリのデザインを生成してください。 メルカリのデザインシステムに厳密に従った高品質なHTMLを生成するため、以下のステップを順守してください。 **ステップ1: デザインシステム参照画像の確認** メルカリのデザインシステムに準拠した表現を行うため、関連するコンポーネントやパターンの参照画像を必ず確認してください。 - `mcp_get_ds_master_image_map` ツールを呼び出し、利用可能なDS Master Imageのカテゴリと画像のリストを取得します。 - ユーザーの要求や生成する画面のコンテキストに合致する画像があれば、その画像の `category` と `filename` を引数として `mcp_get_ds_master_image_details` ツールを呼び出し、詳細な説明と画像URLを取得します。 - 取得した画像URLは、必ず `download_and_save_image_as_artifact` ツールを使用してその内容をシステムに読み込ませ、実際に画像を確認してください。 - これらの参照画像を十分に確認し、スタイル、レイアウト、インタラクションなどがメルカリのデザインシステムに沿っているかを確認した上で、HTML生成に活かしてください。 **ステップ2: アイコン・ロゴ素材の利用** アプリケーションで使用する汎用的なアイコンやロゴは、必ず `mcp_get_image_asset_map` ツールを使用して画像アセットのURLリストを取得し、そこから適切なものを選択してHTMLに埋め込んでください。 **ステップ3: HTML生成と出力** 上記のステップで得られた情報と、以下の「基本デザイン情報」を総合的に判断し、HTMLを生成します。 - **出力形式:** 純粋なHTMLコードのみを出力し、他の説明やコードブロックは含めない。完全な HTML コードのみを出力してください。説明や ```html ... ``` は不要です。 - **単一ファイル:** CSS/JavaScriptは外部参照せず、`<style>`タグや`<script>`タグで内部に埋め込む。 プレースホルダー画像 ユーザーアイコンや商品画像のプレースホルダーが必要な場合は、`get_random_sample_image_url` ツールを使ってください。 **画像のURLをmcpやツールで取得した場合：** 1. mcpやツールから取得したURLの画像を処理する必要がある場合 (例: 画像の内容を説明する、画像から情報を抽出する、画像に基づいて何かを生成する)、まず `download_and_save_image_as_artifact` ツールを使用して画像を取得し、システムに保存してください。 2. このツールを実行すると、システムが自動的に画像を読み込み、あなたがその内容を理解できるようになります。 3. もし画像URLへのアクセスにMCPの認証が必要だと判断される場合は、ツールの `use_mcp_auth` 引数を `True` に設定してください。それ以外の場合は `False` に設定してください。 """, name="HtmlGeneratorAgent", description="Generates a single HTML page based on user idea.", output_key="generated_html", tools=[ get_random_sample_image_url, check_link_status, download_and_save_image_as_artifact, mcp_toolset, ], before_model_callback=before_model_load_artifact, ) return html_generation_agent UI/UX評価の取り組み 以上はUIを生成する仕組みの一端ですが、並行して、生成されたものをUI/UXの観点で評価する仕組みの構築にも取り組みはじめています。品質評価観点を定め、仮想的なペルソナを生成し、自動生成されたUIにフィードバックをします。 静的な画面の評価に加えて、Browser Use等を用いて画面操作をさせつつ、フィードバックを獲得していく仕組みです。全体のイメージとしては、Amazon社の「 UXAgent: An LLM Agent-Based Usability Testing Framework for Web Design 」のような構成で、AIによるUX評価の概念実証に着手しており、納得性の高いフィードバックを得られるケースも確認できています。 UI生成については内製のフロントエンドがあるのですが、UI/UX評価に関してはCursor等のエージェントを使いながら小さく開始しています。有用性が確認できたら、どういう実装であるべきか、アプリ開発のワークフローの中でどう使っていくのが有効かを検討していきたいと考えています。 おわりに PJ-Auroraの取り組みを通じて、生成AIの可能性と課題の両面を実感しています。技術の進歩は目覚ましく、UI生成の精度は日々向上していますが、同時に「何を作るか」「どう作るか」「私たちの仕事の仕方はどう変わるか」という本質的な問いに向き合うことがより重要になってきていると感じます。 メルカリでは引き続き、お客さまにより良いサービスと体験を提供するために、新しい技術と向き合いながら開発をしています。生成AIという新しい道具を使いこなすために、私たち自身も学び続けていきます。

こんにちは。メルペイ Payment & Customer Platform Manager of Managers の @abcdefuji です。 この記事は、 Merpay & Mercoin Tech Openness Month 2025 の19日目の記事です。 要旨 2024年末から2025年6月の半年間で、メルカリではAIツールの導入において劇的な変化を遂げました。数十名から始まったパイロットプロジェクトが、わずか4ヶ月で1,100アカウントを超える全社規模の導入に成功しました。エンジニアの9割以上がAIコーディングアシストを活用する組織へと変貌しています。 この記事では、エンジニアリングマネージャーの視点から、組織変革の成功要因を分析し、技術負債解消への新しいアプローチや個人の開発体験の変化について紹介します。特に、トップダウンのビジョン、ボトムアップの自発性、環境整備、そして可視化による推進力の4つの要素がどのように組み合わさって変革を実現したかを詳しく解説します。 始まりは一つのリクエストから 2024年末の状況 全ての始まりは、同僚からの「Cursorを使ってみたいのですが、導入可能でしょうか？」というシンプルなリクエストでした。 当時のメルカリには、既にAI Code AssistsツールとしてGitHub Copilotが導入されていましたが、実際の利用状況は以下の通りでした： 一部のアーリーアダプターである数十名〜100名（weekly active user）規模で利用されている しかし、多くのエンジニアが「まだ使うには早い」と感じている状況 高度なコンテキスト理解が不十分で、単一ファイルや行単位の修正提案が主流 プロジェクト全体を理解した提案には至らず、AIアウトプットの質がプロダクション開発に適応できていない状況 正直、私自身もGithub Copilotを使っていましたが、開発の現場で本格的にAIを活用するレベルには程遠いと感じていました。 転換点：2025年2月の承認 Cursorは2024/04〜07頃に一度検討されましたが、当時は導入の判断には至りませんでした。 しかし、2025年2月、会社として本格的なAI導入の承認が下りました。数十名のパイロットプロジェクトとしてCursor導入がスタートしました。 初めてCursorを触った時の感動は今でも鮮明に覚えています。特に印象的だったのは、Cursorの「コードのインデックス化」機能でした： プロジェクト全体のコンテキスト理解 既存のパターンを学習した文脈に沿った提案 大規模リポジトリでのコード理解スピードの向上 まだ数万行を超える巨大なリポジトリでは不安定さや上手く機能しない場面もありましたが、主にオンボーディングの側面でスピードが爆速になりました。マネージャーである自分はコードへのコミット機会が減りつつありましたが、Cursorを使ってどの機能がどのように実装されているか非常に容易に特定できるようになりました。 爆発的普及の4ヶ月間 驚異的な成長 2月から6月現在までの数字を見ると、その変化の大きさが分かります： (図: Cursor Usage Summary) アカウント数 ：数十名 → 1,100アカウント超 エンジニア利用率 ：9割以上が何らかのAIコーディングアシストを活用（Cursor以外にもJetBrains AI、Google Code Assist、Claude Codeなど） 普及範囲 ：エンジニアからPdM、デザイナーまで拡大 社内の熱量の変化 数字以上に驚いたのは「熱量」でした。3月から5月の間、社内で起こっていたことは以下の通りです： 毎週複数のAI関連イベントが社内で開催 一つのイベントに100名以上の参加者がいるケースも エンジニアだけではなく、PdMなどの別職種への広がり 社内のオフライン、Slack上で聞こえる会話がAI一色に染まっていきました。 (図: 社内AI開発支援ツールについて語ろう企画) 「隣のチームでCursorの勉強会やるらしい」 「今度MCPについて話すイベントやります」 「AIで○○を楽にしました」 エンジニアから始まった波は、さまざまな職種の人たちにも広がっていきました。マネージャーとして、この自発的な学習意欲の高まりを目の当たりにできたのは本当に感動的でした。 成功の4つの要因 この爆発的な普及を振り返ると、4つの要因が絶妙に組み合わさっていたことが分かります。 1. トップダウンの明確な意志 経営層からの「AIを活用していく」というメッセージは、単なる推奨ではありませんでした。会社の未来への投資であり、明確なビジョンの表明でした。トップが本気だからこそ、現場も本気になれる。その土台があったからこそ、後に続く変化が可能になったのです。 そしてそれを推進するリーダーがいました。私はCursor導入を担当しましたが、Cursorだけではなく、エンジニア職種を超えて生成AIを導入する非常に強いリーダーシップが社内にモメンタムを生み出しました。 2. ボトムアップの自発的な情熱 トップダウンが生み出したモメンタムをさらに加速・継続させたのは「Move Fastな人たち」の存在でした。通常、組織変革では推進役を各チームに配置し、計画を立て、ロードマップを作成しますが、今回のCursorに関しては以下のような声が、あちこちから自然発生的に生まれました： 例として メルカリモバイルのAI Hackathon PCP LLM Week アーリーアダプターがいる。挑戦する文化がある。そして何より、学んだことを共有したがる人たちがいたことにより推進が大きく加速しました。 3. 環境の整備 このモメンタムの維持には環境整備を支えてくれたチームも大きな要因です。CursorだけではなくさまざまなAIツールが登場し、社内で利用したい声が多く上がりました。Cursorもここまでの人数規模が利用できる状態にするために社内のプロセス整備が行われました。ワンボタンでアカウント申請できる仕組みや、新規ツール導入時のセキュリティレビュー・予算レビューなどのさまざまなプロセスを、一体となって環境整備をしてくれました。 Cursorにおいては、Slackから簡単にアカウント発行までできるように調整していただきました。 (図: Cursorアカウント発行アナウンスメッセージ) 4. 可視化という触媒 最後の要素は、「ダッシュボード」による可視化です。 (図: Cursor Dashboardn) (図: Devin Dashboard) CursorをはじめDevin、Claude Code with LiteLLM、GitHub Copilotのダッシュボードを用意し、チームがどのくらいAIを使っているかを可視化しました。これにより、使いこなしているチームとまだ利用頻度が高くないチームを把握し、それぞれの背景を深掘りしていくことで、さらなる浸透のためのアクション定義につなげました。 可視化による競争ではなく、「触発」が生まれました。同僚の活用方法を見て学び、自分なりの使い方を発見する。そんなポジティブなサイクルが会社全体に広がりました。 チームレベルの開発における変革 ここからは組織ではなく1チームの開発状況の変化に関して話します。 技術負債への新しいアプローチ AIの導入が進む中で、私たちのチームに予想外の変化が起こりました。 私たちPayment & Customer Platformチームは、リリースから6年以上が経つシステムです。6年間、さまざまなプロダクトチームからの要求に応え、機能を追加し、時には妥協しながら成長を続けてきました。その結果、技術負債が蓄積されていました： 従来の課題： yak shaving状態：積み重なった実装・複雑な仕様により、一つの小さな改善に大きなコストが伴う課題 改善系のタスクの優先度が低く、時間が確保できず放置された課題 AI（Cursor / Claude Code）による変革： 大規模な内部リファクタリング・リアーキテクチャのような優先度が低く設定されやすいタスクの解消スピードが向上 ルール・コンテキストの共有による一貫性のある修正が可能 これまで「いつかやろう」で終わってしまいがちだった大規模な改修プロジェクトに、以前よりも継続的かつ素早く技術負債解消できる可能性が出てきたと感じています。 今後への展望 さらなる活用領域の拡大 – 開発だけではなく、開発プロセス全体でAIを活用していく仕組み作り（ One Person, One Release ） PMもEngineerも壁を越えていきます。一人の人が企画から開発、QA、リリースまで一気通貫で出来ることを目指します。 技術の壁を越え、ドメイン知識を越え、役割を越えて行くためのAIの活用とし、それらを使い熟すのです。 標準化 – 個人やチームの知見や開発手法の横展開していく仕組みづくり 例えば、CLAUDE.mdをどのように作成し、どのようなルールを記載しているか、どのようにドメインを表現しているか、チームによって独自に進化が進んでいます。それぞれのチームがAIによってさらなる生産性を得るために、導入や利用のプロセス自体の標準化を行いたいと考えています。 このAIトレンドのスピードの中で、さまざまな手法が即座に古くなっていくと思います。古くなったものを即座に捨て去る覚悟を持ちつつ、AIを活用し生産性を向上させていく未来への道のりを作り始めています。 まとめ この半年間で、メルカリはAIツールの導入において以下を実現しました： 組織的な成功 ：1,100アカウントを超えるユーザーへのCursor導入 文化的な成功 ：自発的な学習・普及文化の醸成 成功の鍵は、トップダウンのビジョン、ボトムアップの自発性、環境整備、そして可視化による推進力の組み合わせにありました。AI時代の組織変革において、技術導入だけでなく、文化と人の変革が重要であることを改めて実感しています。 最後に この目まぐるしい変化に楽しく向き合えているのは、周りの同僚たちの存在です。 毎日のように新しいツール、開発体制、ユースケースなどのインプットとアウトプットする機会に溢れており、AI関連の情報交換は純粋に楽しく刺激的でした。この「集合知」でAIに対して前向きに挑めています。 以上、ありがとうございました。 明日の記事は cyanさんです。引き続きお楽しみください。

Design System チームの engineering manager をしている vwxyutarooo です。 私達はメルカリのアプリ・ウェブ開発に利用している Design System をフルリニューアルしました。 この記事で Design System に抱えていた問題とそれをどのように解決しようとしているのか、そのコンセプトを紹介していきます。 既存の Design System に抱えていた課題 既存の Design System は社内で 3.0 と呼ばれており、 GroundUp と呼ばれるメルカリのアプリとウェブを刷新するプロジェクトの一部として2020年頃からデザイン・開発が始まりました。 3.0 と聞くと随分進んでいるように見えますが、様々な開発背景により特定プラットフォームを対象にしたものや、日の目を浴びることのなかった過去のバージョンなどが含まれており、実質 3.0 が全社的に取り組んで開発された最初の Design System v1 となっている背景があります。 おおよそ 5 年の運用期間を経て、3.0 で作られたコンポーネントは当初の利用想定ケースを大きく超える状況に対処する場面が多く見られるようになりました。その結果、多数の新規機能開発で Design System のコンポーネントでは表現できず、シンボルをディタッチして変更を加えたコンポーネントや社内でカスタムコンポーネントと呼んでいる非公式のコンポーネントが多数作成される事態に陥っていました。 なぜこのようなことが起こったかを、ItemObject と呼ばれているコンポーネントの例を用いながら簡単に解説します。 これは複数のスクリーンで頻繁に使用されるコンポーネントです。3.0開発時は共通と思われるパーツだったため単一のコンポーネントとして切り出され、いくつかのユニークな要素をプロパティによって表示・非表示を切り替えることで対応していました。社内ではこれを polymorphic API と呼んでいます。 しかし 3.0 リリース後の継続した機能開発により必要な要素は増え続け、必要とされる表示パターンは増え続けました。 この方式の難しいところは個別の UI 最適が進むほど考慮すべき組み合わせパターンが倍に増えていく点です。さらに、特定の要素 A が表示されているときに出現する要素 B or C のように構造が深くなっていき、複雑さが増していきます。私達はこの構造をコンポーネントの Polymorphic API と定義し避けるべきコンポーネントデザインと考えています。 この状況を打開するため、コンポーネントの定義を刷新し異なるコンセプトで Design System を4.0として再構築することにしました。 Atomic Design Methodology 新しいコンポーネントの設計指針として Atomic Design を採用することにしました。古くから存在した概念で、2013年に Brad Frost によってそのアイディアが初めて提唱されたものです。 Atomic Design – Brad Frost Atomic Design は旬をすぎたものとして扱われるようになって久しいですが、これは多くの場面で誤解のもとに運用されたり、拡大解釈されたりすることで、本来意図していない利用をされていることが大きいと考えています。 Brad Frost: Is Atomic Design Dead? – Hatch Conference Berlin 2023 よくある誤解として Atomic Design を実装リードで適用しようとしてしまう、或いは実装でのみ実現しようとしてしまう例がよく見られます。 私達の解釈では、Atomic Design は Design System を開発・運用するデザイナーとエンジニアのためのコンポーネント設計フレームワークであり共通言語です。実装が Atomic Design を強く意識する必要はなく、利用者に強調すべき情報でもありません。 Atomic Designでは、UIの部品を最小単位の「atoms(原子)」に分解し、それらを組み合わせて「molecule(分子)」のようなより大きな部品を構成します。以前は一つの部品として扱っていたものを、複数の小さな部品に分割して組み立て直す考え方です。 Atomic design によるコンポーネントの分解・設計手法に関しては Brad Frost 本人を含む多くの解説記事や動画が存在するため詳細は省略しつつ、先程紹介した Item Object を 4.0 の考え方で構築した例で簡単に紹介します。 まずセオリー通り各コンポーネントをその役割の最小単位にまで分割していきます。 以下の画像の例も、3.0 では1つのコンポーネントとして扱われていましたが、4.0 は 2 つの atoms と呼ばれる最小単位のコンポーネントになります。そしてこれらのパーツを組み合わせてさらにパーツを構成します。この atoms から構成されるコンポーネントを molecule と呼びます。 これを繰り返し、最終的にバラバラのパーツから ItemObject などのよりハイレベルなパーツを構築可能にします。前提として UI をパーツで組み立て可能にするという点を念頭に置きつつ、組み立て後のパーツが汎用的なコンポーネントであるものを molecules や organisms として提供します。 ItemObject のようにユースケースが細かく別れているコンポーネントに関しては使用頻度の高い汎用的なものを優先的に Design System のコンポーネントとして管理しつつ、利用シーンが多くないものや僅かな要素の違いを持つユースケースにはあえて organisms として完成形を提供せず、利用シーンで組み立てるようにしています。 コンポーネントを利用時に組み立てる、というのも場合によっては利用者の負担になります。そのため、組み立て方法の例をレシピ/設計図として配布し補助的に活用しています。 レシピ/設計図を提供するかどうかは、コンポーネントの利用頻度やコンテンツ/コンテキスト依存度から判断しますが、レシピや設計図 (Blueprint) に関しては Atomic Design とは異なる概念となるため次の節でもう少し詳しく紹介します。 Component Design Strategy Atomic design は Design System のコンポーネントの分解・構築のためのフレームワークを提供しますが、なにがコンポーネントであるべきか、どんなコンポーネントが Design System として管理されるべきかその境界を示してはいません。 私のチームでは Design System から内向きのレイヤーを Atomic Design で、外向きのレイヤーを自分たちで独自に設計しました。次の図はそのレイヤーを簡易的に表現したものです。内側に行くほど Design System で、外側に行くほど Design System ではなくなります。厳密に Design System チームの持ち物として責任を追うのは青の領域ですが、現実的にはっきりとした境界線を引けることは稀で、その境界はグラデーションになっていることが多いため、そのグラデーションを意図してこのような図で表現しました。 1つ1つのレイヤーを順番に解説していきます。 Snowflakes ワンオフコンポーネント。コンテンツやコンテキストに依存しているなどの理由から Design System としては考慮されない 控えめな使用を推奨 Custom Component Design System のコンポーネントスペックでは表現できない UI を構成するため、シンボルからディタッチされたり、stroke など Figma 上で制約を設けることができないプロパティをコンポーネントのスペックを超えて改造されたものを指す Design System としては非常に不本意なコンポーネントであるため将来的にそのスペックが Design System でサポートされるか、或いは UI の仕様を調整することで薄くなっていくべきレイヤー Blueprint 直訳すると青写真という意味になりますが、設計図や完成予想図の意味で使用される Blueprint は、Figma のデザインデータから iOS, Android, Web のソースコードまで包括的にその設計図が提供される 主に Design System Component とするにはコンテンツ/コンテキスト依存が強いが頻繁に活用されるもの、或いは snowflakes のようなワンオフに近い用途を持つが、その組み立て方法が複雑なときに活用する Design Recipes Figma のデザインファイルでのみ設計図が提供されるコンポーネント。ソースコード上では提供されない フレームワークの恩恵を受けるなど実装上コンポーネントとして定義する必要性が低いものに対し、デザイン効率化のため Figma のデザインファイルでのみコンポーネントとして利用 (レイアウト系のコンポーネントに多い) Blueprint がデザイン (Figma) とソースコード両方のレシピを提供するのに対し、Design Component はデザイン (Figma) のレシピのみが提供される Design System コンテンツ/コンテキスト非依存で再利用可能な独立したコンポーネント 実はこれらのレイヤーは Brad Frost により提唱されている vocabulary に深く影響を受けているため、彼に詳しい人にとっては既視感のあるものになっています。 ただこれらには Atomic Design のような明示的な名前はついていないため、単に記事中の表現から component vocabulary と呼ぶことにします。 Design system components, recipes, and snowflakes すべての UI コンポーネントが Design System で完結するデザイン組織が最も strict なデザイン組織と言えるかもしれません。実現は難しいですが、そのような組織も少なからず存在しているようです。 このモデルは、もう少し合理的な妥協ラインを求めた場合にとてもフィットします。プロダクト開発でどうしても発生するコンテンツ依存なコンポーネントをワンオフとして一定数許容しつつ、そこにボキャブラリーとレイヤーを与えることで管理対象とし、薄く維持するためのマインドセットを生み出すことができます。そして、Design System と Snowflakes の間を埋める再利用可能だが Design System として管理するには十分な動機が (まだ) ないものをレシピとすることで、全体のコンポーネントレイヤーにグラデーションを与え、メンテナンスコストとリターンの最適化を図る意図があります。 コンポーネント設計・分割指針 次に Design System コンポーネントの設計・分割指針を見ていきます。冒頭で紹介した通り、以前のシステムでは最終的に1つのコンポーネントに振る舞いや variant を持たせ過ぎたことで利便性やメンテナンス性の低下を招きました。 これらの教訓を踏まえ、新しいシステムではセマンティックでシンプルな分解を重視し、以下の4つをコンポーネント設計の指針としました。 Semantic “ビジュアル的に近いものをコンポーネントとするのではなく、挙動や意味的な分類によってコンポーネントを定義/分割するし常に一貫した振る舞いを提供します。” 例としてメルカリにはチップと呼ばれているラウンド状のクリッカブルなコンポーネントがあります。 3.0 では全て1つのコンポーネントとして定義されていましたが、以下のようによく似た見た目を持つコンポーネントに対して大きく異なる振る舞いをすることが分かります。 トグル: タップする事にステートの変化 リムーバブル: タップすると消える 文字入力: タップが別のアクションのトリガーとなる 一見、共通コンポーネントの異なる状態を利用しているだけに見えますが、タップ可能領域やタップ時、およびホバー時 (Web) のスタイルなども違ってきます。1つのコンポーネントで表現するには不要な依存関係を考慮する必要が出てくるため、コンポーネントの分割対象とすることで依存関係がシンプルになりメンテナンス性が向上します。 Properties “異なる色、角の丸みや角ばっているなどに基づいてわずかな視覚的バリエーションを持つことができます。但しコンポーネントの形や振る舞いを変えることはできません。” 先に紹介したチップコンポーネントでは、ストロークのスタイルを solid/dotted のようなプロパティを持たせています。これは視覚的なバリエーションであり形や振る舞いを変えることはないため、1つ目の Semantic 指針を侵害しません。 Optional Elements “コンポーネントはオプショナルな要素を持つことができる (オプションのアイコンやテキストなど)” ボタンの prefix/suffix アイコンのような子要素を持たせることができます。 次の4つ目の指針で紹介する No polymorpihc API と相反することがないよう注意する必要があります。 No polymorphic API “一貫したAPIを持つべきである (必須となるプロパティが別のプロパティの存在の有無に基づいて変更されるべきではない)” 画像とコードの例を用いて解説します。次の画像は、3.0の古い Design System で定義されていた ItemThumbnail というコンポーネントで、3.0 では Large size のみに割引や値段の要素が許可されていましたが、これは polymorphic API とみなし、新しい指針では避ける設計としています。 “特定の条件の時に発生するネストされた条件”には、最終的に冒頭で紹介したような管理の複雑性を生じます。 Polymorphic API を含むコード例: ItemThumbnail( size = Medium ) ItemThumbnail( size = Large( discountPrice = 900¥, price = 1,000¥ ) ) 4.0 ではコンポーネントの分解と再構築により、これらの問題を回避しています。ItemTile という Organism コンポーネントを用意し、構成要素として ItemThumbnail を含む Atoms, Molecules を持たせています。 Polymorphic API を含まないコード例: ItemThumbnail( leftBottomContentSlot = <other atoms/molecules/organism> ) 結果 Atomic Design を採用した私達の Design System は、最終的に150弱の数のコンポーネントに再分解され、以下のようなコンポーネント分布の構成になりました。これが適切なのか過不足あるのかは現時点で判断することはできませんが、今後の運用で明らかになっていくはずです。 Atoms: 50 Molecules: 60 Organisms: 40 また、冒頭でから例として上げている ItemObject はそのレイアウトだけを提供する ObjectLayout と、パーツを組み上げる blueprint に分かれて提供する方法に着地しました。 ObjectLayout: ItemObject (blueprint): 条件分岐などで膨れ上がったコードも、iOS (Swift) で700行あったものが30行弱にまで削減されました。実際組立時に発生するコードもあるため純粋な削減とはなりませんが、コンポーネントの抽象化や汎用化に失敗していた部分が単純化できたと考えられます。 まとめ 今回の Design System 4.0 刷新プロジェクトを通じて、私達は過去の課題と向き合い、より柔軟かつ持続可能なシステムへと進化させるための重要な学びを得ました。 コンポーネントの過度な汎用化が複雑性を生み、メンテナンス性を著しく低下させる教訓から、Atomic Design の原則に立ち返り、コンポーネントを最小単位に分割し、再利用性を高める設計へと移行しました。これにより、各コンポーネントが単一の責任を持つようになり、変更やテストが容易になりました。 同時にコンポーネントがどうあるべきかを考え直しゼロから組み直すことで 3.0 で得た知識と経験を新しいシステムに反映することができました。 今後 Figma AI や Figma MCP をはじめとするデザイン及びコーディングの自動化において、ブランディングコンセプトを反映し、かつセマンティックな意味を持つ Design System コンポーネントはハブとしての役割や、AI に対してのコンテキスト提供者としてその重要性を増していくと考えています。 また続報があればお伝えしていきます。 最後まで読んでいただきありがとうございました。

こんにちは。メルコイン フロントエンドエンジニアの@y-arimaです。 この記事は、 Merpay & Mercoin Tech Openness Month 2025 の18日目の記事です。 本記事では、Web版メルカリからメルコインAPIへの疎通確認を行ったPoC（Proof of Concept）について、技術的な課題と解決策、そして得られた知見を紹介します。 背景と目的 現在、メルコインの機能を利用できるWebサービスは存在しません。そこで、技術的な検証として、Web版メルカリからメルコインAPIにアクセスできるかどうかを試してみることにしました。 今回のPoCでは、 Web版メルカリからメルコインAPIへの疎通確認 を主な目標とし、技術的な実現可能性を検証しました。 技術的な課題と解決策 1. 認証設計の複雑さ 既存のWeb版メルカリの認証システムは独自のユーザーID体系を使用していましたが、メルコイン側のマイクロサービスは異なるクラスタに存在しており、セキュリティ上の理由からそのIDをそのまま受け付けない仕様となっていました。 この問題を解決するため、プライバシーを考慮した識別子（PPID: Pairwise Pseudonymous Identifier）を利用する新たなOIDC（OpenID Connect）クライアントを作成する必要がありました。PPIDは、異なるサービス間でお客さまを安全に識別するための仕組みです。PPIDの詳細については、以下の記事をご参照ください。 メルコインにおけるシステム間のデータ分離を実現するための通信アーキテクチャ Applying OAuth 2.0 and OIDC to first-party services 2. インフラ周りの設定 メルコインAPIへのアクセスを可能にするためには、Gatewayやネットワーク周りなどのインフラ設定が必要でした。普段フロントエンドエンジニアとしての業務がメインの私にとって、この辺りは馴染みの薄い領域でした。 しかし、アーキテクトチームやSREチームなどさまざまな方にサポートいただき、必要な設定を進めることができました。この経験を通じて、マイクロサービス間の連携には多くのチームの協力が必要であり、またフロントエンドエンジニアとしても、インフラストラクチャーの知識の重要性を実感しました。 3. 未知のコードベースでの開発 今回のPoCでは、普段触れることのない複数のリポジトリでの作業が必要でした。大規模なコードベースを短期間で理解し、必要な修正を加えていく必要があり、これは大きなチャレンジでした。 この課題に対しては、最新のAIツール（特にCursorなどのAI搭載エディタ）を積極的に活用することで対応しました。特に新たなOIDCクライアントの設定では、普段触れることのないTerraformのコードを修正する必要がありました。しかしCursorの機能を活用して既存のOIDCクライアントの設定を分析し、その構造や仕組みを理解した上で、新しいクライアントの設定を進めることで、開発効率を向上させることができました。 実装の成果 今回のPoCでは、以下の2つの機能を簡易的に実装することで、Web版メルカリからメルコインAPIへの疎通確認を行いました： ビットコインの価格をチャートで表示する機能 取引報告書をダウンロードする機能 これらの機能実装を通じて、認証やAPI通信、ファイルのダウンロードなど、さまざまなパターンでの疎通確認を行うことができ、 Web版メルカリからメルコインAPIへのアクセスは技術的に実現可能である ことを確認できました。 PoCを通して学んだこと 一人での限界と効率的な進め方 PoCを進める中で、フロントエンドエンジニア一人でこのような大規模な検証を完遂することの難しさに直面しました。このような状況を受け、多くのチームの方々に協力いただきましたが、PoCという性質上、本番開発に比べて優先度が低く、各チームへの依頼が完了するまでに時間を要することも少なくありませんでした。そこで、未経験の領域にも果敢に挑戦し、「まずは自分でできることを探る」という姿勢で取り組むことで、チーム間のコミュニケーションコストを抑えつつ、効率的な開発を進めることができました。 AIツールの活用 前述した未知のコードベースの理解促進はもちろん、チャート機能や取引報告書のダウンロード機能の実装においても、AIツールは大きな効果を発揮しました。 開発の流れとしては、以下のプロセスを繰り返しました。 Cursorに要件を伝えてコードを生成 細部を自分で調整 または Cursorを活用して修正 動作確認 問題があれば2に戻る この方法により、極めて短期間で機能を完成させることができました。 また、これらの機能の実装では、フロントエンドエンジニアとして普段から慣れ親しんでいる領域だったことが、AIツール活用の大きなアドバンテージになりました。 正しいコードの形が頭の中にあるため、Cursorが生成したコードの良し悪しを即座に判断でき、適切な修正指示を出すことができたのです。この既存知識とAIツールの組み合わせにより、開発スピードは格段に向上しました。 複数のチームとの効率的なコミュニケーション メルカリグループのエンジニアリング組織は大規模であり、複数のチームから構成されています。 PoCを進める上で「誰に質問すれば良いか」が最初は不明でした。この問題に対しては、メルカリ全体のアーキテクチャを横断的に把握していアーキテクトチームに最初に相談し、必要なタスクと担当チームを特定しました。その後は、複数のチームに並行して質問や相談を行うことで、開発のブロッカーを最小限に抑えながら効率的に進めることができました。 まとめ 今回のPoCでは、Web版メルカリからメルコインAPIへのアクセスが技術的に実現可能であることを確認できました。この検証を通じて、フロントエンドエンジニアとしても認証やインフラなど、システム全体への理解を深めることの重要性を改めて実感しました。 また、AIツールの活用や効率的なチーム連携の方法など、今後のPoC開発にも活かせる知見を得ることができました。 この記事が、同様の技術的挑戦に取り組む方々の参考になれば幸いです。 明日の記事は @keitasuzukiさんです。引き続きお楽しみください。

Merpay & Mercoin Tech Openness Month 2025 の第17回目のブログ投稿です。 ntk1000 です。MerpayでKYCチームとPartner Platformチームのエンジニアリングマネージャーを務めています。本日は特定のチームについて話すのではなく、開発者体験（Developer Experience）を向上させるための会社全体のエンジニアリングOKRイニシアチブについて共有したいと思います。 1. なぜDevExなのか？ Developer Experience（以下、DevEx）は、開発者が仕事においてどれだけスムーズに、ストレスなく、価値ある仕事に集中できるかを示す概念です。 Nicole Forsgrenらが提唱した研究では、"良いDevExは、開発者の満足度と効率性を高め、生産性と定着率を向上させることで、ビジネス成果にもつながる" とされています（参考： The SPACE of Developer Productivity ）。 また、Googleも、"開発者が実際にどれだけの時間を本質的な価値創出に費やせているか" を重視しており、DevExの改善をプロダクトの品質とスピード向上の重要な要素として扱っています（参考： How Google Measures Developer Productivity ）。 このように、DevExは単なる開発効率の指標ではなく、チームの健全性とプロダクトの競争力に直結する、戦略的なテーマです。 AIの台頭、事業の多角化、グローバル展開など、エンジニアリング組織の複雑性が増す中で、エンジニアの日々の業務には、集中時間の確保や自律的な判断の難しさといった新たな課題が生まれています。複雑性が高まるにつれて、個人の努力や善意だけでは対応しきれない構造的な摩擦が目立つようになってきているのです。 たとえば、私が担当しているKYCおよびPartner Platformチームは、社内の他チームやプロダクトに必要な共通機能を提供するプラットフォームとしての役割を担っています。そのため、私たちは多様化・グローバル化するサービスの要求に応える開発と、自チームのプロダクト自体の改善を並行して行う必要があります。しかし現実には、前者への対応に時間とリソースの大半を割かれてしまい、後者の改善が後回しになり、結果として前者の対応にも時間がかかってしまうというジレンマが存在しています。これは構造的な負債であり、個人やチーム単体の努力だけで解決できる問題ではありません。 だからこそ、私たちはDevExを単なる業務効率やスコア改善の話ではなく、開発チームの持続可能性とプロダクトの競争力を両立させるための戦略的な取り組みと位置づけました。複雑な環境の中で、自律的に動けるチームを育てるには、構造的な課題に対して全社的に向き合う必要があります。そのため、私たちはEMや開発チームだけにその責任を任せるのではなく、組織全体でDevEx改善に取り組む体系的なアプローチを選択しました。 2. 測るのは、行動と対話の出発点 私たちは DX という、サーベイベースの定性データとデリバリースループットのような定量データを組み合わせたDevEx可視化ツールを採用しました。目的はスコアを生成することではなく、チームが自分たちの働き方を客観的に見つめ直し、課題を言語化し、改善に向けた行動を起こすきっかけを生み出すことです。定量と定性を合わせて可視化することで、エンジニアやEMが感覚的に持っていた課題認識をチーム全体で共有できるようになり、そこから建設的な会話が始まります。 「測って終わり」にしないために、私たちは四半期ごとの改善サイクルを設計しました。サーベイは単なる数字の羅列ではなく、チーム内の声を可視化し、EMやチームメンバーがその背景にある課題を言語化するための出発点です。そこで得られた定量・定性のデータは、対話のきっかけとなり、チームが納得感を持って改善に向けたアクションを検討するプロセスを支えています。こうした仕組みによって、計測→判断→行動→振り返りというサイクルが継続的に回るようになっています。 3. 組織全体で機能する改善サイクルの設計 改善サイクルの詳細は以下の通りです： 計測 ：四半期毎に15分前後の匿名サーベイの実施 判断 ：EMがサーベイ結果を確認、チームとも議論して、改善に注力するエリアを判断 行動 ：EMは判断結果を元に、具体的なアクションプランを作成し、チームとして実行 振り返り ：チームのレトロスペクティブや次のサーベイ結果を元にアクションの効果を確認 このプロセスの主体はチームのエンジニアおよびEMです。Manager of ManagersやDirector、VPは各チームの実施状況や、チームからエスカレートされた課題の確認と解決に責任を持ちます（これによって、EMの改善努力が組織全体に反映される構造が保たれます）。 このプロセス設計には、セクション2で触れた「データをきっかけとした対話と行動」の考え方が反映されています。単にスコアを確認するだけでなく、数値とコメントから文脈を読み取り、現場で実行可能な改善策へと落とし込むことが重要です。そのために、各チームが自律的に進められるよう、プロセス自体はシンプルかつ反復可能な形で整備されています。 また、このサイクルは四半期単位で繰り返すものであり、定常業務と並行しながらも継続的に改善が進むよう設計されています。過剰な負荷を避け、着実な実行と振り返りを促すために、各チームが取り組む改善アクションは一つか二つに絞ることが推奨されています。具体的には、サーベイ結果を元に、Vote数、コメント数、業界や会社平均とのスコアの乖離などの要素から複合的に判断し、チームで対話を行いながら優先度の高い課題を特定します。その中から、現実的に取り組めるものを選定します。アクションの量よりも、実行可能性とチームの納得感を重視しています。 今回の取り組みでは、DevEx改善を個人やチーム単体の工夫ではなく、組織の仕組みとして整え、継続可能な文化として根付かせることを目指しています。実際に、今回のサーベイでは対象となるエンジニア100%からの回答を得ることができ、同じく100%全てのEMが改善アクションの提出・実行に参加しています。 高い参加率を確保できたポイントとしては以下の通りです： このプロセス構築をエンジニア組織全体のOKRとして横断的に取り組んだこと なぜDevEx改善に取り組むのか、背景とその狙いをエンジニアだけでなく組織全体にも継続的に発信したこと サーベイ実施やEMによる改善の検討期間中はLunch&Learn（ランチをとりながら学び、質疑応答ができる会）を積極的に開催し、接点を増やしたこと DXやサーベイに関する質問を受け付けるオープンドアセッションを複数回開催し、疑問や不安の解消につなげたこと プロセス開始前にAll Handsで改善サイクル全体を紹介し、意義や進め方への納得感を醸成したこと 4. チームを越えて見えた構造的課題 このように、改善サイクルはチーム単体の実行だけでなく、組織全体での振返りや支援を通じて持続的に機能する設計になっています。その結果、私たちはチーム単体では捉えきれない構造的な課題にも気づくことができました。 内部スコアは公開できませんが、全社共通で明らかになった課題は次のようなものです： Deep Work（集中できる時間）の不足 ：エンジニアが集中を要する複雑な作業に没頭する時間が不足しているという課題です。会議・割り込み・不明瞭な優先順位により、多くのチームで集中が妨げられており、投票数が最も多かった項目でした。複雑な問題解決のためには集中した時間が必要ですが、絶え間ないコンテキストスイッチによってその時間は奪われてしまいます。これは単なる時間管理の問題ではなく、組織の設計や業務の優先順位づけが関係する構造的な課題です。 チーム横断連携における摩擦 ：プロダクト開発はエンジニアリング部門だけで完結はせず、プロダクト・法務・CSなどさまざまな関連部署との連携が必要不可欠です。そして事業の多角化、組織の拡大によってチーム数・組織構造は複雑化していきます。この課題は業界平均との差が最も大きかった項目でした。これは私が担当しているKYCおよびPartner Platformチームでも自覚があり、本来は他チームが必要とする共通機能をスムーズに提供したいのですが、整備が間に合っておらず、他チームからの問い合わせ対応に多くの時間を要してしまっているのが現状です。 このような課題はいずれも、個々のチームやEMだけでは解決できない、より上位の構造や仕組みの見直しが必要な領域です。したがって、全社的な文化と仕組みの転換、たとえば集中時間を保護する働き方のルール整備や、チーム間連携をスムーズにするセルフサービス化の推進といった取り組みが求められます。 5. 現時点で見えてきたこと 実例：2つのドメインを持つチームからの学び 私が担当しているKYCおよびPartner Platformチームのサーベイ結果と改善アクションについて共有します。両チームをあわせて分析すると「ドキュメント」に関する課題が共通して浮かび上がりました。一方で、KYCチーム単体では「本番環境でのデバッグの難しさ」や「開発環境の整備不足」が強く指摘されるなど、ドメイン固有の課題も明確になりました。 特にドキュメントに関しては、最新情報の所在が不明確であることや、過去の経緯に関するナレッジが分散していることが要因で、問合せ対応や仕様確認に多くの時間を要しているという声を普段からも聞いていました。これは、プラットフォームチームとしての提供価値を最大化するうえで重要な改善領域です。 従来のドキュメント整備だけでは限界があると判断し、以下のようなアクションを早速進めています： AI/LLMを活用した過去の問合せやナレッジの検索・再利用ができる仕組みの構築 過去の設計ドキュメントやコードベースをもとに、自然言語で仕様を検索・確認できる内部ポータルの構築 更新頻度が高く、非構造的な情報も多い中で、LLMの柔軟性は有効だと考えています。まだ実験段階ではありますが、情報アクセスのしやすさはDevExに直結するため、引き続き取り組んでいきたいテーマです。 6. 最後に：DevExはプロダクト体験そのもの 良いプロダクトを作りたいなら、それを作る人たちにとって良い環境が必要です。DevExは単なるスピードや効率の話ではなく、明確さ・集中・流れの話です。 今回は初回の改善サイクルでしたが、高い関心と参加率をもって全社的に取り組むことができました。対象エンジニアの100%からの回答と、すべてのEMによるアクション提出という結果は、今後に向けた大きな一歩です。一方で、この取り組みを一過性のプロジェクトで終わらせず、疲弊することなく習慣として定着させていくことが次の課題です。 そして、DevEx改善はエンジニアリング組織の効率化にとどまるものではなく、提供するプロダクトそのものの体験価値の向上につながるものです。エンジニアが安心して集中できる環境を整えることが、結果的にユーザーにとっても価値ある機能や品質につながるという視点を忘れずに、今後も取り組んでいきたいと考えています。 私たちもまだ試行錯誤中です。同じような取り組みを進めている方がいれば、ぜひ一緒に学び合いましょう。 より良い開発体験を、一緒に育てていきましょう。 明日の記事は @y-arimaさんの「Web版メルカリにメルコインの機能を組み込む検証をした話」です。引き続きお楽しみください。

こんにちは。メルペイ iOSエンジニアの @shunta です。 この記事は、 Merpay & Mercoin Tech Openness Month 2025 の16日目の記事です。 今回は、WWDC25に現地参加してきたので現地の雰囲気やイベントなどについてご紹介します。 私は、今回が初めての参加なのでとてもワクワクしました！ WWDCとは WWDCは、Appleが毎年開催している開発者向けのカンファレンスです。最新のiOSやmacOSなどの新機能が発表される他、さまざまなセッションやラボで直接Appleのエンジニアや各国のiOSエンジニアと話せる貴重な機会でもあります。今回初めて現地に行くことができました。 準備 WWDCはコロナ後からチケットが無料・抽選制になり、事前の応募が必要です。 チケットを確保したら、次はホテル・航空券の手配です。チケットを入手した時点で2ヶ月ほどしか猶予がないので、早めに取りました。 また、忘れずにESTAを申請しておきましょう。 Day -1（6月7日）: アメリカ到着 時差ボケを考慮して前日の6月7日にアメリカに到着しました。 Apple Visitor Centerに行きました。WWDC期間中は混むとのことなので、当日着ていくAppleのTシャツやグッズを調達しました。 夜にはtry! Swiftコミュニティの飲み会に参加してきました。なんと日本から20～30人くらいの方々が集まっていました。 今までにWWDCに参加したことがある人が多かったので、やっておいたほうがいいことなどを教えていただき、とても役立ちました！ Day 0 (6月8日): 前夜祭 WWDCの前夜祭イベントは夕方からだったので、それまでの時間を使ってGoogle Plexに寄ったり現地のFarmer’s Marketに行ってみたりと観光を楽しみます。 夕方からはAppleの旧本社であるInfinity LoopでWelcome Receptionに参加しました。 空港みたいな厳しい手荷物検査(WWDC期間中は毎日検査があります)を通過したら本人確認をして、WWDCのグッズなどをもらえます。 今年はタンブラーと、ピンズ、トートバッグ、キーアクセサリーです。 その後は参加者同士の交流会があり、 ・世界地図にピンを刺して出身地を示すコーナー ・DJブース ・大きいジェンガなどのボードゲームコーナーなど ・美味しいドリンクとフード などが用意されていて、世界のエンジニアと交流が盛んになるような仕組みが素晴らしかったです。 Day 1 (6月9日): Keynote当日 時差ボケで朝4時に目が覚めてしまい、早く行ってみようかなと思い、朝5時には会場に到着しました。Apple Visitor Center付近に集合です。着いたら誰もいなくて、一番先頭になりました。 待機列では6:30頃にドーナッツやコーヒーなど軽食が配られました。 8:00頃から入場を開始しました。先頭で待機していたのでTim Cook氏のXにも載っています。 https://x.com/tim_cook/status/1932275973606834627 席を確保した後は、Apple Park内のCaffè Macsで朝ごはんが用意されていました。ホテルのような高クオリティのご飯が提供されていてとても美味しかったです。 Keynoteの開始時刻になるとTim Cook氏やCraig Federighi氏が登場。その後大きなスクリーンでKeynoteが始まりました。 最初のF1カーの場面では笑いが起こったり、Liquid Glassや会場が沸いたりと現地でしかできない体験をしました。 Keynote後はお昼ご飯が用意されています。行列ができてしまったので全部の写真を撮れなかったのですが、いろいろな国の料理が提供されていました。これもとても美味しかったです。 Apple Park内に設置されたDownload Stationでは高速のネットが使えて、ベータ版をダウンロードできます。iOS 26を試したり、近くにいた人とVisionOS 26を入れて空間体験を共有できる機能などを試しました。 昼食後はDeveloper向けのKeynoteとも言えるState of the Unionを見た後、In-Person LabsというAppleのエンジニアに直接質問できるアクティビティがあります。 さまざまなジャンルのコーナーが用意されていますが、Design Labなどの人気なLabは事前予約制でWWDCに参加する前に予約が必要です。 私は、iOSのシミュレーターについて気になる点があったのでシミュレーターやXcodeなどデベロッパーツールに関して質問できるラボに行きました。 他にも、Keynoteに登場したF1カーと写真を撮ったり、Apple Park内を散策したりと盛りだくさんの一日でした。ディナーまで用意されていて一日中Apple Parkで過ごしました。 Day 2 (6月10日): セッション参加とスペシャルイベント 2日目はApplePark近くのDeveloper Center Cupertinoで行われた、夕方のDeveloper Activityに参加しました。公式サイトのセッションビデオでは見ることができないオリジナルセッションのようで、AppleのエンジニアにLiquid Glassをデザイン・実装する方法を実際にデモやスライドを用いて説明していただける貴重な機会でした。 夜にはSteve Jobs Theaterで「F1: The Movie」の試写会に参加しました。 WWDCのKeynoteで一番初めに紹介された映画です。 シアター内の撮影はできなかったのですが、Steve Jobs Theaterは普通の映画館に比べてディスプレイの発色や明るさが綺麗だったり、音響がとても良かったりシアターの設備にも感動しました。 もちろん映画の方もとても良かったので、公開されたら是非観てください！ おわりに 初めてのWWDC現地参加でしたが、本当に濃い数日間でした。オンラインでは得られない現地ならではの体験や、世界中の開発者との交流、Appleのコミュニティへの力の入れ方などを肌で感じることができました。 他にも追加で3日ほど滞在し、現地のAI企業に行ったり、Waymoに乗ったりと最新のテクノロジーに触れてきたので別の機会に紹介できればと思います。 やはり現地でしか得られない経験は多いと思うのでiOSエンジニアの方でもそうでない方でも、一度訪れてみてはいかがでしょうか！ 明日の記事は ntkさんです。引き続きお楽しみください。

こんにちは。メルカリモバイル 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さんです。引き続きお楽しみください。 この記事の画像に利用されたAndroid ロボットは、Google が作成および提供している作品から複製または変更したものであり、 クリエイティブ・コモンズ 表示 3.0 ライセンスに記載された条件に従って使用しています。

こんにちは。メルペイ Credit & Payment Service / Engineering Headの @fivestar です。 この記事は、 Merpay & Mercoin Tech Openness Month 2025 の20日目の記事です。 今回はメルペイで主にBFF向けに採用しているgRPC Federationという仕組みを使って、3rd party向けのAPIを実装する取り組みの事例紹介になります。 BFF(Backends For Frontends)開発に導入されているgRPC Federation gRPC Federation は、Protocol Buffers上にDSL(Domain-Specific Language)を記述することでコードを書かずにBFF(Backends for Frontends)を作成できるフレームワークです。現在 OSS として公開しています。 gRPC FederationはBFFに限らずあらゆるマイクロサービス開発において、サービス間の依存関係をProtocol Buffers上で表現することを目指して社内で開発が進められていました。 この仕組みはメルペイのBFFのリアーキテクチャに先行導入されていましたが、IDP(ID Platform)チームが用意しているメルカリID連携の仕組みやAPI Gatewayと組み合わせることで3rd party向けのAPI開発もスムーズに実現することができました。 gRPC Federation: gRPC サービスのための Protocol Buffers を進化させるDSL 【書き起こし】gRPC Federation を利用した巨大なBFFに対するリアーキテクチャの試み – goccy【Merpay & Mercoin Tech Fest 2023】 【書き起こし】メルカリグループの認証基盤における理想と現状、今後の取り組み – kokukuma 【Merpay Tech Fest 2022】 メルペイのアーキテクチャ メルペイではマイクロサービスアーキテクチャを前提とした4レイヤーアーキテクチャを採用しています。API Gatewayを経由してAPI = BFFレイヤーが、Backendのマイクロサービスを束ねるという構成です(図1)。 API GatewayはAPIサーバーをexposeするための処理を行います。メルペイではAPIサーバーはgRPCのエンドポイントを提供しており、API GatewayがgRPCのAPIをJSONのHTTP APIに変換します。他にもアクセストークンの検証等も行います。 APIレイヤーにはMerpay APIという集約的なBFFが提供されていました。しかしサービス拡大に伴って保守コストの増加とオーナーシップの問題が出てきたことを受け、BFFをドメインごとに分割するMerpay APIリアーキテクチャプロジェクトが立ち上がります。このプロジェクトでgRPC Federationが採用されました。 図1 メルペイの4レイヤーアーキテクチャ gRPC Federationの導入 gRPC Federationの利用者として感じる利点は、Protobuf上のDSLの記述のみで完結するため運用時の認知負荷が低いこととパフォーマンス最適化、品質安定性です。 BFFの主な役割は大雑把に言えば「Frontendのために必要なデータをBackendのサービス群から取得して返す」ことです。gRPC Federationは DSLの記述順序に関わらずAPIコールの順序・並列化を最適化 してくれるため、特に複雑なデータ取得が要求される画面で力を発揮します。 複雑な実装が求められる場合は個別にGoのコードを直接記述することもできるのですが、これまでgRPC Federationを用いた開発上はDSLのみで完結しています。そのため自動生成されたGoのコードのみで運用することになり、バグが埋め込まれにくく品質が安定します。 メルペイにおける3rd party向けAPI 現在メルペイでは主に次のような3rd party向けのAPIを提供しています。 ネット決済加盟店向けAPI PFMサービス連携向けAPI メルカリポイント交換API このうちPFM(Personal Financial Management)サービス連携向けAPIとメルカリポイント交換APIについてはgRPC Federationで実装されており、メルカリID連携を用いた認証・認可を採用しています。社内のアセットを最大限に活用して短期間・低コストでAPIを提供する手段が確立でき、外部システムとの連携において非常に前向きな意思決定ができるようになりました。 メルカリID連携 APIを外部に公開するうえで最も重要な要素が認証・認可です。メルカリにはIDPチームがあり、既にメルカリIDを用いたOAuth / Open ID Connect(OIDC)を実現する基本的な仕組みが整っていたので、この点は既存の資産を活用することで実現できました。 これまでAuthentication Code FlowだけでなくClient Credentials Flowを採用したケースもあり、このあたりOAuth 2.0の基本的な機能はおおよそカバーされているため、ユースケースに応じた柔軟な対応が可能となっています。 またメルカリ内部ではお客さまのIDはPII(個人識別用情報)として扱うため慎重に取り扱う必要があるのですが、OIDCを用いたときにPPID(Pairwise Pseudonymous Identifier)として変換されるため、安全かつシームレスに扱える仕組みが整っています。 実際にこれまで3rd party向けのAPIを用意するときは都度IDPチームに相談して適切な選択肢を一緒に考えてもらっているのですが、プラットフォームとして確かな機能が提供されており、またそれらが正しく使えるように毎回丁寧に相談にのってくれるため、大変心強いです。 Applying OAuth 2.0 and OIDC to first-party services gRPC Federationを用いた3rd party向けAPI提供 最初に3rd party向けAPIに導入したのがPFMサービスである マネーフォワードとのシステム連携プロジェクト でした。gRPC Federationが導入されてまもなくの頃で、まだ実際にプロダクション環境での実績がない状況でしたが、前述のような利点があることからSolutionsチーム・Architectチームと相談の上で採用を決定しました。 実はメルカリ全体としてオープンなPublic APIを提供するアイディアもありましたが、意思決定のコストや要求されるスピード感を考えたときに今それを目指すのはToo muchでした。 gRPC Federationを使うことでBFFの立ち上げコストが劇的に下がった ことからも、一旦はドメインごとにAPIを用意していく方が合理性があると判断しています。 このあとに実装したポイント交換APIはgRPC Federationへの習熟度が上がってきたこともあり、おおよそ1-2週間程度で基本的なAPIの用意ができています。gRPC FederationのDSLを記述するのに多少の学習コストが必要でしたが、 Language Server の他、執筆時点では MCPサーバーの実装 も進められており、効率的な開発が行える様々な支援が提供されています。 新規開発の流れ 3rd party向けのAPIをgRPC Federationで実装する場合、次のような手順で進めています。 要件定義 Design Doc作成 API仕様書作成 API仕様に合わせてProtocol Buffers上でスキーマ定義 Protocol Buffers上でDSLを書いてAPI実装 メルペイの場合、要件定義はプロダクトマネージャーが中心となって進めるケースが多いですが、3rd party向けAPIの場合は画面仕様が明確でないケースもあるため、エンジニアがオーナーシップを発揮する必要があります。マネーフォワード連携の場合、私自身がマネーフォワードの利用者で連携を待ちわびていたこともあったので喜々としてやった覚えがあります。 Design Doc作成 Design Docはステークホルダとの合意形成のためにさまざまな観点から情報を整理するために記述します。特にメルカリ・メルペイにおいてはドメインに関係があるチームはもちろん、Architect、SRE、IDP、SecurityといったEnabling方面との合意を早期に得ることが最終的な成果物を早く提供することにつながるため、迅速にまとめることを意識しています。 API提供の背景、目的、スコープ、ゴール APIの名称、ドメイン名 アーキテクチャ図、依存関係 外部システムを含めたシーケンス図 どのチームにどのような作業を要求するか エンドポイント メルカリID連携のクライアントの単位 認可スコープ 提供環境、特に外部向けの開発環境をどうするか こういった情報は要件定義以前から関係チームを巻き込みながら進めておくことで、そこまでにおおよそ決まった方針をDesign Docとして清書し、不確実な要素をつぶしていく作業になります。自分は1度やって勘所を掴んだこともあり要件次第ですがおおよそ1日程度で最低限はまとめられるため、とにかく1度やってしまえば意外と難しいことはなかったりします。 API仕様書作成 3rd partyにAPI仕様を伝える上で当然API仕様書を用意する必要があります。リクエストやレスポンスのヘッダーやパラメーター情報はもちろん、エラーの種別や実際のレスポンスのパターンも用意する必要があります。ただし、特にAPIを新規で開発するタイミングでは、実際にAPIクライアント側が想定するAPI構成になっているかを早めに揃えることが手戻りを抑えるために重要なため、基本的なAPIの単位と主要なパラメーターを整理して早期にすり合わせるように心がけています。 またこの時メルカリID連携のフローも含めたシーケンス図を用意しておくことで、想定されるAPIの呼び出し方法や、お客さまがどこで操作を行うのかといったUX面でもよりイメージを揃えることができたため、シーケンス図もあわせて用意するようにしています。 gRPC Federationを用いたAPI定義の例 gRPC Federationを用いてProtocol Buffers上でAPIを作成するサンプルコードを用意しました。リスト1で3つのエンドポイントを内包する APIService サービスを、リスト2はそのうちの CreateCharge メソッドをそれぞれ定義したものです。(なおコードは実際のものを模したダミーです) gRPCサービス定義 リスト1にはAPIのアウトラインとなる定義が記載されています。 APIService にはまず mercari.api.gateway.spec オプションで、API Gateway向けの設定を行っています。exposeするドメインや、内部的なAPI区分などを指定します。 APIService には CreateCharge GetCharge CaptureCharge という3つのgRPCメソッドが定義されています。各エンドポイントにはAPI GatewayでHTTPのエンドポイントで変換するために google.api.http オプションを設定しています。今回の例ではREST形式のパスを採用しているため、クライアントからするとREST APIとして操作しているように見えるでしょう。 gRPC Federationでは option キーワードを使って .proto ファイル上にannotateします。gRPCサービスに対しては .grpc.federation.service をマッピングするだけで基本的には十分です。もしgRPC FederationのDSL内で環境変数にアクセスしたい場合 env キーで設定することができます。 mercari.api.jp.authority.scopes は必要なスコープを定義するメルカリ独自のオプションです。これはAPI Gatewayによって必要な権限のないリクエストを弾く処理が行われているため、どのようなスコープ単位の定義と、メソッドごとの必要スコープの設定にのみフォーカスできます。 なお、 mercari. で始まっているオプションは基本的にメルカリ社内用のアノテーションで、あくまでメルカリ・メルペイ内部において、API GatewayやIDPとの連携についてアノテーションベースで設定できる仕組みがある、程度の理解で大丈夫です。 リスト1: gRPC サービス定義 service APIService { option (mercari.api.gateway.spec) = { domain : "example-api.merpay.com" endpoint_prefix : "" api_type : API_TYPE_OPEN }; option (.grpc.federation.service) = {}; rpc CreateCharge(CreateChargeRequest) returns (CreateChargeResponse) { option (google.api.http) = { post : "/v1/charges" body : "*" }; option (mercari.api.jp.authority.scopes) = SCOPE_MERPAY_EXAMPLE_API_CHARGE_READWRITE; } rpc GetCharge(GetChargeRequest) returns (GetChargeResponse) { option (google.api.http) = { get : "/v1/charges/{charge_id}" }; option (mercari.api.jp.authority.scopes) = SCOPE_MERPAY_EXAMPLE_API_CHARGE_READWRITE; } rpc CaptureCharge(CaptureChargeRequest) returns (CaptureChargeResponse) { option (google.api.http) = { post : "/v1/charges/{charge_id}:capture" body : "*" }; option (mercari.api.jp.authority.scopes) = SCOPE_MERPAY_EXAMPLE_API_CHARGE_READWRITE; } } gRPCメソッド定義 実際にgRPC FederationでDSLを記載するのは主に各メソッドの戻り値に設定したメッセージになります。リスト2では CreateCharge メソッドの戻り値である CreateChargeResponse に、Backendサービスの merpay.payment.v1.PaymentService/CreateCharge を呼び出して、そのレスポンスから res.charge を取り出して CreateChargeResponse.charge に詰めて返す、という記述をしています。 gRPC Federationでは def キーワードを用いて変数を定義しながら、その中で call キーワードを用いることでBackendサービスのAPIコールを行い、レスポンスに必要なデータを形成していくというフローです。 $.amount のように $ を用いてリクエストパラメータに直接アクセスできます。 今回は省略しましたが validation キーワードを用いてバリデーションしたり、 error キーワードを用いてエラーを返したりといった操作も可能です。 (.grpc.federation.message).alias を用いて、パッケージが異なるがスキーマが同じ場合に自動的にプロパティを詰め替えてくれる機能もあります。レイヤードアーキテクチャを採用しているとこういったレイヤーをまたいだ際のペイロードの詰め替えが発生しがちですが、名前を見て適切にマッピングしてくれるためとても簡潔に扱えます。 customer_id 変数に mercari.grpc.federation.authority.pat().customerId() という値を設定していますが、これはgRPC FederationのDSL(CEL API)を プラグインによって拡張 したもので、IDPが発行した内部用のアクセストークンからカスタマーIDを取得するメルカリ固有のデータアクセスをDSLに組み込んでいます。 なお、このサンプルコードではAPI設計でよく使われる冪等性の担保についても実装例を示しています。昨今ではHTTPリクエストに Idempotency-Key ヘッダーで「冪等キー」を指定する手法が一般的で、サンプルコードでもこの指定に則っています。 grpc.federation.metadata.incoming()['idempotency-key'][0] のようにHTTPヘッダーの値が取得できます。従来メルペイでも 決済や残高のデータ整合性担保 のために冪等キーを導入していましたが、gRPCのリクエストパラメータに指定する手法を採用しているため、BFFレイヤーで詰め替えを行っています。 リスト2: CreateCharge RPCの定義 option (grpc.federation.file) = { import : [ "proto/merpay/payment/v1/payment.proto" ] }; message CreateChargeRequest { uint64 amount = 1; } message CreateChargeResponse { option (.grpc.federation.message) = { def[ { name : "customer_id" by : "mercari.grpc.federation.authority.pat().customerId()" }, { name : "idempotency_key" by : "grpc.federation.metadata.incoming()['idempotency-key'][0]" }, { name : "res" call { method : "merpay.payment.v1.PaymentService/CreateCharge" request : [ {field : "customer_id", by : "customer_id"}, {field : "amount", by : "$.amount"}, {field : "idempotency_key", by : "idempotency_key"} ] } } ] }; Charge charge = 1 [(grpc.federation.field).by = "res.charge"]; } message Charge { option (.grpc.federation.message).alias = "merpay.payment.v1.Charge"; string id = 1; uint64 amount = 2; } gRPC FederationでAPIサーバーが動くまで 実際にはこのProtobufの変更をマージした上で、gRPC Federationを用いてビルドされたGoのコードにテストコードを書いていきます。またAPI Gatewayに対してこのAPIをexposeするための設定も必要です。とはいえおおよそはgRPC Federationによってレールが敷かれるため、1からサービスを作成することに比べると非常にシンプルな工数で実現が可能となっています。 複雑なエンドポイントの実装 先ほど示したサンプルコードはスキーマ自体もかなり簡略化していますが、実際にマネーフォワードとの連携においてはお客さまの残高やメルカードの利用状況など複雑なスキーマやパターンを持つエンドポイントを複数実装しています。 gRPC FederationでDSLを記述する際、次のような操作が基本機能として提供されています。 ネストしたメッセージの中でもAPI call含めた定義が可能 四則演算や型変換が可能 if キーワード、あるいは by キーワード内で三項演算子を用いた条件分岐が可能 call キーワードの中で timeout を用いたタイムアウト時間の設定、及び retry を用いたリトライの指定が可能 複雑なスキーマにおいてはDSLもそれなりの記述量となりますが、基本的には処理結果を変数に詰めるということを繰り返していくため、処理がネストするような書き方にはならず複雑さは比較的抑えられるかと思います。 またスキーマ自体が適切に正規化されていることでメッセージのまとまり単位でDSLの記述も整理できるため、特に新規にスキーマ定義する際は 正規化を意識する ことで全体の見通しがよくなると思います。 まとめ 現時点におけるベストプラクティスの1つとして、gRPC Federationを採用して3rd party向けAPIを提供する流れをざっくりと紹介してきました。 gRPC FederationはBFFのような仕組みを簡単に作成でき、運用負荷も少ないため、低コストでAPIを立ち上げることができます。もちろん複雑なスキーマにも対応できますし、サーバーを分割したい場合にも適しており、プロダクトの規模に応じて様々な状況に対応できる非常に実用的なソリューションです。 もちろんこれはgRPC Federationを導入しただけで作れるものではなく、API GatewayやBackendサービスといったアーキテクチャのレイヤー化や、IDPのようなプラットフォームがあるからこそ、BFFレイヤーの拡張だけで新しいAPIの導入が実現できています。ですのでアーキテクチャの全体像を踏まえて参考にしていただければ幸いです。 今回の記事用に書いたサンプルコードの作成にあたってClaude Codeを用いてDSLを生成しましたが、多少のやり取りでおおよそ期待通りのアウトプットが出来上がりました。今回の Merpay & Mercoin Tech Openness Month 2025 でもAI関連の記事が非常に多く出ていますが、本当に目まぐるしい速度で環境が変わっていっていますよね。ぜひ他の記事も目を通してみてください！ 明日の記事は @takeshiさんと@Shuntaさんです。引き続きお楽しみください。

はじめに こんにちは。メルペイ Solutionsチーム所属のデータエンジニア @orfeon です。 この記事は、 Merpay & Mercoin Tech Openness Month 2025 の15日目の記事です。 2020年にデータパイプラインをJSONで定義して実行することができるツールとしてmercari/DataflowTemplateを開発して OSSとして公開 しました。 最近このツールに大幅な機能追加を行い、 mercari/pipeline と名前を変更してv1.0.0(β版)をリリースしました。 この記事では今回開発を行った以下の機能について紹介していきます。 運用の容易化 YAML対応 パイプライン構成管理の強化 dead-letter設定の追加 パイプライン定義の容易化 checkerツールの提供 運用の容易化 多くのデータパイプラインの開発・デプロイを進めていくと、極力少ない工数で多くのパイプラインを運用していく必要性が高まります。 ここではデータパイプラインのプロダクション環境での運用負荷を軽減するために追加された以下の機能について紹介します。 YAML対応 パイプライン構成管理強化 dead-letter設定の追加 YAML対応 パイプラインの定義を行うconfigファイルのフォーマットは、これまでJSON形式のみサポートしていたのですが、YAML形式でも定義できるようになりました。 JSONでは、改行やダブルクオートを含むようなパラメータがあった場合にサニタイズする手間が発生したり、コメントを書けなかったり、可読性が落ちたりするなどconfigファイルの保守に問題もありました。YAMLで定義することでこうしたパラメータでも直接指定できるようになり、configをよりシンプルに定義して保守できるようになりました。 YAML定義によるbigquery sourceの定義例 sources: - name: bigquery_source module: bigquery parameters: query: |- WITH subquery AS ( -- some comment SELECT user_id, MIN(timestamp) AS first_timestamp FROM `mytataset.mytable` GROUP BY user_id ) SELECT format('%d#g', user_id) as row_key, first_timestamp FROM subquery パイプライン構成管理強化 さまざまなデータパイプラインを運用していると、別々のパイプラインで共通する処理や設定を使いまわしたいケースがあります。 起動時に変数を指定してパイプラインのパラメータを変更する パイプラインの中で指定したパスのみ実行する 複数のパイプライン定義を一つのパイプラインにマージして動かす 本来共通する部分を別々で定義してしまうと、変更時にそれぞれ修正する必要があり、データパイプラインの保守性が落ちてしまいます。 今回configのsystemの項目で新たに以下のパラメータが追加されました。これらを指定することで、上記のようなケースに対応するためのパイプラインの構成制御ができるようになりました。 system args context imports 以降の節でこれらのパラメータによる構成の制御方法について説明します。 argsによる起動時のパイプラインのパラメータの変更 system.argsパラメータを使うことで、パイプラインの起動時のオプションに指定した変数を使ってモジュールのパラメータを書き換えることができるようになります。 実はこれまでのmercari/DataflowTemplateでもパイプラインの起動時の変数指定はできたのですが、複数手段があったり、パイプライン実行時の動的な変数指定(データの値に応じて宛先のtopicをスイッチするなど)と競合したりするなど、いろいろと問題があったため今回argsパラメータとして整理をしました。 args機能を利用するユースケースとしては、通常起動時はcronの起動時の条件でデータを読み込み、問題発生時のデータのバックフィルで読み込み元のテーブルやフィルタ条件の日付を起動時に指定する例などが挙げられます。 以下はargsでパイプラインの起動時に変数を指定して、パラメータの値を書き換えるconfigの例です。 argsでは起動時の指定が無い場合の変数のデフォルト値を設定しています。 デフォルト値では固定値だけでなくTemplate Engineを使って動的に生成することもできます。 target_tableではクエリで参照するテーブル名、current_dateではクエリのフィルタ条件として使うための日付として起動時の日付を生成しています。 bigqueryモジュールのqueryパラメータでこれらの変数の値を埋め込むことでクエリの条件を起動時に制御できます。 system: args: target_table: "myproject.mydataset.mytable" current_date: "${utils.datetime.current_date('Asia/Tokyo')}" sources: - name: bigquery_source module: bigquery parameters: query: |- SELECT * FROM `${target_table}` WHERE created_date >= DATE("${current_date}") パイプライン起動時に以下のようにparameters=args.{変数名}を指定すると、argsで定義した変数のデフォルト値を指定した値で置き換えることができます。 gcloud dataflow flex-template run sample-job \ --project=myproject \ --region=asia-northeast1 \ --template-file-gcs-location=gs://xxx/yyy/zzz \ --parameters=config="$(cat path/to/config.yaml)" \ --parameters=args.target_table=myproject2.mydataset2.mytable2 contextによるパイプラインのパスの指定 単一の目的のためのデータパイプラインではあるものの、状況により処理を派生させたいケースがあります。 こうした派生する処理ごとに別々のconfigファイルを定義すると管理が煩雑になってしまいます。 contextとtagsパラメータを使うことで、派生する処理も含めて単一のconfigファイルで定義しておき、状況に応じて一部の処理を切り替えることができます。 具体的にはconfigファイルで各モジュールにtagを設定して、起動時にcontextで指定したtagのモジュールだけでパイプラインを構成して実行することができます。 contextとtagsを使う例として、機械学習の学習用パイプラインと予測用パイプラインを単一のconfigファイルで定義してcontextで切り替える構成を紹介します。 機械学習では予測モデルを構築する際に、学習用と予測用で別々のパイプラインを作ることがあります。データのソースは学習時と予測時で別々だが特徴量を生成する処理は共通というケースを想定します。 以下のconfigファイルでは、特徴量生成は共通ですが、学習用にはBigQueryのデータソース/結果シンクを用い、予測用にはPub/Subのデータソース/結果シンクを用いています。 system: context: train sources: - name: ml_source module: bigquery tags: - train parameters: table: xxx timestampAttribute: timestamp_field - name: ml_source tags: - prediction schema: avro: file: xxx parameters: format: avro subscription: xxx transforms: - name: feature inputs: - ml_source tags: - train - prediction parameters: groupFields: - user_id select: - name: moving_avg field: amount_field func: avg range: count: 10 sinks: - name: feature_sink module: bigquery tags: - feature inputs: - feature parameters: table: xxx - name: feature_sink module: pubsub tags: - prediction inputs: - feature parameters: topic: xxx sourcesとsinksにそれぞれml_sourceとfeature_sinkという同じnameを持つモジュールがあります。ただしtagsではtrain、 predictionと異なるtagを持っています。 transformsでは特徴量を生成するselectモジュールとして直近の指定した個数の移動平均を計算する設定をしています。バッチでもストリーミングでも同じ特徴量を生成します。 tagsではtrainとpredictionの両方を指定しています。 system.contextでtrainを指定した場合、sourcesとsinksではtagsでtrainが指定されたモジュール(この場合はbigquery)のみでパイプラインが構成されます(contextでpredictionを指定した場合はsourcesとsinksでpubsubのみ)。 transformのselectモジュールはtagsでtrainとprediction両方指定されているのでどちらのコンテキストでも利用されます。 (なおcontextで何も指定しない場合は全てのモジュールが使われ、同じnameでコンフリクトが発生してエラーになります) contextにより、複数のコンテキストに応じたモジュールの設定を単一のconfigファイルに定義しておき、起動時にcontextを指定することでパイプラインの処理を簡単に切り替えられるようになります。 importsによる複数configファイルのマージ パイプラインのためのインフラや運用のコストを減らすために複数の処理を単一のパイプラインにまとめたい場合があります。 一方で、一つのパイプラインに複数の処理をまとめるとconfigファイルが肥大化してパイプライン定義の見通しが悪くなります。 そこでconfigファイルは用途に応じて別々に定義しておいて、importsパラメータでそれらのconfigファイルを指定することでパイプラインを一つにまとめることができるようになりました。 以下ではimportsパラメータを利用したconfigファイルの例を説明します。 この例のconfigファイルではsystem.importsパラメータのみ指定されています。実際の処理はimportsのfilesで指定されたconfigファイルで定義されており、起動時にこれらのファイルを読み込んで一つのパイプラインとして構成・実行します。 (baseパラメータでconfigファイルのパスのprefixを指定しています) system: imports: - base: gs://example-bucket/configs/ files: - pipeline_1.yaml - pipeline_2.yaml - subdir/pipeline_3.yaml このimports機能は、単純に複数のconfigファイルで定義されたモジュールをマージしているだけなので、各configファイルではnameが重複しないように注意が必要です。 (imports時の重複チェックなどの機能は今後改善予定です) dead-letter設定の追加 運用のためには処理の途中でエラーが発生した場合は原因を特定したりリカバリを行うために、問題のあったデータを切り分けて保持する必要があります。またデータパイプラインの要件によっては問題が発生した場合でも処理を正常に続ける必要があります(streaming処理や処理全体をやり直すコストが非常に大きい場合など)。 今回のバージョンアップではほぼ全てのモジュールで修正を行い、処理に問題が発生した場合も極力処理を正常に続行できるようにしました。また問題のあったデータを切り分けて指定したdead-letterに簡単に出力できるようになりました。 以下、dead-letterのconfigファイルの設定例になります。 このconfigではfailuresの項目が新たに追加されています。 failuresのモジュールでは通常のsinkとは異なりinputsを指定する必要はありません、パイプラインの全てのモジュールで処理に失敗したデータはこのfailuresで指定されたモジュールに送られます。 system: failure: failFast: false sources: - name: pubsub_source module: pubsub parameters: format: avro subscription: xxx sinks: - name: pubsub_sink inputs: - pubsub_source parameters: format: avro topic: xxx failures: - name: pubsub_failure_sink parameters: format: avro topic: xxx 処理に失敗したエラーデータは共通のスキーマでfailuresで定義したモジュールに送られます。 あらかじめBigQueryでこのスキーマに準じたテーブルを作っておき、Pub/SubのBigQuery subscriptionを通じてBQに連携・保持することもできます。 パイプライン定義の容易化 パイプラインの定義を作って動作確認する際に、これまでは実際にJobを実行してうまくいくか確認する必要がありました。 しかしこれは手間がかかる作業であり、パイプラインの定義自体が非常に時間の掛かるプロセスでした。 ここではパイプラインの定義をもっと手軽に試行錯誤できるようにするために追加した以下の機能を紹介します。 checkerツールの提供 checkerツールの提供 ブラウザ上で簡単にconfigファイルの内容をチェックするためのツールを同梱しました。 これまでのmercari/DataflowTemplateのビルド成果物は基本的にDataflow Flex Templateのためのコンテナイメージのみでした。 mercari/pipelineではビルド時のプロファイルを切り替えることで複数のビルド成果物を生成することができるようになりました。 現在では以下のプロファイルがサポートされています。 dataflow Cloud Dataflow Flex Template用のコンテナイメージを生成 direct パイプラインのローカル実行用のコンテナイメージを生成 server パイプラインのローカル実行機能をAPIとして提供するサーバ用のコンテナイメージを生成 プロファイルでserverを指定して生成されたコンテナイメージは、ローカルにpullして起動、利用することもできますし、Cloud Runなどにデプロイして使うこともできます。 APIだけでなくチェック用のUIも備えているのでブラウザ上で操作できます。 以下はこのserverのコンテナイメージを起動してブラウザで開いた画面の例になります。 画面の左側がconfigの内容を記述するテキストエリアになります。 右側はconfigの実行結果を表示するエリアになります。 右上のヘッダーには定義したconfigを実行するために以下の2つのボタンが並んでいます。 Dry Run 定義したパイプライン処理の実行グラフを生成する 各モジュールのパラメータのチェック 各モジュール間の関係整合性のチェック 各モジュールの出力スキーマの確認 Run 定義したパイプライン処理をローカルで実行する Dry Runボタンでは、定義したconfigの内容に問題がないか確認できます。 問題があった場合は右側にエラー内容が表示されるので、それを確認して修正することができます。 問題がなかった場合は右側に各モジュールの出力のスキーマが表示されるので、処理内容が想定した通りか確認することができます。 Runボタンでは、定義したconfigの内容で実際にパイプラインをローカルで実行します。 パイプラインでクラウドリソースにアクセスする場合(BigQueryのクエリ結果を取得するなど)はローカル実行しているサービスアカウントに必要な権限が付与されているか注意してください。 以下のコマンドは、利用者のローカルマシン(MacOS)で自分の権限でserverコンテナを起動する例です。 docker run \ -p "8080:8080" \ -v ~/.config/gcloud:/mnt/gcloud:ro \ --rm asia-northeast1-docker.pkg.dev/{deploy_project}/{template_repo_name}/server:latest Cloud Runにデプロイして使うこともできます。以下Cloud Runにデプロイするためのコマンド例です。 (データ処理でBQ等の外部リソースにアクセスする場合はCloud Runのサービスアカウントに権限が必要です) gcloud run deploy {service_name} \ --project={project} \ --image=asia-northeast1-docker.pkg.dev/{deploy_project}/{template_repo_name}/server:latest \ --platform=managed \ --region=asia-northeast1 \ --execution-environment=gen2 \ --port=8080 \ --no-allow-unauthenticated ローカルであっても規模の小さいデータ処理であれば特に問題なく実行できるはずです。バッチでちょっとしたデータの加工や移動をするための便利ツールとしても利用することができます。 なお現在このcheckerツールではstreamingモードでのRun実行はサポートしていないので、streamingモードでローカル実行する場合はdirectのコンテナイメージをコマンドラインで起動して使うことを推奨しています。 directコンテナを動かすのは基本的にserverイメージをdirectに差し替えるだけです。 ただしconfigファイルを起動時のパラメータに指定する必要があります。 以下のコマンドは、利用者のローカルマシン(MacOS)で自分の権限でdirectコンテナをstreamingモードで起動する例です。 docker run \ -v ~/.config/gcloud:/mnt/gcloud:ro \ --rm asia-northeast1-docker.pkg.dev/{deploy_project}/{template_repo_name}/direct:latest \ --streaming=true \ --config="$(cat path/to/config.yaml)" ちなみにこのUIの部分の開発はClaude Codeを使いながら作りました。 自分はフロントエンド開発の経験はほとんどないのですが、ちょっとしたUIを持ったサービスをサクッと作れてとても便利でした。 今後の開発 今後のmercari/pipelineの開発としては大まかに以下のような項目について開発を進めていきたいと考えています。 checkerツールの拡張 streaming処理機能の強化 Apache Flink, SparkなどCloud Dataflow以外のRunnerへの対応 checkerツールの拡張 checkerツールは現在はまだシンプルなconfigファイルの簡易チェックや簡易な動作確認しかできませんが、非エンジニアでもデータパイプラインを手軽に利用できるように機能を拡張していきたいと考えています。 将来は自然言語で処理内容を指示するとエージェントがドキュメントや過去のconfigファイルの履歴などを参照して利用者とインタラクティブにパイプラインを構築できるようにしていきたいと考えています。 今回のリリースには間に合いませんでしたが、エンジニアがインタラクティブにconfigファイルの定義をできるようにcheckerツールをMCPサーバとして利用できるように準備を進めています。 エージェントの連携を強化するためにも、リポジトリのドキュメントの整備やconfigファイルのexamplesの拡張も進めていきたいと思います。 streaming処理機能の強化 Google Cloudにおいてバッチ処理についてはBigQueryでかなりのことができるようになってきました。例えば Federated Query や Reverse ETL を使うことで、Cloud Spanner や Cloud Bigtable などの外部のデータソースから取得したデータをBigQueryのクエリエンジンで処理して結果を書き戻すことも手軽にできるようになりました。 BigQuery ML で機械学習モデルやLLMの推論結果を手軽にクエリの中で付与することもできます。 またちょっとしたリアルタイム処理も、BigQueryの Continuous queries や、Cloud Pub/Sub の Single Message Transforms などを使うことで手軽に実現できるようになってきました。 Google CloudにおいてCloud Dataflowは、大規模データに対する複雑なstreamingデータ処理を担うことを役割として期待されているように思います。 streaming処理の中でも、Apache Beamの特徴であるbatchとstreamingで同じ処理をするユースケースに対して特に集中して機能開発をしていきたいと考えています。 Cloud Dataflow以外のRunnerのサポート予定 名前を mercari/DataflowTemplate から mercari/pipeline に変更した理由でもあるのですが、mercari/pipeline を Cloud Dataflow 以外のデータ処理基盤でも動かせるようにしていきたいと考えています。 Google CloudでもApache Spark, Flink, Kafkaなどの人気でオープンなビッグデータのフレームワークやそのエコシステムとの連携にも力を入れていこうとしているように思います。 こうしたフレームワークとの連携も進めていき、Cloud Dataprocなどでもパイプラインを動かせるように機能を拡張をしていきたいと考えています。 mercari/pipeline は大幅に変更があり、まだβ版でのリリースのため、機能が不足していたり一部バグがあったりするかもしれません。もし問題に気付かれた方がおられましたら、お知らせいただけますと助かります。 またフィードバックやコントリビュータも随時募集しているので、こんな機能があったら嬉しいといった要望などありましたら、気軽にIssueで相談いただいたり、PRを送っていただけたりすると嬉しいです。 明日の記事はtakeshiさんによる「「自分ができる領域が増えた」-Cursorを使って未経験のKotlinコードレビューに挑戦」とShuntaさんによる「初めてのWWDC25に現地参加！Apple Parkで体験した特別な数日感」の2本です。引き続きお楽しみください。

こんにちは。メルペイSREの @foostan です。 この記事は、 Merpay & Mercoin Tech Openness Month 2025 の14日目の記事です。 皆さんはインシデント対応は好きですか。多くの方はこの答えにNoと答えるかもしれません。ただこの業界にいるとYesと答える方もいてなかなか楽しい気分になることがあります。ちなみに私はインシデントの非日常感に少し高揚するタイプではありますが、同僚がたくさんいる昼間に限ります。夜はできる限り携帯電話をスリープ状態にしたいものです。 さて、今回ご紹介するのはメルペイがローンチしてからの約6年間で培ってきたインシデント対応や管理のノウハウです。また実際に直面した課題を例としていくつか取り上げ、その改善をどのようにしてきたか共有します。 なお内容は以前登壇させて頂いた Incident Response Meetup vol.2 のものを少しアップデートしたものになります。 サービスについて 最初にインシデントに関わる話をするにあたり我々がどのような事業を展開し、どのようなデータや規模感でサービスを運用しているのか簡単に紹介させてください。 メルペイはメルカリアプリで使用できるスマホ決済サービスであり、iDやコード決済、メルカードを利用してお店やネットサイトで利用できます。サービスのローンチは2019年2月なので6年と少し経ちました。なおFintechの領域のサービスであり、金融情報や与信などを扱っているためサービスには高い信頼性が求められます。もし不具合が発生しサービスが中断してしまった場合は、速やかに関係各所への連絡と事後対応が求められます。 またメルペイの規模感は 150以上のマイクロサービス 40以上のチーム 1900万人以上の利用者※ と、国内ではそれなりの規模のサービスとなります。 ※ メルペイ「電子マネー」の登録、「バーチャルカード」の設定、「メルカード」の発行、暗号資産取引口座開設を行ったユーザと「メルペイコード決済」「ネット決済」「メルペイスマート払い（翌月払い・定額払い）」等の利用者の合計（自主退会・重複を除く）2025年3月末時点 システム / 組織構成 我々のサービスはマイクロサービスアーキテクチャを採用しており、小さな独立したサービスの集合体になっています。チームごとにサービスの開発や運用を分離できるため、他のサービスに依存することなく変更や拡張が可能です。 ロゴ出典： https://www.cloudflare.com/ja-jp/press-kit/ Google Cloud Official Icons and Solution Architectures チームと責任範囲の例を以下に示します。API GatewayサービスやAuthorityサービス、またCDNなどの共通コンポーネントやネットワーク関連はPlatformチームが担い、ビジネスロジックを持つサービスをProductチームが担います。またPlatformチームは各Productでサービスが運用できるようにサービスのインフラの提供や運用に必要なエコシステムの提供を行っています。開発や運用は基本的にこの責任範囲のもと行っているため、なにか不具合が起きたときはそれぞれの責任範囲で復旧を行います。 ロゴ出典： https://www.cloudflare.com/ja-jp/press-kit/ Google Cloud Official Icons and Solution Architectures エンジニアリング組織と内部統制の概略図を以下に示します。3線モデルに従い、プロダクト提供を行う1線、リスクやコンプライアンス管理する2線、内部監査の3線の大きく3つに分類されます。また1線についてProductチームが効果的に動けるようにSREチームやPlatformチームが存在します。その他にも複数のチームが存在しますが今回は省略しています。 私が所属するSREチームは大きく2つの役割があり、一つはプロダクトに近い立場で各領域の信頼性の向上や課題解決などを通してビジネスの成長に貢献するProduct SRE、もう一つはグループ全体にプラットフォームを提供してビジネスの成長を支えるPlatform SREです。インシデントに関してはProduct SREが実際の対応やサポート、ポストモーテムのレビューなどを行っており、Platform SREがインシデント管理のためのツールの選定や導入等を行っています。またインシデント管理のポリシーや対応フローの作成などインシデントに関わる統制はIT Riskとともに行っています。 インシデント対応・管理 続いて我々が行っているインシデント対応や管理方法について紹介します。 そもそも「インシデント」と言ってもいくつか意味を持ちますが、我々は以下のように分類しています。 システムインシデント : システムトラブル等による予期せぬサービス中断や品質の低下など セキュリティインシデント : サイバー攻撃、システムの脆弱性による情報漏洩など 事務事故 : 事務作業によるミスや不正による個人情報漏洩など 不正や犯罪 : アカウントの不正利用など なお本記事は基本的にシステムインシデントについての話です。特に言及がなく「インシデント」と記載する場合はシステムインシデントを指しています。 インシデント管理は準備、対応、学びのサイクルを繰り返します。各フェーズについて我々が実際に取り組んでいることの例をいくつかご紹介します。 インシデントへの備え SLO / アラートの整備 システムの異常を検知して対応に移れるようにモニターを整備します。どのようなモニターを用意するかはサービスや組織によってさまざまかと思いますが、我々はSLOをベースとしたものを用意しています。また異常を検知した後に原因を追求できるようにオブザーバビリティを確保したり、Dashboardを整備してシステムが正常に動いているかどうか確認できるような体制を取っています。 オンコールの整備 インシデントはいつ発生するかわかりません。仕事をしている日中かもしれないし、休日かもしれない。または夜中に発生する可能性もあります。なのでどのようなときでもアラートを受け取って対応できるようにローテーションを組んで待機します。なお弊社では社内規定を決めて手当が出るようにしています。異常にそなえて休日や深夜にも直ぐに行動ができるように待機するので精神的にも肉体的にも負荷がかかります。またこれは業務なので公平性を保つためにもこのような社内規定は重要です。 マニュアルの整備 緊急の対応は誰が実施するかわからないのでマニュアルを作成して誰でも対応できるように備えておくのが理想的です。前回の対応ログ等を残しておき、参照しやすいようにしておくのも効果的でしょう。最近だとAIの技術が急激に発展してきているので過去の実績をRAGなどによって与えられればAI Opsも現実味を帯びてきます。 インシデントへの対応 異常検知 サービスの異常を即座に捉えるために、アラートでオンコールのメンバーに連絡を送ります。監視と通知の概略は以下のとおりです。我々はGoogle CloudやCloudflareを利用しており、それをDatadogでモニタリングしています。異常を検知するとPagerDuty経由で電話を鳴らしたりSlack上に通知を行います。なお社内にはインシデント情報を共有するMercariグループ共通のSlackチャンネルがあり、一次情報はそこに集約されます。お客さまからのお問い合わせなどの情報もCS経由でここに集まります。 ロゴ出典： https://www.cloudflare.com/ja-jp/press-kit/ https://www.datadoghq.com/about/resources/ https://brandguides.brandfolder.com/pagerduty/logo https://slack.com/intl/ja-jp/media-kit Google Cloud Official Icons and Solution Architectures インシデントの識別 発生した内容や影響度からSEV(重大度)を見積もり対応を行います。SEVのレベルごとにポリシーを設けており、その後の対応方針が決まります(詳細は後述)。ただしいずれのレベルにおいても最優先でインシデントの緩和や解決に動き始めます。 エスカレーション / 通知 影響が社外に及ぶ場合は、並行してステークホルダーへの周知を行います。インシデントコマンダーもしくは連絡役を専任し、社内外の連絡窓口を一本化。お客さま、VPs、パートナー企業へ影響範囲・暫定対応・次回更新予定を通知します。 インシデントの緩和 / 解決 インシデントの対応は関連するチームが主体となって進めます。影響度が単一のプロダクトチームに閉じる場合はそのチームのPdMやEM、テックリードなどがインシデントコマンダーとなりインシデントの緩和や解決、その後の処理を行います。また規模が大きく複数のプロダクトチームをまたぐ場合はSREやPlatformチームなど組織横断で動きやすいチームが中心となって対応します。 インシデントからの学び ポストモーテム インシデントが解決したらなるべく早くポストモーテムを実施します。社内ではポストモーテムのガイドやテンプレートを用意して効果的に振り返りが行えるような体制を整えています。最近ではSlackの会話を要約したり時系列の情報を収集したりするためにAIの活用も進めています。 恒久対応および再発防止 ポストモーテムで特定された根本原因に対しては、一時しのぎではなく恒久的な対策を計画します。コードの修正だけでなく、運用プロセスや組織構造に起因するケースも多いため、変更管理やレビュー体制まで含めて見直します。また対応策は実現可能なものを策定し完了日を設定することを重要視しています。 レポート作成 / 共有 社内で整備しているテンプレートを利用してインシデントレポートを作成します。インシデントが発生してから解決するまでの時系列情報、被害情報、発生原因、対応内容、根本原因、事後改善策などの項目が含まれます。また後に分析できるように内容や原因はいくつかのカテゴリに分類して記録しています。レポート作成においても最近はAI活用の試みを始めており、できる限り早く情報共有ができるように改善を行っています。 インシデント分析 過去インシデントのデータを集約し、ダッシュボードで傾向を可視化しています。たとえばチーム、原因、SEV、MTTRなどをグラフ化し特定の領域の増加傾向の識別やプロセス等を改善した際の効果測定などに利用しています。また未解決インシデントや未実施のポストモーテムの数を可視化することでインシデントの管理プロセスが正常に動いているかどうかを定期的に監視し、悪化傾向にあればプロセス全体の見直しをするなどの判断も行っています。 インシデント識別と対応ポリシー 重大度を示すSEVの定義と対応ポリシーは以下のとおりです。なお公開用に抽象度が高い表現をしていますが、社内ではもっと詳細な定義があります。 SEV 概要 対応ポリシー SEV1 極めて重大なインシデント 全社で最優先に対応 プロジェクト化して継続的に改善 SEV2 多くのお客さまに影響を与える重大なインシデント 関係チームで最優先に対応 恒久対応・再発防止策の完了をIT Riskチームでトラッキング SEV3 お客さまに影響を与えるインシデント 関係チームで優先的に対応 恒久対応・再発防止策の完了をチームでトラッキング SEV4 お客さまに影響はないが対応が必要なインシデント 関係チームで対応 恒久対応・再発防止策の完了をチームでトラッキング SEV5 お客さまに影響はなく対応が不要と判断したインシデント 対応不要 SEVの定義は日々運用していく中で見直しを行っています。SEVの運用にはいくつかの課題がありますが、その一つは正しく選べないというものです。選択するための基準はありますが、機械的に完璧に定義することは難しく最終的にはどうしても人の判断が入ります。そこで最近ではSLOの毀損度に応じて自動的に判断するなど、わかりやすくかつ即座に判断できる新しい基準を設けるための議論も行っています。 課題と改善 数年運用する中で発生した課題やその解決方法、また現在抱えている課題とそれに対して今取り組んでいること、これから取り組もうとしていることなどをご紹介します。一部既に上述したものも含まれています。 大量のアラート インシデントまたはその予兆を知らせるアラートも大量に発生すると対応しきれません。また不要なアラートに埋もれてしまい、重要なアラートを見逃してしまうことで、インシデント対応の初動が遅れるリスクもあります。更にこのようなアラートを放置すると割れ窓理論によって状況が悪化する恐れがあります。 SLOアラート この問題を解決するために、CPUやメモリの使用率といったシステム内部のメトリクスではなく、お客さまへの影響度を指標化した SLO(Service Level Objective)ベースのアラートを採用しました。SLI(Service Level Indicator)はお客さまへ影響が出たときに変化するメトリクスを選ぶ必要があり、現在はエラー率とレイテンシを広く利用しています。「ページャーから呼び出しがある ＝ お客さまへの影響が実際に発生している」という状態が理想です。なおこのSLOアラートは何度かアップデートを繰り返しており我々も試行錯誤を続けている最中です。最近では E2E Testを用いたマイクロサービスアーキテクチャでのUser Journey SLOの継続的最新化 で取り上げたCritical User Journeyに基づいたSLOアラートの仕組みが軌道に乗り始めており、運用のさまざまな場面での活用を進めています。 ロゴ出典： https://www.datadoghq.com/about/resources/ https://brandguides.brandfolder.com/pagerduty/logo https://slack.com/intl/ja-jp/media-kit https://brand.hashicorp.com/product_logos 第一報の遅延 インシデントを検知したあとの情報共有は、社内だけでなく社外に対しても迅速に行う必要があります。第一報が遅れると対応そのものが遅延するだけでなく、現場や関係者を混乱させ、さらなる被害拡大を招くおそれがあります。 自動報告システム SLO を基準とし、一定以上毀損した場合にあらかじめ登録された連絡先へ自動で第一報を送信する仕組みを導入しています。誤報を恐れずとにかく素早く第一報を送ることをコンセプトとしていますが、SLO をベースにしているため一定の精度も担保できます。 ロゴ出典： https://www.datadoghq.com/about/resources/ https://slack.com/intl/ja-jp/media-kit https://aws.amazon.com/jp/architecture/icons/ 情報過多 インシデント対応中は現場が混乱し、情報が過剰に流れてきます。また、途中から参加したメンバーが状況を瞬時に把握するのは困難です。熟練したインシデントコマンダーであればこうしたケアも行えますが、実際にはうまく機能しないことのほうが多いです。 インシデントサマライザー Slack の会話内容を自動で要約し、影響を受けたサービス、その被害状況、原因などをまとめて表示できるようにしています。LLM を利用しているため、プロンプトを変更するだけでさまざまなフォーマットへ容易に拡張できます。外部向け報告資料やポストモーテム資料の作成にも活用可能です。 インシデント管理 ガイドが浸透しない、ポリシーが守られない、ポストモーテムがいつまでも終わらない、恒久対応・再発防止策の実施が進まないなど決められたインシデント管理プロセスの統制を取るのが難しいという問題があります。 コミュニティの形成 インシデント対応・管理を向上させるためには、関係者全員の理解が欠かせません。まずは「自分ごと」として捉え、主体的に対応することが第一歩です。そのために各チームから代表者を選出してコミュニティを組織し、インシデント管理状況の共有、分析結果の報告、ナレッジ共有、課題の整理や解決策の立案・実施などを自主的に進められる体制を構築しました。ただし長年運用をしていると活動が少なくなってしまう時もあったため、SREやIT Riskの責務として継続することが重要だと感じています。 インシデント分析 インシデントに関するデータは順調に蓄積されていますが、現状を手軽に可視化・分析したいというニーズが高まっています。 インシデントダッシュボード インシデントの発生状況や要素別の集計結果、未対応タスクなどを可視化し、状況を迅速に把握できるダッシュボードを整備しました。しかし、現時点では詳細な分析まで踏み込めておらず、類似インシデントの検出や共通原因の特定といった高度な分析およびデータ活用は今後の課題です。 AI活用 最近の AI 技術の発展により、インシデント管理で有効に活用できる場面が急速に増えていると感じます。たとえば、不要なアラートが増えすぎている問題に対しては AI に分析させて削減案を自動で提案させたり、インシデント対応中に過去の類似インシデントを検索して対応の補助に利用できます。また、インシデント管理ツールの MCP サーバーを用意し、AI 経由でレポートの作成やデータ入力を依頼するなど、さまざまなアイデアが提案され実装が進んでいます。以前公開した LLM x SRE: メルカリの次世代インシデント対応 で紹介したIBISもその一例です。 AI 関連領域は目覚ましいスピードで進化しており、IBIS もアーキテクチャのアップデートや他の社内ツールとの連携を継続的に進めています。さらに SaaS でも Bits AI SRE のような AIを 活用したインシデント対応機能が登場しつつあります。 最後に 本記事では、6年間にわたる試行錯誤を通じて得られたインシデント対応・管理に関する知見をご紹介しました。SLO を利用した異常検知、コミュニティ形成によるポリシー適用と運用促進、ポストモーテムの徹底、AI 活用による効率化など、継続的に改善を進めています。インシデントを完全にゼロにすることはできませんが、仕組みに落とし込み、改善サイクルを回し続ければ、サービスの安定化とチームの強化につながると考えています。 本記事が皆さまの運用を一歩前に進めるヒントになれば幸いです。AIがもたらす大きな変化とカオスを楽しみながら運用を楽にし、安眠を勝ち取りましょう。 明日の記事はorfeonさんの「 Mercari Pipeline (旧Mercari Dataflow Template) v1を公開しました 」とfivestarさんの「 gRPC Federationを使った3rd party API開発事例：マネーフォワード連携から学ぶ実装ノウハウ 」の2本です。引き続きお楽しみください。

こんにちは。メルカリモバイル Backend チームでエンジニアリングマネージャーをしている @k_kinukawa です。 この記事は、 Merpay & Mercoin Tech Openness Month 2025 の12日目の記事です。 2025年4月21日にメルカリモバイル開発チームでオフサイトミーティングを実施し、その中でAI Hackathonを開催しました。チーム内でのAI活用を促進することを目的とし、約20名のソフトウェアエンジニア・PM・QAエンジニアが参加しました。 なぜAI Hackathonを実施したのか メルカリモバイル開発チームでは、2025年3月に社内の生成AI開発ツールのPoCに参加する形でCursor、Devin、Gemini Code Assistのアカウントをソフトウェアエンジニアに付与し、積極的な活用を推奨していました。しかし、4月中旬の時点で実際の活用は十分に進んでいませんでした。 メルカリモバイルは3月4日にローンチしたばかりの新サービス で、やりたいこともやるべきことも山積している状況でした。一方で、生成AI開発ツールを取り巻く状況は日々ものすごいスピードで変化しており、忙しい中で最新の情報をキャッチアップして業務で活用するのはなかなかハードルが高い状況でした。 そんな中、エンジニアリングマネージャーの週次定例ミーティング内でAI Labs TeamのマネージャーからCursor bootcampを実施したという共有がありました。Cursor bootcampでは以下のような取り組みが行われたとのことです。 Cursorのリファレンスを読み合わせる（1時間） 各々、取り組むことを決めて個別に作業する（2時間） 結果として参加者間での知識レベルとCursorに対する期待値が揃い、Cursor活用や議論が活発になったとのことでした。 また、 PCP LLM Week のような大規模な取り組みの話も耳にしていました。1週間という期間をかけて組織全体でAI活用に取り組むという非常に興味深い試みでしたが、メルカリモバイルの現状では同規模の時間を確保することは難しい状況でした。 これらの事例を参考に、現実的に実行可能な形でチームのAI活用を推進するために 1日という限られた時間で集中的にAI活用を体験する オフサイトイベントを企画しました。 普段の忙しい業務の中では断片的にしか触れないAIツールについて、まとまった時間を確保して一気にキャッチアップし、Hackathon形式で実際に楽しく手を動かして理解を深めることを目的としました。また、全員が同じタイミングで同じ体験をすることで、その後のチーム内での情報共有や議論の土台を作ることも狙いでした。 オフサイトの実施内容 オフサイトミーティングは社外の貸し会議室を利用しました。 参加対象者はソフトウェアエンジニアだけでなく、PM、QAエンジニアも含めました。 当日までに参加者全員に対してCursorのアカウント発行とダウンロードを実施しました。 時間割は以下の通りです。 午前 : アイスブレイク、相互理解セッション（偏愛マップ、ドラッカー風エクササイズ） 午後前半 : AIキャッチアップセッション（0.5時間） 午後後半 : AI Hackathon（2.5時間 + 発表1時間） 余談ですが、このオフサイトではAI Hackathonだけでなく、相互理解のためのセッションとして偏愛マップ、ドラッカー風エクササイズも実施しました。 このセッションを通じて、チームメンバーのパーソナルな一面を知ることができたり、お互いの期待値のズレを認識することができたりと非常に有意義でした。 AIキャッチアップセッション Hackathonに入る前に、全員の認識を揃えるためのキャッチアップセッションを実施しました。 事前に私が社内外の情報を取りまとめて、スライドで発表しました。 内容は以下の通りです。 組織目標の共有 : エンジニアリング組織として設定された重要な指標「全てのエンジニア100%が何らかのAIコーディングアシスタントツールを活用し生産性を高める」を改めて確認 AIツール利用ガイドライン : 社内におけるAIツールの基本的な利用方法が記載されたガイドラインの紹介、AIツールにどんな情報を入力してよいかの確認 社内のCursor利用ガイドライン : コードのindexingについての理解、.cursorindexingignoreファイルの理解 MCP Serverとセキュリティ : MCP Serverの説明、使用可能なMCP Serverの紹介、MCP Server利用時のセキュリティに関する注意点 社内のAIに関する取り組み、活用事例紹介 : 社内で利用可能なAIツールとその活用事例の紹介、AI活用をしているプロジェクトの紹介 社外の事例紹介 : 社外のAI開発ツール活用事例紹介 このセッションを通じて、メルカリ社員として社内業務でAI開発ツールを利用するために必要な基礎知識のキャッチアップと、AI開発ツールを使ってできることの認識を合わせることができました。 AI Hackathon 2.5時間の時間を使って、各々が事前に準備したアイデアの実現に取り組みました。 Hackathonを開催した4月末は、世の中的にMCP Serverが非常に注目されていたタイミングだったため、多くのメンバーがMCP Serverのセットアップとそれを活用したアイデアの検証にチャレンジしていました。 私は以下のようなことに取り組みました。 MCP Serverセットアップ支援 PMとQAエンジニアに対して、CursorとMCP Server（Confluence、Jira、Figma）のセットアップをサポート Terraform編集タスクをAIに任せる実験 あるメンバーへの権限付与タスクをCursorのAgentに依頼 Terraformコードの変更からプルリクエスト作成まで、一切手動でコードを書かずに実施 自作MCP Server開発チャレンジ Cursor Agentを使って、自作のMCP Server作成に挑戦（時間切れで未完成） チームメンバーがチャレンジしたAIを使ったアイデアも一部紹介します。 MCP Server開発・活用 Cursor と Jira、Figma、Confluence、Spanner、BQとのMCP Server 連携そその活用方法の模索 Proto MCP Server 開発 GitHub mermaid sequence diagram 生成 AI開発支援ツール活用 AI Reviewer 作成 Cursorでのリファクタリングとテスト 生成 GitHub MCP Server 連携 デザイン・プランニング領域 FigmaAI調査 新機能のプランニング（1時間で設計からリソース計画まで作成） テキストからワイヤーフレーム作成 業務改善 便利ツールの開発 Test Case自動生成 アンケート分析 私が今回のHackathonで最も印象的だったのは、PMがCursorとMCP Serverを活用して、メルカリモバイルの新機能プランニングに取り組んでいたことでした。 Hackathonの最初、Cursorにメルカリモバイルの最新のソースコードを読ませMCP ServerでConfluenceに接続できる状態までサポートしたのですが、そこからたった1時間程度で新機能開発に関する仕様作成、主要開発項目の洗い出し、既存機能を踏襲した設計、開発・QA工数とスケジュール算出を行いました。もちろんこれを使っていきなり開発に入れるわけではないのですが、叩き台としては十分使えるものが作れてしまったことに本人含めて皆驚いていました。 AI Hackathonを終えて 事後アンケートでは「CursorなどのAIツールをしっかり触る時間を取れて新しい技術をキャッチアップすることができてよかった」「業務から離れる時間を取ってAI活用にフォーカスする時間を取ることができて良かった」といった回答を頂きました。 ↑は DX というツールを使ってメルカリモバイルBackendチーム内のCursorによるline changesを集計したグラフです。4月21日以降、Cursorが日常的に活用されるようになったことが数字からも読み取れます。 また、チームのエンジニアによる メルカリ内製MCP Server リポジトリ へのコントリビュート（いくつかのサービスの追加）も行われました。 興味ある方は是非こちらも御覧ください。 Sourcegraph × 自作MCP Serverによる社内コード検索連携の取り組み Cursorを"導入"だけじゃなく"活用"まで メルカリ2000人展開のリアル 現在ではCursorだけでなく、DevinやClaude Code Agentの利用も徐々に増えています。 まとめ 今回のHackathonを通じて、以下のような学びがありました。 1. まとまった時間確保の重要性 環境は整っていても、忙しい日常では新しいツールを試す時間が取れない 目的のために強制的に時間を確保することで、全員が「最初のハードル」を超え同じスタートラインに立てる 2. 全員参加による学習効果 皆で一緒に作業することで、その場で疑問を解消できる 情報共有により全員の理解を一致させることができる ソフトウェアエンジニア以外のメンバーも効果的にAI開発ツールを活用できる可能性を確認することができた 個人の自発的な学習だけでなく、組織として意図的に学習機会を創出することの有用性を実感することができました。これからも組織としてAI-Nativeになるための機会や仕組みを継続的に作っていきたいと思います。 一方で、日々のミーティングや業務の量を見直していくことで余裕が生まれ、日常的に新しいことにチャレンジできる状態も作り出せるのではないかと考えています。これは今後の大きな課題だと考えています。 明日の記事は@David, @anzaiで「 Building a Flexible Checkout Solution: Frontend Architecture for Multi-Service Integration 」です。引き続きお楽しみください。

こんにちは。Fintech SREの佐藤隆広(@T)です。 この記事は、 Merpay & Mercoin Tech Openness Month 2025 の11日目の記事です。 Google社が提唱し、 Site Reliability Engineering Book によって広く知られるようになったSREの信頼性マネジメントは、開発と運用の関係性を再定義し、SLI/SLOとエラーバジェットに始まり、Availability・Latency・エラーレート・トラフィック・リソース飽和度・耐久性といったような指標で補強されてきました。 ところが近年、大規模言語モデル（LLM）の進歩が著しく、サービスにLLMを利用する機会が増えることによって、 プロンプトを数行変えただけで回答品質が変動する Latencyやエラーレートが良好でも幻覚（ハルシネーション）が急増する モデルの軽微なアップデートで回答スタイルが激変する といった、従来指標では見落としがちな事象に遭遇することが多くなりました。 つまり 「LLMサービスの信頼性」 を守るには、クラシックなインフラ指標の他に LLMサービス固有の品質指標 を重ね合わせてモニタリングする必要性が迫られています。 本記事では、LLMサービスの信頼性評価に不可欠な指標の選定から、具体的な測定・評価方法までを、DeepEvalライブラリを用いたデモを交えて紹介します。 1. LLMサービスの一般的評価指標 LLMサービスの信頼性を測る上で、どのような指標に着目すべきでしょうか？ LLM Evaluation Metrics: The Ultimate LLM Evaluation Guide では、下記の評価観点の代表例が挙げられていました。 指標名 説明 回答の関連性 (Answer Relevancy) 質問に対して、どれだけ適切に答えているかを測る指標 タスク完遂度 (Task Completion) 与えられたタスクをどれだけ正確にやり遂げられたかを測る指標 正確さ (Correctness) 事前に用意された正解とどれだけ一致しているかを測る指標 幻覚の有無 (Hallucination) 事実に基づかない内容や、デタラメな情報が含まれていないかを測る指標 ツール使用の正確さ (Tool Correctness) タスクを達成するために正しいツールを選び、実行できたかを測る指標 文脈適合性 (Contextual Relevancy) 検索された情報が質問に対してどれだけ適切かを測る指標 責任あるAI指標 (Responsible Metrics) 差別的な表現や攻撃的な内容を含んでいないか、特定の属性に対して偏見を持っていないかなどを測る指標 タスク固有指標 (Task-Specific Metrics) 要約や翻訳など、「特定のタスク」においてLLMの性能を測るための指標 従来のサービスの代表的な指標として、AvailabilityやLatencyなどといったインフラ系SLIを監視すれば、ユーザージャーニーと関連付けてお客さま満足度を把握することができました。 しかしLLMサービスでは、「応答が意図に沿い、事実に基づいているか」「タスクを正しく完遂できたか」といった生成品質そのものがお客さま満足度に直結します。 そのため、従来のAvailabilityやLatencyに加え、LLMサービス特有の生成品質を捉えるSLIを設計し、お客さまが「意図どおりの正しい回答を迅速に得られるか」を定量的に示せる指標体系を整える必要があります。 では、具体的にLLMサービスの指標を設計する上で、どの指標を選定するべきでしょうか。 1.1. 一般的評価指標の落とし穴 上記の表にある、回答の関連性、正確さ、幻覚の有無といった一般的な評価観点は骨格ですが、すべてのLLMサービスのユースケース固有の成功条件をキャッチアップできるとは限りません。 たとえば要約サービスなら「網羅性」や「矛盾の有無」、RAGなら「検索文脈の適合度」といった独自指標がなければ、お客さまが得る価値を測り切れないことが多いです。 The Accuracy Trap: Why Your Model’s 90 % Might Mean Nothing という記事では、顧客離反（churn）予測モデルがテスト精度92%を達成したにもかかわらず、実運用では解約防止どころか誤警告と取りこぼしが発生し、結果として離反率が増えたことを解説しています。 教訓としては、お客さま視点のエンドツーエンド評価を最優先にする、ということだと思われます。 LLMサービスはRAGやエージェント機構など複雑な内部構造を持ちますが、中間コンポーネントをいくら改善しても、お客さまが受け取る回答が向上しなければROIは上がりません。 ブラックボックスとしての最終出力を計測し、エンドツーエンドで測った結果が、サポート工数削減や売上向上と相関することが、そのLLMサービスの選定すべき評価指標でしょう。 1.2. 優れた評価指標とは? The Complete LLM Evaluation Playbook: How To Run LLM Evals That Matter では、優れた評価指標の条件として、下記3点が挙げられていました。 定量的であること（Quantitative） 評価結果として数値スコアを算出できること。数値で評価できれば「合格ラインとなるしきい値」を設定したり、スコアの時系列変化を追ってモデル改善の効果を測定したりできることが望ましいです 信頼性が高いこと（Reliable） 常に安定した評価結果が得られること。LLMの出力に予測不能な揺らぎがある以上、評価指標まで不安定では困ります。例えばLLMを用いた評価手法（後述のLLM-as-a-judgeなど）は従来手法より高精度な反面、評価結果にばらつきが出やすい傾向があるため注意が必要です 正確であること（Accurate） LLMモデルの性能を実際の人間の評価と近い基準で的確に反映できること。評価スコアが高い出力=人間にとって良好と感じられる出力、となるのが理想であり、そのためには人間の期待と整合した基準で評価する必要があります また、評価指標値がいくら高いスコアを叩き出しても、売上やお客さま満足度などのビジネス成果につながらなければ意味がありません。 同記事では、これを Metric Outcome Fit（指標と成果のつながり） と呼んでおり、「現場で行われるLLMの指標評価の95%は、このつながりがなく価値を生まない」とまで言及されていました。ビジネス上「良い結果」とみなされるケースを指標が確実に“良い”と判定できるか、上記を確認・調整し続けることが、指標を外さない唯一の方法、と紹介されています。 2. 指標の評価方法の全体像 次に、指標を実際に評価する手法の種類について紹介します。大別すると、下記の4つが存在し、それぞれに長所・短所があります。 統計的手法 (string-based / n-gram based / surface base) LLM以外のモデルを用いる手法 (classifier / learned metrics / small-LM metrics) 統計的手法、LLM以外のモデルを同時に用いるハイブリッドな手法 (embedding-based metric) LLMそのものを用いる手法 (LLM based / generative evaluator) 2.1 統計的手法 人手で作成した正解データと出力テキストを文字列レベルで比較し、類似度を測って評価する手法です。 BLEU モデル出力と期待される正解文との1〜4-gram 精度を平均し、brevity penalty を乗法して精度ベースで算出し、長さの過不足に対するペナルティも加味したスコアを与えます ROUGE 要約評価によく用いられ、ROUGE-Lは LCS(最長共通部分列)ベースで再現率と精度の F1を取り、ROUGE-1/2 が n-gram再現率に基づき要約が元文書をどれだけカバーしているかを測ります METEOR 精度と再現率の両面から評価し、語順の違いや同義語のマッチングも考慮する指標です。(最終スコアは精度・再現率の調和平均に語順ペナルティを乗法して算出） 編集距離（ レーベンシュタイン距離 ） 出力と正解の文字列差分そのものを測定する指標。実務では複数文長の比較にそのまま使うことは稀で、キャッチアップコストの割には使用されていないケースが多いようです ref: LLM evaluation metrics — BLEU, ROGUE and METEOR explained これら統計的指標は計算が単純で再現性（一貫性）は高いですが、テキストの意味や文脈を考慮しないためLLMが生成するような長文回答や高度な推論を要する出力の評価には不向きです。事実、純粋な統計手法では出力の論理的整合性や文意の正しさまでは評価できず、複雑な出力に対しては精度が不十分だとされています。 2.2. LLM以外のモデルを用いる手法 評価専用の機械学習モデルを用いて、分類モデルや埋め込みモデルなど、比較的軽量な自然言語処理モデルを使って評価する手法です。 NLI（自然言語推論）モデル LLMの出力が与えられた参照テキスト(事実情報など)に対して、整合しているか（Entailment）/ 矛盾しているか（Contradiction）/ 無関係か（Neutral）を分類できます。この場合、モデルの出力スコアは「論理的にどれだけ一貫しているか」を表す0.0~1.0の確率値になります Transformer型の言語モデル（NLI, BLEURTなど）をベースに学習した専用モデル LLMの出力と期待される正解との類似度をスコアリングして計測する手法で、モデルベース手法では、テキストの意味をある程度考慮した評価が可能になりますが、評価モデル自体に不確実性があるため、スコアの一貫性（安定性）に欠ける場合があります。例えば、NLIモデルは入力文が長大になるとうまく判断できなかったり、BLEURTは学習データの偏りに影響を受け評価が偏る可能性が指摘されています 2.3. 統計的手法、LLM以外のモデルを同時に用いるハイブリッドな手法 上記の中間に位置する手法で、事前学習済み言語モデルの埋め込んでベクトル化した値と、統計的な距離計算を組み合わせて評価する手法です。 BERTScore BERT などで求めた各単語の文脈ベクトル同士の コサイン類似度 を計算し、出力文と参照文の意味的な重なり度合いを測定します MoverScore 出力文と参照文それぞれについて単語埋め込みを用いた分布を作成し、そこから Earth Mover’s Distance（最適輸送距離） を計算して両者の差異を測定します これらの手法は単語レベル・表面レベルを超えて意味的な近さを捉えられる点で統計的手法で挙げたBLEUなどより優れていますが、結局は元となる埋め込みモデル（BERT等）の性能やバイアスに影響されるという弱点があります。例えば専門領域の文脈や最新の知識について、事前学習モデルが適切なベクトル表現を持っていなければ正確な評価はできません。また評価モデルが内包する社会的バイアスがスコアに現れるリスクもあります。 2.4. LLMを用いた手法（LLM-as-a-judge） 評価手法の中でも近年注目されているのが、LLM自体に計測させて出力品質を評価させる手法、LLM-as-a-judgeです。 高度なLLMに「与えられた回答が基準を満たすか評価してください」と指示を与え、モデルから評価スコアや判定を引き出すアプローチになります。 LLMは文章の意味理解や複雑な判断ができるため、人間の主観に近い評価を自動化できる点が大きな長所です。 実際、GPT-4を評価者に用いる G-Eval という手法では、評価スコアと人間評価との相関が従来の自動評価よりも大幅に向上することが、 G-Eval Simply Explained: LLM-as-a-Judge for LLM Evaluation という記事でも紹介されています。 一方で、LLMベースの評価はそのモデルの応答次第で結果が変動しうるため、スコアの安定性（信頼性）に課題があります。 LLMに同じ回答を再評価させても毎回まったく同じスコアが得られる保証はなく、モデルのランダム要素や出力の揺らぎが評価結果にも影響を及ぼすためです。 下記に、代表的なLLM-as-a-judgeの手法をピックアップしてみます。 G-Eval 評価基準を1～5段階スケールで採点し、LLMが評価スコアと評価結果の理由(Chain of Thoughtの結果)を返す仕組み QAG Score 出力からQA(Yes/No/Unknown)を自動生成し、原文で同じQAを解き、両者の一致率をスコアにする SelfCheckGPT 同じプロンプトでN回サンプリングし、生成文同士の一貫性(例：N-gram・QA・BERTScoreなど複数の比較モード)を測って事実性を推定する。ばらつきが大きいほど幻覚の可能性が高くなる DAG(deep acyclic graph) DeepEval が提供する決定木型メトリック。各ノードはLLM判定(Yes/No)で、経路によって固定スコアを返すため LLM-as-a-judgeなのにブール判定ノードを決定木で束ね、部分点を決定論化する Prometheus2 Model GPT-4を含む高品質ジャッジのフィードバックと多数の評価トレースで蒸留した7B/8×7Bの評価モデル。人間/GPT-4との一致率0.6〜0.7(直接採点), 72–85%(ペアワイズ比較)で立証済み 最後に、ここまで挙げた指標の計測評価方法をまとめてみたのが下記の表になります。 種類 具体的な手法 長所 短所 統計的手法 BLEU / ROUGE / METEOR / 編集距離（レーベンシュタイン距離） ・計算が単純で高速・再現性が高い ・追加学習が不要で実装が容易 ・意味・文脈を考慮せず表層一致のみを評価 ・論理整合性や高度な推論が必要な出力には不向き LLM 以外のモデルを用いる手法 NLI（自然言語推論）モデル / BLEURT / Transformer ベースの専用評価モデル ・意味理解や論理的一貫性をある程度評価できる ・LLM より計算コストが低く、自前で fine-tune 可能 ・評価モデル自体の不確実性 ・バイアスに依存 ・長文・専門領域で精度が低下しやすい ハイブリッド手法 BERTScore / MoverScore ・埋め込みで語義的近さを捉え、統計指標より高精度 ・決定論的で再現性を保ちやすい ・埋め込み元モデルの学習範囲・バイアスに左右される ・最新知識や狭い専門領域では適合しにくい LLM を用いる手法（LLM-as-a-judge） G-Eval / QAG Score / SelfCheckGPT / DAG (Deep Acyclic Graph) / Prometheus2 Model ・人間評価に近い複雑な判断を自動化できる ・回答の多面的品質を一括で評価可能 ・出力が確率的でスコアに揺らぎが出やすい ・モデル利用コストが高く、プロンプトに敏感 これら評価手法を実際に計測するには、効率的に測定するためのツールが必要です。 そこで、今回はLLM評価ライブラリの中から参考記事で垣間見ていたDeepEvalについて紹介したいと思います。 3. DeepEval DeepEval は、LLMサービスを評価するためのPythonライブラリです。 テストケースの作成、評価指標の定義、評価の実行を行うためのフレームワークを提供します。 DeepEvalは、応答の関連性、忠実性、文脈の精度など、さまざまな側面を評価する指標をサポートしており、カスタム指標や評価データセットの自動生成、Pytestのようなテストフレームワークとの統合もサポートしています。 公式ドキュメント には、詳細なインストール手順、基本的な使用方法、各種評価指標の設定方法、カスタム指標の作成方法などが詳しく解説されています。 それでは、簡単な要約サービスを元に、評価手順を実践してみようと思います。 3.1 実践例： 要約サービスでの指標決定と測定方法 ここで想定する要約サービスは、記事やドキュメントなどの長文を入力として受け取り、その内容を短くまとめた要約文を生成するサービスです。 LLMの仕組み的に得意分野として真っ先に思いつくサービスだと思います。 今回は、グリム童話を要約して、子供でもわかるような文章で要約してくれるサービスを考えてみたいと思います。 3.2 指標の選定 要約という観点から、一般的な評価指標として思いつく指標は、 回答の関連性 (Answer Relevancy) , 正確さ (Correctness) , 幻覚の有無 (Hallucination) です。 Deepevalの G-Eval を利用して、上記3つの指標に対応することができますが、今回のケースでの 1.2. 優れた評価指標とは? に該当するか調査する必要があります。 定量的であること(Quantitative) G-Evalは0〜1の連続スコアを返すので、評価結果として数値スコアを算出できると言えます 信頼性が高いこと(Reliable) G-Evalは本来確率的ですが、LLMモデルに渡す temperatureのオプションを0で呼び出し 、 evaluation_stepsを固定しCoT生成処理をスキップ 、 Rubricを指定して評価スコアを一定にする という3点を実行すれば、同じ入力で同じスコアがほぼ再現させることができるので、常に安定した評価結果が得られそうです(厳密には、OpenAI側の sampling noise、 system randomness が残っており完全再現には至りません。top_p=0, seed 固定可能な API/backend を使うか，最終的には majority vote/ensemble 評価が推奨されます) 正確であること(Accurate) G-Evalは参照(expected_output、今回のケースの場合、グリム童話の原文や正解データです)付きの評価であり、事実照合を中心とするタスクではG-Evalは人間判定との相関が高いことが論文・実運用の両方で示されています。 よって、今回のケースでは、 回答の関連性 (Answer Relevancy) , 正確さ (Correctness) , 幻覚の有無 (Hallucination) の指標について、DeepEvalのG-Evalでの指標評価を使用することは妥当だと言えそうです。 3.3 評価観点の分解 次に、ピックアップした指標をどのような手順で評価させるのか、評価するために必要な観点やステップを列挙していきます。 幸いなことに、評価観点を分解する上で、参考になりそうな文献が、Google Cloudの Vertex AIのドキュメント – モデルベース評価の指標プロンプト テンプレート にありましたので、今回はそちらを参考に評価観点を分解していきたいと思います。 回答の関連性 (Answer Relevancy) STEP1. Identify user intent – List the explicit and implicit requirements in the prompt. STEP2. Extract answer points – Summarize the key claims or pieces of information in the response. STEP3. Check coverage – Map answer points to each requirement; note any gaps. STEP4. Detect off-topic content – Flag irrelevant or distracting segments. STEP5. Assign score – Choose 1-5 from the rubric and briefly justify the choice. 正確さ (Correctness) STEP1. Review reference answer (ground truth). STEP2. Isolate factual claims in the model response. STEP3. Cross-check each claim against the reference or authoritative sources. STEP4. Record discrepancies – classify as omissions, factual errors, or contradictions. STEP5. Assign score using the rubric, citing the most significant discrepancies. 幻覚の有無 (Hallucination) STEP1. Highlight factual statements – names, dates, statistics, citations, etc. STEP2. Compare with provided context and known reliable data. STEP3. Label claims as verified, unverifiable, or false. STEP4. Estimate hallucination impact – proportion and importance of unsupported content. STEP5. Assign score following the rubric and list specific hallucinated elements. 3.4 評価スコアの算出 では、実際に評価測定をして評価スコアを算出してみます。 まず、要約させる題材とプロンプトを用意します。 今回、グリム童話の原文は 赤ずきん を使用し、プロンプトは下記を用意してみました。 以下のグリム童話の内容の要約を作成してください。 要件： 1. 主要な登場人物や重要な要素を特定して含める 2. 内容の流れを論理的に整理する 3. 重要な出来事や転換点を含める 4. 原文の内容に忠実であること 5. 要約の長さは500文字以内に収める グリム童話の内容： {赤ずきんの原文} 要約：""" 使用した評価スクリプトは下記になります。 import asyncio import openai from deepeval.metrics.g_eval.g_eval import GEval from deepeval.metrics.g_eval.utils import Rubric from deepeval.test_case.llm_test_case import LLMTestCase, LLMTestCaseParams async def evaluate_comprehensive_metrics(client: openai.AsyncOpenAI, test_case: LLMTestCase, prompt_name: str, original_text: str) -> dict: """G-Evalメトリクス評価を実行""" # 回答の関連性評価 (Answer Relevancy) geval_answer_relevancy = GEval( name="Answer Relevancy", evaluation_steps=[ "STEP1. **Identify user intent** – List the explicit and implicit requirements in the prompt.", "STEP2. **Extract answer points** – Summarize the key claims or pieces of information in the response.", "STEP3. **Check coverage** – Map answer points to each requirement; note any gaps.", "STEP4. **Detect off-topic content** – Flag irrelevant or distracting segments.", "STEP5. **Assign score** – Choose 1-5 from the rubric and briefly justify the choice.", ], rubric=[ Rubric(score_range=(0, 2), expected_outcome="Largely unrelated or fails to answer the question at all."), Rubric(score_range=(3, 4), expected_outcome="Misunderstands the main intent or covers it only marginally; most content is off-topic."), Rubric(score_range=(5, 6), expected_outcome="Answers the question only partially or dilutes focus with surrounding details; relevance is acceptable but not strong."), Rubric(score_range=(7, 8), expected_outcome="Covers all major points; minor omissions or slight digressions that don’t harm overall relevance."), Rubric(score_range=(9, 10), expected_outcome="Fully addresses every aspect of the user question; no missing or extraneous information and a clear, logical focus."), ], evaluation_params=[LLMTestCaseParams.INPUT, LLMTestCaseParams.ACTUAL_OUTPUT, LLMTestCaseParams.RETRIEVAL_CONTEXT], model="gpt-4o" ) # 正確さ評価 (Correctness) geval_correctness = GEval( name="Correctness", evaluation_steps=[ "STEP1. **Review reference answer** (ground truth).", "STEP2. **Isolate factual claims** in the model response.", "STEP3. **Cross-check** each claim against the reference or authoritative sources.", "STEP4. **Record discrepancies** – classify as omissions, factual errors, or contradictions.", "STEP5. **Assign score** using the rubric, citing the most significant discrepancies.", ], rubric=[ Rubric(score_range=(0, 2), expected_outcome="Nearly everything is incorrect or contradictory to the reference."), Rubric(score_range=(3, 4), expected_outcome="Substantial divergence from the reference; multiple errors but some truths remain."), Rubric(score_range=(5, 6), expected_outcome="Partially correct; at least one important element is wrong or missing."), Rubric(score_range=(7, 8), expected_outcome="Main facts are correct; only minor inaccuracies or ambiguities."), Rubric(score_range=(9, 10), expected_outcome="All statements align perfectly with the provided ground-truth reference or verifiable facts; zero errors.") ], evaluation_params=[LLMTestCaseParams.ACTUAL_OUTPUT, LLMTestCaseParams.RETRIEVAL_CONTEXT], model="gpt-4o" ) # 幻覚の有無評価 (Hallucination) geval_hallucination = GEval( name="Hallucination", evaluation_steps=[ "STEP1. **Highlight factual statements** – names, dates, statistics, citations, etc.", "STEP2. **Compare with provided context** and known reliable data.", "STEP3. **Label claims** as verified, unverifiable, or false.", "STEP4. **Estimate hallucination impact** – proportion and importance of unsupported content.", "STEP5. **Assign score** following the rubric and list specific hallucinated elements.", ], rubric=[ Rubric(score_range=(0, 2), expected_outcome="Response is dominated by fabricated or clearly false content."), Rubric(score_range=(3, 4), expected_outcome="Key parts rely on invented or unverifiable information."), Rubric(score_range=(5, 6), expected_outcome="Some unverified or source-less details appear, but core content is factual."), Rubric(score_range=(7, 8), expected_outcome="Contains minor speculative language that remains verifiable or harmless."), Rubric(score_range=(9, 10), expected_outcome="All content is grounded in the given context or universally accepted facts; no unsupported claims.") ], evaluation_params=[LLMTestCaseParams.ACTUAL_OUTPUT, LLMTestCaseParams.RETRIEVAL_CONTEXT], model="gpt-4o" ) await asyncio.to_thread(geval_answer_relevancy.measure, test_case) await asyncio.to_thread(geval_correctness.measure, test_case) await asyncio.to_thread(geval_hallucination.measure, test_case) # Rubricスコアを推定する関数(表示用) def extract_rubric_score_from_normalized(normalized_score, rubric_list): """正規化されたスコア(0.0-1.0)からRubricの範囲を特定""" scaled_score = normalized_score * 10 for rubric_item in rubric_list: score_range = rubric_item.score_range if score_range[0] <= scaled_score <= score_range[1]: return { 'scaled_score': scaled_score, 'rubric_range': score_range, 'expected_outcome': rubric_item.expected_outcome } return None answer_relevancy_rubric_info = extract_rubric_score_from_normalized( geval_answer_relevancy.score, geval_answer_relevancy.rubric ) correctness_rubric_info = extract_rubric_score_from_normalized( geval_correctness.score, geval_correctness.rubric ) hallucination_rubric_info = extract_rubric_score_from_normalized( geval_hallucination.score, geval_hallucination.rubric ) return { "answer_relevancy_score": geval_answer_relevancy.score, "answer_relevancy_rubric_info": answer_relevancy_rubric_info, "answer_relevancy_reason": geval_answer_relevancy.reason, "correctness_score": geval_correctness.score, "correctness_rubric_info": correctness_rubric_info, "correctness_reason": geval_correctness.reason, "hallucination_score": geval_hallucination.score, "hallucination_rubric_info": hallucination_rubric_info, "hallucination_reason": geval_hallucination.reason, } async def generate_summary(client: openai.AsyncOpenAI, prompt_template: str, full_story: str, model: str = "gpt-4o") -> str: """LLMを使って要約を生成""" prompt = prompt_template.format(context=full_story) try: response = await client.chat.completions.create( model=model, messages=[{"role": "user", "content": prompt}], max_tokens=300, temperature=0.0, top_p=0, logit_bias={} ) content = response.choices[0].message.content return content.strip() if content else "" except Exception as e: return f"Error: {str(e)}" async def process_prompt(client: openai.AsyncOpenAI, prompt_info: dict, full_story: str, context: list) -> dict: model = prompt_info.get("model", "gpt-4o") # 要約生成 summary = await generate_summary(client, prompt_info["template"], full_story, model) # テストケース作成 test_case = LLMTestCase( input=prompt_info["template"], # プロンプト actual_output=summary, # 要約結果 retrieval_context=context # 要約対象(童話)の原文 ) # 評価実行 metrics_result = await evaluate_comprehensive_metrics(client, test_case, prompt_info['name'], full_story) return { "prompt_name": prompt_info['name'], "model": model, "summary": summary, **metrics_result } async def main(): # 童話の原文を読み込み with open('little_red_riding_hood.txt', 'r', encoding='utf-8') as f: full_story = f.read().strip() context = [full_story] prompts = [ { "name": "prompt-01", "template": """以下のテキストを読んで、内容の要約を作成してください。 要件： 1. 主要な登場人物や重要な要素を特定して含める 2. 内容の流れを論理的に整理する 3. 重要な出来事や転換点を含める 4. 原文の内容に忠実であること 5. 要約の長さは250文字以内に収める テキスト： {context} 要約：""", "model": "gpt-4o" }, ] async with openai.AsyncOpenAI() as client: tasks = [ process_prompt(client, prompt_info, full_story, context) for prompt_info in prompts ] all_results = await asyncio.gather(*tasks) # 結果表示処理 ... if __name__ == "__main__": asyncio.run(main()) 実行した要約結果は下記になりました。 昔、赤ずきんちゃんという愛らしい女の子がいました。彼女はおばあさんから赤いずきんをもらい、それをいつもかぶっていました。 ある日、病気のおばあさんにお菓子とぶどう酒を届けるため、森を通っておばあさんの家に向かいます。 途中で狼に出会い、行き先を教えてしまいます。狼は先回りしておばあさんを飲み込み、赤ずきんちゃんも騙して飲み込みます。 しかし、通りかかった狩人が狼のお腹を切り開き、赤ずきんちゃんとおばあさんを救出します。赤ずきんちゃんは教訓を得て、二度と森で道を外れないと心に誓いました。 G-Evalが評価した結果は下記になります。(1回目を抜粋) - 回答の関連性 (Answer Relevancy): 0.912 - Expected Outcome: Fully addresses every aspect of the user question; no missing or extraneous information and a clear, logical focus. - Reason: The summary includes key characters like Little Red Riding Hood, her grandmother, the wolf, and the hunter. It logically organizes the flow of events, such as the journey through the forest, the encounter with the wolf, and the rescue. Important events like the wolf's deception and the rescue by the hunter are covered. The summary is faithful to the original text and concise, with no extraneous information. - 正確さ (Correctness): 0.901 - Expected Outcome: All statements align perfectly with the provided ground-truth reference or verifiable facts; zero errors. - Reason: The main facts in the Actual Output align well with the Retrieval Context, including the characters, events, and moral of the story. Minor details like the specific dialogue and actions are slightly condensed but do not affect the overall accuracy. - 幻覚の有無 (Hallucination): 0.903 - Expected Outcome: All content is grounded in the given context or universally accepted facts; no unsupported claims. - Reason: The output closely follows the context with accurate details about Little Red Riding Hood, her grandmother, the wolf, and the hunter. The sequence of events and character actions are consistent with the context, with no unsupported claims. スコアを決定した評価理由を見ますと、各指標に対して的確に評価しているようにみえます。 3.2. 指標の選定 で、G-Evalは評価に揺らぎがあることを紹介しました。よって、上記のスクリプトを50回実行して、計測した評価数値の散布図は下記になります。 結果的には、すべての指標でスコア値が概ね 0.9以上 になりましたが、これで各指標のSLI値を概ね0.9としてSLOを0.9以上として目標値に掲げることはできるでしょうか？ 3.5. 評価指標のレビュー 上記で紹介したとおり、このサービスは、 グリム童話を要約して、子供でもわかるような文章で要約してくれるサービス です。 上記の要約結果を 子供でもわかるように するには、下記の指標も考慮しないといけないでしょう。 可読性 (Readability): 子供が読めない難しい漢字、表現が使われていないか？ 騙して?、教訓?、ぶどう酒? 安全性・有害性 (Toxicity / Safety): 現代のコンプライアンスと照らし合わせて、子供には過激な表現が使われていないか? お腹を切り開き? 評価指標はお客さま価値とビジネスKPIと密接に関連付けることを意識して評価指標を選定する必要があります。 今回の要約サービスの場合、一般的評価指標より、対象者を考慮して上記の指標をタスク固有指標(Task-Specific Metrics)として最優先に考える指標にするべきです。 また、それに伴い、プロンプトも修正しなければならないでしょう。 とはいえ、初回から完璧な指標セットを作るのは困難です。 The Complete LLM Evaluation Playbook: How To Run LLM Evals That Matter では、 評価指標はまず1つから始め、最終的には5つに絞る指標設計が望ましい とありました。 評価指標のスコアが、 Metric Outcome Fit – 指標と成果のつながり (子どもたちに頻繁に利用されること)と、どれだけ一致しているか、意識しながら指標を選定、計測、評価する必要があります。 (実サービスだった場合、ビジネスKPIとしては、文章より画像で提供した方が、良い成果が得られるかもしれません) 3.6. 自動化の可能性を探る 今回の例では、人間が指標の選定、評価スコアの算出、評価スコアの算出、指標評価のレビューを実施しました。 G-EvalはGPT-4クラスのモデルに「評価手順を自分で分解して考えさせ、最終スコアだけを返させる」仕組みをとるため、人間の代わりに 評価基準の適用・スコアリング・集計までをワンショットで自動化できます。 以下はその手順例です。 評価タスクの提示: 評価に使うLLMに対し、「これから提示する生成文をある評価基準に従って1〜5点で採点して下さい」といったタスク説明を与える。その際に、その評価基準の定義も明示してLLMに文脈を教える(例えば、LLMサービスの一般的評価指標にあった指標一覧を提示する) 評価観点の分解: 1.でLLMが選定した指標に対して、必要な観点やステップを自ら列挙させる スコア算出: 続いてモデルに、先ほど生成した評価ステップに従い、実際の入力・出力を評価させる 注意点として、LLMが評価者だと“LLMらしい”出力を過大評価し、数語仕込むだけでスコアを操作される脆弱性があります。そのため、別系列のLLMモデルで評価してみることや、2つの回答を並べてどちらが良いか比べるペアワイズ比較、異常検知などで緩和を試みても、完全な中立性は保証できません。 また、 3.2. 指標の選定 でも紹介しましたが、G-Evalは確率的評価手法が故に、同じ回答でも評価が揺らぐという再現性に問題があり、評価プロンプトやシードを固定するなどの工夫が必要です。 これらの理由から、最終判断は必ず人間のレビューを併用して補正・検証する二段構えを取ることが不可欠です。 4. まとめ LLMサービスの信頼性評価に不可欠な指標の選定から、具体的な測定・評価方法までを、DeepEvalライブラリを用いたデモを交えてご紹介しました。 従来のAvailabilityやLatencyといった指標だけでは測りきれない『LLMサービスの信頼性評価』の指標をSLIとしてどう定義するかは、SREにとっても新しい分野だと思います。 本記事で試したDeepEvalなどの評価ツールのアプローチも、数ある選択肢の一つに過ぎません。LLMの評価指標は現在も絶賛研究中の分野であり、LLMサービスの信頼性をどう測るか、という問いに、まだ唯一の正解はなさそうです。ただ、この先、新しい評価指標や新しい測定手法が発見されたとしても、 『この指標は本当にお客さま満足度を表しているのか？』 という問いは、変わることのない本質的な問いかけだと思います。 技術の進歩とともに、この問いかけを忘れず、日々のSRE業務に取り組んでいければ幸いです。 明日の記事は @k_kinukawaさんの「メルカリモバイル Dev OffsiteでAI Hackathonをした話」です。引き続きお楽しみください。 References Site Reliability Engineering Book: https://sre.google/books/ LLM Evaluation Metrics: The Ultimate LLM Evaluation Guide: https://www.confident-ai.com/blog/llm-evaluation-metrics-everything-you-need-for-llm-evaluation The Accuracy Trap: Why Your Model’s 90 % Might Mean Nothing: https://medium.com/%40edgar_muyale/the-accuracy-trap-why-your-models-90-might-mean-nothing-f3243fce6fe8 The Complete LLM Evaluation Playbook: How To Run LLM Evals That Matter: https://www.confident-ai.com/blog/the-ultimate-llm-evaluation-playbook レーベンシュタイン距離: https://note.com/noa813/n/nb7ffd5a8f5e9 LLM evaluation metrics — BLEU, ROUGE and METEOR explained: https://avinashselvam.medium.com/llm-evaluation-metrics-bleu-rogue-and-meteor-explained-a5d2b129e87f BERTScore: https://openreview.net/pdf?id=SkeHuCVFDr BERT: https://en.wikipedia.org/wiki/BERT_(language_model) コサイン類似度: https://atmarkit.itmedia.co.jp/ait/articles/2112/08/news020.html MoverScore: https://arxiv.org/abs/1909.02622 Earth Mover’s Distance（最適輸送距離）: https://zenn.dev/derwind/articles/dwd-optimal-transport01#%E6%9C%80%E9%81%A9%E8%BC%B8%E9%80%81%E8%B7%9D%E9%9B%A2 G-Eval (Paper): https://arxiv.org/abs/2303.16634 G-Eval Simply Explained: LLM-as-a-Judge for LLM Evaluation: https://www.confident-ai.com/blog/g-eval-the-definitive-guide QAG Score: https://arxiv.org/abs/2210.04320 SelfCheckGPT: https://arxiv.org/abs/2303.08896 DAG(deep acyclic graph): https://deepeval.com/docs/metrics-dag Prometheus2 Model: https://arxiv.org/abs/2405.01535 DeepEval: https://deepeval.com/docs/getting-started Vertex AI – モデルベース評価の指標プロンプト テンプレート: https://cloud.google.com/vertex-ai/generative-ai/docs/models/metrics-templates 赤ずきん: https://ja.wikipedia.org/wiki/%E8%B5%A4%E3%81%9A%E3%81%8D%E3%82%93

はじめに こんにちは！メルペイの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関連の技術についても積極的にキャッチアップするようになりました。 社内のコードを漁る コードを読み進めることで、開発基盤やソフトウェアアーキテクチャなどについて理解を深めることができました。マイクロサービスなので、各サービスの全体像の把握がしやすく、学びやすかったです。インターンではせっかく実際に会社で働けるので、タスクに取り組むだけでなく、自分がこのインターンで学べることは何か？を積極的に考えていくと良いと思いました。 さいごに 以上が、私がインターンで行ったことやその感想でした。 メルペイでのインターンを通して、自分の中でできることや今後のキャリアに向けた視野がグッと広がったと感じています。 ２ヶ月間ありがとうございました！！