こんにちは。医療プラットフォーム本部 歯科診療所事業部 DENTIS開発グループの藤原です。 2026年4月にメドレーに入社、エンジニアとしてクラウド歯科業務支援システム「 DENTIS 」を開発しています。 メドレーは2026年5月30日に岐阜県の関ケ原ふれあいセンターにて開催された「関ケ原Ruby会議01」にGoldスポンサーとして協賛しました！ 関ケ原Ruby会議01 関ケ原Ruby会議01は、天下分け目の地「関ケ原」で開催される地域Ruby会議です。2026年5月30日（土）開催。 regional.rubykaigi.org 関ケ原Ruby会議は地域Ruby会議のうちのひとつで、開催地の岐阜周辺の方々だけではなく、全国からRubyエンジニアが集うイベントです。 入社したての私も含め、エンジニアとDevRelの計3名が現地参加し、多くの方々と交流させていただきました。 今回は会場・ブースと発表の様子をご紹介します。 道中 関ケ原駅から徒歩10分、関ケ原の戦いについての紹介ボードを見ながら会場へ向かいました。 会場の様子 会場には西軍・東軍の幟が立っていました。 登壇者ごとに武将ネームが記載されていましたので、東軍で登壇する弊社の牧とブーススタッフで記念撮影をいたしました。 発表は400席を超える大ホールにて行われました。 弊社ブースの様子 弊社ブース企画として、生成AIの活用アンケート・XフォローでのノベルティGETガラポンチャレンジを実施いたしました。 発表の様子 どのセッションも非常に面白かったのですが、個人的に印象に残ったセッションを少し紹介します。 【西軍 次鋒】 Termfront: Ruby標準ライブラリだけで作るFPS Termfront: Ruby標準ライブラリだけで作るFPS - 関ケ原Ruby会議01 関ケ原Ruby会議01は、天下分け目の地「関ケ原」で開催される地域Ruby会議です。2026年5月30日（土）開催。 regional.rubykaigi.org Rubyの標準ライブラリのみで作られた、ターミナル上で動くFPS「Termfront」の発表です。 登壇者のS.H.さんはFPSが好きでスキマ時間にもプレイされるとのことです。 しかし最近はAIへの指示などでまとまった待ち時間が少なく、5〜10分程度のセッション（試合）かつ簡単に開始できるようターミナルにされたようです。 ターミナルなので当然2Dなのですが、擬似的な3D化により奥行きがあるように見えます。 音声だけは外部のライブラリではあるものの、それ以外はRuby標準ライブラリのみで実装されており、合戦（通信対戦）も可能でした。 最近はターミナルの表現力を上げる「ターミナルUI」が流行っていますが、まさかゲームまで作れるとは思わず驚きました。 【東軍 中堅】 Play Music on Ruby ── PicoRubyで作るMIDIオーケストレーションツール Play Music on Ruby ── PicoRubyで作るMIDIオーケストレーションツール - 関ケ原Ruby会議01 関ケ原Ruby会議01は、天下分け目の地「関ケ原」で開催される地域Ruby会議です。2026年5月30日（土）開催。 regional.rubykaigi.org 弊社の牧による、MIDI（Musical Instrument Digital Interface：電子楽器の音声の転送規格）オーケストレーションツール「MIDoRI」の発表です。 2023年のKeebKaigiでの発表をきっかけに、入出力・加工も可能な汎用的なMIDIデバイス開発を目指しているとのことです。 PicoRubyの対応デバイスの増加・デバイス性能の向上により、実現されたものが今回の内容でした。 デモではMIDIキーボードとSEQTRACK（ヤマハ株式会社）の間にMIDoRIデバイスを繋ぎ演奏されました。 琴と尺八を制御するためのキーボードのスプリットや、各機能のオン・オフ切り替えで使うタッチパッドの制御はRubyで書かれており、他のデバイスとも自由に組み合わせられるようです。 PicoRubyへの取り込みに向けて活動中とのことで、今後はRubyカンファレンスで電子楽器も見ることになると思うと楽しみです。 ランチ・おやつ お弁当とレジャーシートを受け取って会場外へ。天候は晴れで風も涼しく、絶好のピクニック日和でした。 庭では東軍・西軍の各大将へのインタビューも行われ、最後は「それではしばしの休戦をお楽しみください」という初めて聞く日本語で締められました。 RubyKaja RubyKaja 2026 受賞者 RubyKaja 2026 の受賞者、推薦理由、参加コミュニティを紹介します。 kaja.rubyist.net RubyKajaは2012年に「 互いに褒め合い賞賛し合う文化を生み出し、自身や周囲の活躍を積極的にアピールしていく世界を作っていきたい 」として始まったそうです。 今回はRubyコミュニティから20名の紹介と、特別賞として5名が表彰されました。 （本イベントで登壇した弊社の牧も選出されました✨） コミュニティを維持・継続する活動は外から分かりづらいため、こうして貢献が評価されるのは素敵なことだと思いました。 合戦 いずれも素晴らしい発表だったのですが、ここは関ケ原。決着をつけるための決戦が始まりました。 東軍・西軍に分かれて籠攻め（玉入れ）を行い…惜しくも西軍の勝利となりました。 最後は全員で記念撮影してクロージングとなりました。 最後に 東軍・西軍に分かれての発表や合戦、武将のような言葉遣い「武将語」など、他にはない特色・関ケ原の地でカンファレンスをすることへの熱意に触れられた素晴らしいイベントでした。 奉行衆（運営スタッフ）の皆様、武将（登壇者）の皆様、参加者の皆様も本当にありがとうございました！ メドレーではエンジニアを積極採用中です！ メドレーではRubyを積極的に活用して、医療ヘルスケアの未来をつくるプロダクトを開発しています。 医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp Medley Engineer Entrance Book この度は株式会社メドレーに興味をお寄せいただきありがとうございます。本資料は、メドレーへの転職をご検討いただいている皆様に、当社をより深くご理解いただくために作成いたしました。 medley-inc.notion.site

こんにちは。医療プラットフォーム本部 歯科診療所事業部 DENTIS開発グループの藤原です。 2026年4月にメドレーに入社、エンジニアとしてクラウド歯科業務支援システム「 DENTIS 」を開発しています。 メドレーは2026年5月30日に岐阜県の関ケ原ふれあいセンターにて開催された「関ケ原Ruby会議01」にGoldスポンサーとして協賛しました！ 関ケ原Ruby会議01 関ケ原Ruby会議01は、天下分け目の地「関ケ原」で開催される地域Ruby会議です。2026年5月30日（土）開催。 regional.rubykaigi.org 関ケ原Ruby会議は地域Ruby会議のうちのひとつで、開催地の岐阜周辺の方々だけではなく、全国からRubyエンジニアが集うイベントです。 入社したての私も含め、エンジニアとDevRelの計3名が現地参加し、多くの方々と交流させていただきました。 今回は会場・ブースと発表の様子をご紹介します。 道中 関ケ原駅から徒歩10分、関ケ原の戦いについての紹介ボードを見ながら会場へ向かいました。 会場の様子 会場には西軍・東軍の幟が立っていました。 登壇者ごとに武将ネームが記載されていましたので、東軍で登壇する弊社の牧とブーススタッフで記念撮影をいたしました。 発表は400席を超える大ホールにて行われました。 弊社ブースの様子 弊社ブース企画として、生成AIの活用アンケート・XフォローでのノベルティGETガラポンチャレンジを実施いたしました。 発表の様子 どのセッションも非常に面白かったのですが、個人的に印象に残ったセッションを少し紹介します。 【西軍 次鋒】 Termfront: Ruby標準ライブラリだけで作るFPS Termfront: Ruby標準ライブラリだけで作るFPS - 関ケ原Ruby会議01 関ケ原Ruby会議01は、天下分け目の地「関ケ原」で開催される地域Ruby会議です。2026年5月30日（土）開催。 regional.rubykaigi.org Rubyの標準ライブラリのみで作られた、ターミナル上で動くFPS「Termfront」の発表です。 登壇者のS.H.さんはFPSが好きでスキマ時間にもプレイされるとのことです。 しかし最近はAIへの指示などでまとまった待ち時間が少なく、5〜10分程度のセッション（試合）かつ簡単に開始できるようターミナルにされたようです。 ターミナルなので当然2Dなのですが、擬似的な3D化により奥行きがあるように見えます。 音声だけは外部のライブラリではあるものの、それ以外はRuby標準ライブラリのみで実装されており、合戦（通信対戦）も可能でした。 最近はターミナルの表現力を上げる「ターミナルUI」が流行っていますが、まさかゲームまで作れるとは思わず驚きました。 【東軍 中堅】 Play Music on Ruby ── PicoRubyで作るMIDIオーケストレーションツール Play Music on Ruby ── PicoRubyで作るMIDIオーケストレーションツール - 関ケ原Ruby会議01 関ケ原Ruby会議01は、天下分け目の地「関ケ原」で開催される地域Ruby会議です。2026年5月30日（土）開催。 regional.rubykaigi.org 弊社の牧による、MIDI（Musical Instrument Digital Interface：電子楽器の音声の転送規格）オーケストレーションツール「MIDoRI」の発表です。 2023年のKeebKaigiでの発表をきっかけに、入出力・加工も可能な汎用的なMIDIデバイス開発を目指しているとのことです。 PicoRubyの対応デバイスの増加・デバイス性能の向上により、実現されたものが今回の内容でした。 デモではMIDIキーボードとSEQTRACK（ヤマハ株式会社）の間にMIDoRIデバイスを繋ぎ演奏されました。 琴と尺八を制御するためのキーボードのスプリットや、各機能のオン・オフ切り替えで使うタッチパッドの制御はRubyで書かれており、他のデバイスとも自由に組み合わせられるようです。 PicoRubyへの取り込みに向けて活動中とのことで、今後はRubyカンファレンスで電子楽器も見ることになると思うと楽しみです。 ランチ・おやつ お弁当とレジャーシートを受け取って会場外へ。天候は晴れで風も涼しく、絶好のピクニック日和でした。 庭では東軍・西軍の各大将へのインタビューも行われ、最後は「それではしばしの休戦をお楽しみください」という初めて聞く日本語で締められました。 RubyKaja RubyKaja 2026 受賞者 RubyKaja 2026 の受賞者、推薦理由、参加コミュニティを紹介します。 kaja.rubyist.net RubyKajaは2012年に「 互いに褒め合い賞賛し合う文化を生み出し、自身や周囲の活躍を積極的にアピールしていく世界を作っていきたい 」として始まったそうです。 今回はRubyコミュニティから20名の紹介と、特別賞として5名が表彰されました。 （本イベントで登壇した弊社の牧も選出されました✨） コミュニティを維持・継続する活動は外から分かりづらいため、こうして貢献が評価されるのは素敵なことだと思いました。 合戦 いずれも素晴らしい発表だったのですが、ここは関ケ原。決着をつけるための決戦が始まりました。 東軍・西軍に分かれて籠攻め（玉入れ）を行い…惜しくも西軍の勝利となりました。 最後は全員で記念撮影してクロージングとなりました。 最後に 東軍・西軍に分かれての発表や合戦、武将のような言葉遣い「武将語」など、他にはない特色・関ケ原の地でカンファレンスをすることへの熱意に触れられた素晴らしいイベントでした。 奉行衆（運営スタッフ）の皆様、武将（登壇者）の皆様、参加者の皆様も本当にありがとうございました！ メドレーではエンジニアを積極採用中です！ メドレーではRubyを積極的に活用して、医療ヘルスケアの未来をつくるプロダクトを開発しています。 医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp Medley Engineer Entrance Book この度は株式会社メドレーに興味をお寄せいただきありがとうございます。本資料は、メドレーへの転職をご検討いただいている皆様に、当社をより深くご理解いただくために作成いたしました。 medley-inc.notion.site

こんにちは。メルペイ Payment & Customer Platform（PCP）チームでBackend Engineerをしている @ryuyama です。この記事は「 Merpay & Mercoin Tech Openness Month 2026 」の1日目の記事です。 はじめに メルカリでは、2025年9月30日にグローバル版のメルカリアプリをリリースしました。このアプリは台湾・USをはじめとして、 3年以内に50カ国へ展開することを目指しており 、メルカリのグローバル展開を加速させるための重要なマイルストーンとなりました。 この記事では、メルカリ グローバルアプリ（以下、グローバルアプリ）のリリースに向けて、Payment Platformがどのような課題に向き合い、どのようにアーキテクチャを進化させてきたのかを紹介します。 Payment Platformに課せられたミッション グローバルアプリ対応プロジェクトが立ち上がった際に、Payment Platformに課せられたミッションは、 「3年以内に50カ国展開できる決済・会計システムを作ること」 でした。 そこで、Payment Platformのシステムを大きく「決済」と「会計」のドメインに分け、達成すべきゴールを整理しました。 決済基盤としては、主に以下のような対応が求められました。 50カ国の通貨・決済手段への対応 決済画面の多言語対応 複数のPSP（決済事業者）との接続 為替レートを考慮した金額計算 不正利用やチャージバックのリスクへの対応 会計基盤としては、以下のような状態をゴールと置きました。 通貨ごと、国・地域ごとの売上、返金、決済手数料を正しく集計できること PSP（決済事業者）からの入金と、メルカリ側の取引データを照合できること 在庫変動や税務関連の会計イベントを、外部システムから会計システムへ正しい粒度・タイミングで連携できること 既存の国内向け会計システムとの整合性を保ちながら、新しい会計基盤へ移行できること また、これらを一度きりのゴールとして実装するのではなく、グローバル展開のコストとスピードを強く意識する必要がありました。例えば、通貨や決済手段の追加をできるだけ迅速に行い、展開国を早く増やせること。不正対策、税務、会計などの各国・地域ごとの最適化を、それぞれ独立して進められることが求められました。 Payment Platformの進化 既存のPayment Platform 先ほど掲げたミッションを達成するために、現在のアーキテクチャにある課題洗い出しを行いました。Payment Platformは、日本のメルカリアプリの決済基盤をベースにして誕生し、 メルペイの成長とともに進化してきました 。 決済のレイヤーでは、Payment Serviceというマイクロサービスが存在します。Payment Serviceでは、メルカリで商品を購入し、取引が完了するとお金が移動するという一連の取引を表現した Escrow というリソースや、お金の動きに注目した Charge、さらに3Dセキュアの普及や高度化する決済手段への対応のために Source というリソースが開発されてきました。 会計のレイヤーでは、Balance Service（残高サービス）やAccounting Service（会計サービス）といったサービスが存在します。Balance Serviceはお客さまの残高や加盟店の売上残高の管理を、Accounting Serviceは会計イベントの保存と経理向けのレポーティングを責務としています。 これらはいずれも、これまでのメルカリグループ全体の成長を支えてきた重要なサービスです。 一方で、グローバル対応に向けて、特に「展開コスト」と「展開スピード」という観点において、いくつかの課題がありました。 グローバル展開に向けた課題 PSPや決済手段の追加にPayment Serviceが必要 1つ目の課題は、Payment Serviceにおいて、PSP（決済事業者）との接続ロジックと Source リソースが密結合していたことです。 グローバル展開では、国や地域によって利用される決済手段が異なります。また、接続すべきPSPも国や地域ごとに変わる可能性があります。 そのため、新しいPSPや決済手段を追加するたびにPayment Serviceのロジックへ変更が入る状態では、展開国が増えるほど開発・運用コストが増大してしまいます。 また、Source が特定の決済手段と密結合していたため、新しい決済手段を追加する際には、新しいリソース定義や既存リソースへの影響を慎重に検討する必要がありました。 国内向けの決済基盤としては十分に機能していた設計でも、50カ国展開を前提にすると、決済手段やPSPの追加をより小さな変更範囲で実現できる構成が必要でした。 残高と会計イベントの整合性がアーキテクチャで保証できていない 2つ目の課題は、残高管理と会計イベントの整合性です。 既存の構成では、Balance Serviceが残高を管理し、Accounting Serviceが会計イベントを保存していました。しかし、両者の整合性は会計レイヤー自体で保証されているわけではなく、Payment Service側のサービス間トランザクション管理に依存していました。 グローバル展開では、通貨ごと、国・地域ごと、PSPごとの売上、返金、決済手数料を正しく集計できることが求められます。また、PSPからの入金とメルカリ側の取引データを照合できることや、在庫変動・税務関連の会計イベントを外部システムから会計システムへ正しい粒度・タイミングで連携できることも必要になります。 そのため、単に決済処理の結果を保存するだけではなく、後続の照合やレポーティング、既存の国内向け会計システムとの整合性を見据えた会計基盤が必要でした。 この課題は、グローバル対応が始まる以前から、メルカリのグローバルなマーケットプレイスの実現というビジョンに向けての課題だと認識されていました。これらの課題は次世代の会計システムであるBalance V2やBookkeeperとして、 メルコイン やメルカリ ハロの立ち上げに合わせて導入され、実運用の中で磨き上げられていました。一方で、メルカリのマーケットプレイスに関連する領域では既存システムからの移行コストが高く、導入の機会を待っている状況でした。 現在のアーキテクチャ Payment Platformでは、グローバル対応に合わせて2つの大きな意思決定を行いました。 1つ目は、PSP（決済事業者）と接続するための処理をPayment ServiceからPSPとの接続を責務とするPayment Provider Serviceに切り出し、PSPとの接続ロジックや決済手段に関するロジックを決済リソース管理から分離することです。 2つ目は、会計システムにBalance V2とBookkeeperを利用し、Payment Serviceのトランザクション管理による整合性の管理から、残高と会計イベントが整合したモデルで扱われるアーキテクチャへ移行することです。 Payment Serviceが決済リソースのライフサイクル管理に集中する 新しいアーキテクチャでは、Payment Serviceの責務をより明確にしました。 Payment Serviceは注文や取引に紐づく決済リソースのライフサイクル管理に集中し、決済の作成、オーソリ、キャプチャ、キャンセルなどといった状態遷移を管理します。 一方で、どのPSPのAPIをどのように呼び出すか、各決済手段にどのようなパラメータが必要でPSPから返ってくるレスポンスやWebhookをどのように処理するかといった詳細はPayment Provider Serviceに切り出しました。 これにより、Payment Serviceは特定のPSPや決済手段に強く依存せず、より安定した決済リソース管理の責務に集中できるようになりました。 Balance V2 / Bookkeeperで残高と会計イベントの一貫性を担保する 会計基盤には、 Balance V2 とBookkeeperを利用しました。 Balance V2とBookkeeperでは、残高の変動と会計イベントを一貫したモデルとして扱います。これにより、残高更新と会計イベントの記録が別々のデータとして管理されるのではなく、複式簿記のように、「現在の残高（ストック）」と「残高が変化した理由（フロー）」を対応づけて保存されるようになりました。 このアーキテクチャにより、Payment Service側で残高と会計イベント間の整合性を保つ複雑なサービス間トランザクション管理を担う必要が減り、Payment Serviceは決済リソースの管理により集中できるようになりました。 終わりに 今回のプロジェクトでは、グローバル展開に必要な決済・会計基盤の土台を作ることができました。 記事執筆時点では台湾・USへのローンチが完了し、クレジットカード決済・Apple Pay・Google Payなどの決済手段にも対応しています。 また、Payment Platformで実現した抽象化を利用して、カートを使ったまとめ買い機能などの新しい購入体験も日本国内に先立ってグローバルアプリで提供することができました。 一方で、今後取り組むべき課題もまだ残っています。 例えば、日本のメルカリで日本円で売られている商品を海外通貨で販売する時の為替変換の仕組みは、現時点ではグローバルアプリ専用の実装に近く、社内のPayment Platformを利用しているチームにとって十分になめらかな体験になっているとは言えません。また、グローバルアプリ内でのポイントや残高の利用サポートも、今後進めていく必要があります。 そして、より長期的には、今回整備した基盤を日本国内のメルカリにも適用するプロジェクトも進行しています。今回整備したグローバル向けの基盤や設計を国内向けの基盤にも還元することで、Payment Platform全体をより柔軟で拡張しやすい基盤へ進化させていきたいと考えています。 次の記事は mattsuuさんです。引き続きお楽しみください。