はじめに こんにちは。医療プラットフォーム本部 CLINICS 開発グループの吉岡です。 メドレーは 5 月 22 日・23 日にベルサール羽田空港にて開催された TSKaigi 2026 に Bronzeスポンサーとして協賛しました。 TSKaigi は、日本最大級の TypeScript をテーマとした技術カンファレンスで、2024 年の第 1 回から毎年協賛しています。 今年は現地参加 800 人、オンライン参加 900 人を超える規模で開催されました。 TSKaigi 2026 会場（ベルサール羽田空港） TSKaigi 2026 では、TypeScript 7 で正式リリースとなる tsgo に関するセッションが多く見られました。 本記事では、弊社から登壇した髙橋のセッションと、その他に印象に残ったセッションについて紹介します。 弊社・髙橋の登壇「次世代リンターで探る、tsgo 時代における型認識カスタムルールの現実解」 Day2 の Leverages トラックにて、弊社の髙橋が登壇しました。 次世代リンターで探る、tsgo 時代における型認識カスタムルールの現実解 | TSKaigi 2026 TSKaigi 2026 のスピーカー、トーク情報です。 2026.tskaigi.org 発表内容 発表では、まず型認識リントについて、typescript-eslint、Oxlint、Rslint、Biome の各リンターの対応状況が整理されました。続いて、Rslint に対して型認識カスタムルールを Go 言語で実装し、独自ビルドしたリンターバイナリで実際に診断できることを示したPoCのデモがありました。 特に勉強になったのは、こうしたカスタムルールは typescript-go の internal API に依存することになり、その追従コストを考慮する必要があるという点です。型認識カスタムルールで対応するのではなく、コード規約と設計を工夫して、ASTのみで判定可能なカスタムルールと型チェックで解決できないかを最初に検討すべきだという指針が示されました。 余談ですが、発表前日に Oxlint JS Plugin から tsgo の型情報を問い合わせる方法を実証した OSS である corsa-bind を発見し、当日の朝に急遽スライドを追加して臨んだという裏話もありました。 次世代リンターにおけるカスタムプラグインの今後の動向に注目していきたいですね。 発表中の様子 印象に残ったセッション tscからtsgoへ ── DenoのTypeScript基盤はどう変わったか 登壇者: maguro さん tscからtsgoへ ── DenoのTypeScript基盤はどう変わったか | TSKaigi 2026 TSKaigi 2026 のスピーカー、トーク情報です。 2026.tskaigi.org Phase 1 では、tsc にパッチを当てた JavaScript ファイルを Deno binary に埋め込み、V8 isolate 内で実行していました。 Phase 2 では、tsgo を fork して子プロセスで動かすことで、型チェック（ deno check ）が約 2.5 〜 2.6 倍に高速化されました。一方で、上流追従と LSP 対応のコストが重いことが課題となっていました。 そして現在進行中の Phase 3 では、fork をやめ、Deno 側のソースを公式 TypeScript が読める形に materialize して、npm の公式 TypeScript に処理させる方針へと進んでいます。 「fork も再実装も避けたい」という制約の中で公式 TypeScript への統合を進める Deno の方針が印象的でした。 TS 7: How We Got There 登壇者: Jake Bailey さん TS 7: How We Got There | TSKaigi 2026 TSKaigi 2026 のスピーカー、トーク情報です。 2026.tskaigi.org TypeScript チーム本人による基調講演で、TypeScript コンパイラを Go 言語へ移植した背景が語られました。セッションでは tsgo のデモが行われ、従来 2 分ほどかかっていた型チェックが 10 秒に短縮される様子が示されました。 コンパイル時の処理は Parse、Bind、Check、Emit の順で行われます。特に印象的だったのは、Checker で生成される型情報を Checker 間で共有しないことで、並列実行時の同期オーバーヘッドを避けて高速化を実現している点です。 CLINICS でもローカル環境で tsgo を使用しており、型チェックを高速化することで、AI 開発のフィードバックを速めています。 制約と時代から読み解くTypeScriptコンパイラ設計史 登壇者: Yoshiaki Togami さん 制約と時代から読み解くTypeScriptコンパイラ設計史 | TSKaigi 2026 TSKaigi 2026 のスピーカー、トーク情報です。 2026.tskaigi.org TypeScript コンパイラは、AST が semantic 情報を背負い、循環参照だらけの構造になっているという独特な構成を持っています。 Web の歴史の中で Ajax 革命や V8 / Chrome / Node.js の登場により JavaScript で大規模なソフトウェアが書かれるようになり、Microsoft 内部でも Office などの Web 移植が迫られていました。一方で、当時の JavaScript 向け開発ツーリングは貧弱で、大規模開発の体験が成立しなかったため、それを解決するために TypeScript が開発されました。 さらに、TypeScript には IDE での高速な応答が要件として課せられました。本来であれば immutability と親アクセスを両立する仕組みが必要でしたが、当時の JavaScript では実現できず、結果として AST に直接 symbol や parent を書き込む現在の構成に落ち着いています。 tsgo ではネイティブ化と共有メモリ・マルチスレッド化で約 10 倍の高速化が実現されています。歴史を遡ることで、現在の TypeScript がなぜこのような設計になっているのかという背景を理解できました。 まとめ 本記事では、弊社・髙橋の登壇と、TSKaigi 2026 で印象に残ったセッションについて紹介しました。 今年のメドレーからは、Bronzeスポンサーとしての協賛と髙橋の登壇に加え、運営スタッフとしても德永と山河の 2 名が TSKaigi 2026 に関わりました。 TSKaigi 2026 に参加したメドレーメンバー メドレーでは今後も TypeScript コミュニティの発展に貢献し、社内での実践を続けていきます。 過去にスポンサーとして協賛した TSKaigi の参加レポートはこちらです。 TSKaigi 2025 参加レポート：新卒2年目エンジニアが感じたTypeScriptの最前線 | MEDLEY Developer Portal はじめに こんにちは！ 人材プラットフォーム本部プロダクト統括部プロダクト開発部アカデミー開発グループ所属の城間（シロマ）です。 私は 2024 年 4 月に新卒エンジニアとして入社し、現在はオンライン動画研修サービス「ジョブメドレーアカデ... developer.medley.jp TSKaigi 2024のスポンサーLTでTypeScriptコード改善の取り組みについて紹介しました | MEDLEY Developer Portal こんにちは。医療プラットフォーム本部プロダクト開発室 CLINICS 第二開発グループ所属の髙橋です。 メドレーは 5 月 11 日に中野セントラルパークカンファレンスにて開催された TSKaigi 2024 に Gold Sponsor ... developer.medley.jp We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、「お話だけでも聞いてみたい！」「ちょっと雑談してみたい！」でも構いませんので、お気軽にお問い合わせください！ メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp Medley Engineer Entrance Book この度は株式会社メドレーに興味をお寄せいただきありがとうございます。本資料は、メドレーへの転職をご検討いただいている皆様に、当社をより深くご理解いただくために作成いたしました。 medley-inc.notion.site

はじめに こんにちは！メドレーDevRelの重田（ @Shige0096 ）です。 メドレーは、2026年5月30日(土)に岐阜県関ケ原町で開催される地域Ruby会議 「関ケ原Ruby会議01」 にGoldスポンサーとして協賛します！ 関ケ原Ruby会議01 関ケ原Ruby会議01は、天下分け目の地「関ケ原」で開催される地域Ruby会議です。2026年5月30日（土）開催。 regional.rubykaigi.org 本記事では、イベントの概要やメドレーのブース情報、そして当日登壇する弊社社員のセッションについて先行情報をお伝えします！ 「関ケ原Ruby会議01」とは？ 「天下分け目の地域Ruby会議」と銘打たれた 関ケ原Ruby会議01 は、歴史ある古戦場の地「関ヶ原」で開催される新たな地域Ruby会議です。 開催日 ：2026年5月30日(土) 会場 ：関ケ原ふれあいセンター（岐阜県不破郡関ケ原町） 全国からRubyistが集まり、熱い議論や知見の共有が行われる、まさに「天下分け目」の盛り上がりが期待されるカンファレンスです。 Goldスポンサーとしてブース出展します！ 当日は、会場内のスポンサーブースエリアにてメドレーもブースを出展いたします！ ブースでは、AIに関するアンケート調査をはじめ、お立ち寄りいただいた方のために、 オリジナルノベルティ もご用意しています。ぜひお気軽に足を運んでみてください！ メドレーのエンジニアが登壇します！ 弊社の医療プラットフォーム本部歯科診療所事業部 事業部長 兼 DENTIS開発グループ グループマネジャーの 牧（@kirikak2） が登壇します！ 時間 ：14:30-14:50 セッション詳細 ： Play Music on Ruby ── PicoRubyで作るMIDIオーケストレーションツール - 関ケ原Ruby会議01 関ケ原Ruby会議01は、天下分け目の地「関ケ原」で開催される地域Ruby会議です。2026年5月30日（土）開催。 regional.rubykaigi.org セッションの見どころを、発表者の牧よりコメントいただきました！ こうして会社のブログで紹介してもらうのも恐縮なのですが、普段やっている仕事とは全く関係のない趣味100%の電子楽器とRubyに関する発表をします。マニアックな内容ですが、なるべく初めての人にも分かるように解説しながら発表しますので、こういう世界もあるんだ〜という気持ちで聞いていただけると幸いです。 おわりに メドレーは「医療ヘルスケアの未来をつくる」をミッションに掲げ、医療ヘルスケア領域における社会課題を解決するプロダクトをRubyを中心に開発しています。 今回の関ケ原Ruby会議01を通じて、多くのRubyistの皆さまと現地でお会いし、熱いお話ができることを楽しみにしています。 当日、関ケ原ふれあいセンターのメドレーブース、およびセッション会場でお会いしましょう！ メドレーでは、Rubyが大好きなエンジニアを募集しています！（もちろんそれ以外のエンジニア職種も大歓迎・大募集中です！） まずはカジュアル面談でざっくばらんにお話しできるので、会場でお会いできない方はぜひこちらでお話ししましょう！お待ちしております！ 医療ヘルスケアの未来をつくる｜株式会社メドレー 株式会社メドレーのコーポレートサイトです。メドレーは、「医療ヘルスケアの未来をつくる」をミッションに掲げ、テクノロジーを活用した事業やプロジェクトを通じて「納得できる医療」の実現を目指します。 www.medley.jp 株式会社メドレー エンジニア 東京 の求人一覧 株式会社メドレー エンジニア 東京 の求人一覧です。| HRMOS hrmos.co

はじめに こんにちは！メドレーDevRelの重田（ @Shige0096 ）です。 日本最大級の TypeScript カンファレンス『TSKaigi 2026』の開催がいよいよ目前に迫ってきました。2024年の産声を上げてから、回を重ねるごとにエンジニアの熱量が高まっている本イベントですが、今年は羽田空港という新たな舞台で2日間にわたり開催されます。 実は、メドレーは2024年の第1回目から毎年協賛をしています✨ 本年も、TypeScript コミュニティのさらなる発展を願い、Bronzeスポンサーとして盛り上げていきたいと思います！ TSKaigi 2026 TSKaigiは日本最大級のTypeScriptをテーマとした技術カンファレンスです。2026/5/22 (金) - 23 (土) の日程で開催します。 2026.tskaigi.org メドレーのエンジニアが登壇します！ Day2の5/23（土）15:50 ~ 16:20 （Leveragesトラック）にて弊社の髙橋が登壇します。 次世代リンターで探る、tsgo 時代における型認識カスタムルールの現実解 | TSKaigi 2026 TSKaigi 2026 のスピーカー、トーク情報です。 2026.tskaigi.org 当日のセッションをよりお楽しみいただくために、今回は特別に先行情報を公開したいと思います！ 医科診療所プロダクト開発室 AI推進グループの髙橋です。Day2の15:50から「次世代リンターで探る、tsgo 時代における型認識カスタムルールの現実解」というタイトルで発表します。 TypeScript 7.0 / tsgo の登場により、型チェックやビルドが Go 実装で大幅に高速化される見込みです。一方で、これまで typescript-eslint の parser service 経由で Program や TypeChecker を使って実現していた型認識カスタムルールは、tsgo 時代にはどのように運用していけばよいのでしょうか。本セッションでは、この問いを軸にお話しします。 セッションは三部構成です。まず Oxlint / Rslint / Biome といった次世代リンターが、型認識ルールにどこまで対応しているのかを整理します。次に、Rslint を主軸に「処理契約値の捨て忘れ」を検出する型認識カスタムルールを PoC として実装し、実現可能性を評価します。最後に、その PoC を踏まえて、型認識カスタムルールを持続的に運用していくための論点を議論します。 AI コーディングエージェントによる「コード生成 → リント → 修正」ループが日常化していく時代に、型認識カスタムルールとどう付き合っていくかを皆さんと一緒に考える時間にできればと思っています。リンター・開発体験に関心のある方は、ぜひ当日聞きに来てください！ おわりに TSKaigiは、単なる事例発表の場ではなく、TypeScriptを愛するエンジニアが集い、現場の知恵や試行錯誤を分かち合うことで、コミュニティ全体の開発体験をアップデートしていくイベントです。 会場でメドレーの社員を見かけましたら、ぜひ話しかけていただけると嬉しいです！ 皆さんとお会いできるのを、弊社一同楽しみにしています。 それでは、羽田でお会いしましょう！ また、メドレーでは、TypeScriptが大好きなエンジニアを募集しています！（もちろんそれ以外のエンジニア職種も大歓迎・大募集中です！） まずはカジュアル面談でざっくばらんにお話しできるので、会場でお会いできない方はぜひこちらでお話ししましょう！お待ちしております！ 株式会社メドレー 正社員 エンジニア の求人一覧 株式会社メドレー 正社員 エンジニア の求人一覧です。| HRMOS hrmos.co

こんにちは！メドレーDevRelの重田（ @Shige0096 ）です。 4/22(水)-24(金) に函館で開催されたRubyKaigi に今年も参加してきたので、その参加レポートをお送りします👟 はじめに 株式会社メドレーはRubyスポンサーとして協賛し、現地でブース出展しました。 弊社のプロダクトの半数以上でRubyを用いていることもあり、 Rubyコミュニティへの貢献は、協賛活動の中でも特に重要視している活動です！ １番最初にロゴを掲載していただきました🙌 弊社VPoEの倉林（ @terukura ）が書き込み中✍️ 今年は役員を含め総勢13名で参加し、RubyKaigi を堪能しました✨ 本レポートでは、現地の様子や弊社のブース企画のご紹介を写真メインで雰囲気が伝わるようお伝えします！ ぜひ楽しんでご覧いただけると嬉しいです🙌 会場の様子 本年の開催場所は「函館」。（昨年の発表から心待ちにしていました!!!） 採用人事の福島さんとともに前日入りし、ブース設営⚒️ ブースの完成形。Rubyスポンサーは長机2つなので広々としていました🚩 上から見た会場。 弊社ブースのご紹介 ブース企画その１_Ruby×AIアンケート調査 以下3つのAIに関するアンケートをとりました！🔍 ご回答いただいた皆様、ご協力ありがとうございました！！ AI（生成AIなど）を開発に取り入れ始めたのはいつ頃ですか？ 使っている具体的なルールを教えて下さい AIを活用したRuby開発における成功体験やお困りごとを教えて下さい アンケート結果サマリ✍️ 1.AIを開発に取り入れ始めた時期 2024年前半： 早期導入層が一定数存在し、この時期から活用が始まる。 2024年後半〜2025年前半： ボリュームゾーン です。この期間に圧倒的多数のエンジニアが導入を開始。 2025年後半〜2026年： 導入が一段落し、ほぼ全てのエンジニアが当たり前に利用しているフェーズに移行。 2.使っている具体的なツール 圧倒的シェア: Claude Code 併用・特定用途: Cursor, Codex, GitHub Copilot, Devin, Gemini など 結果としては単なる「コードの補完」ではなく、Claude Code や Code x、Devin のような「自律的にタスクを完了させるエージェント型」が主流であることが顕著に現れていました。 3.Ruby開発における成功体験・お困りごと ☀️ ポジティブ（成功体験）※一部抜粋 開発スピードの向上: 「実装が早くなった」「コードを書く時間が減った」「爆速」「PR（プルリクエスト）出すまでが早い」といった声が目立ちました。 学習・調査の効率化: 「知らない構文やライブラリをすぐ聞ける」「エラー解消が早い」「Rubyの古いバージョンからの移行に役立った」 テスト・ドキュメント: 「テストコードを書いてくれる」「仕様の言語化が楽になった」 精神的負担の軽減: 「一人で悩む時間が減った」「心理的ハードルが下がった」 ☔️ ネガティブ（お困りごと） ※一部抜粋 精度の問題: 「嘘をつく（ハルシネーション）」「動かないコードが出てくる」「古い情報を出してくる」 レビュー・品質への懸念: 「レビューが大変になった」「AIが書いたコードの意図を追うのが苦労する」「コピペによる技術的負債への不安」 特有の悩み: 「トークン代が高い」「追いつくのが大変」「AIのスピードに人間がついていけない」 ブース企画その2_アンケート or XフォローでノベルティGET🎁 弊社の認知度をはじめとした簡単なアンケートへの回答またはXフォローでガラポンチャレンジをしてノベルティをプレゼントしていました✨ どちらもご協力いただいた方は2回引いていただきました💪 防災7点セットをはじめ絆創膏やポーチなどを用意しました🎁 多くの方にお越しいただき、賑わいを見せた弊社ブースの様子👀✨わいわい。 弊社役員のオフショット📸 Matzさんにお越しいただき記念撮影✨ ありがとうございました！ エンジニアによるセッションレポート エンジニアによるセッションの感想を一部紹介します！ Ruby Committers and the World Ruby Committers and the World RubyKaigi 2026, #rubykaigi rubykaigi.org Rubyの開発体制について。Matzさんがいなくなった場合を考えて、pythonのような合議制への移行などを検討すべきかが話された。Matzさんは大人数での合議制には否定的で、一部の意見によって言語設計が揺らぎやくなる懸念があると話していた。少人数での合議制か、AIでメカMatzを作るべきという意見があった。 RubyコミッターのAI活用について。コミッターも半分以上をAIに実装されている人が多い。Matzさんも一年以上自分でコードを書いていない、エディタも開発目的では使っていない（メールでもemacsを使っている）。CRubyは以前からMatzさんは実装から離れて他のコミッターに任せていた。同レベルのことをAIエージェントに任せてもアウトプットレベルはそんなに変わらないらしい。（言う事を効かないことがあるコミッターたちよりもAIエージェントを使ったほうが良いとのこと） HTML-Aware ERB: The Path to Reactive Rendering HTML-Aware ERB: The Path to Reactive Rendering RubyKaigi 2026, #rubykaigi rubykaigi.org この発表は、ERBを単なる文字列生成の仕組みとしてではなく、HTML構造を理解できるテンプレートとして扱うことで、RailsのView層をより進化させようという内容でした。HerbはHTML+ERBを解析するための文法とパーサを提供し、Prismと組み合わせることで、Ruby構文やHTMLの不整合を実行前に検出できるようにします。普段Reactを書いている立場から見ると、JSXをツールが構造として理解できることがReactの開発体験を支えているように、HerbはERBにもそれに近い土台を作ろうとしているように感じました。Hotwireで進んできたHTML中心のRails開発を、テンプレート解析やエディタ支援の面からさらに押し進める取り組みに見えます。特に面白いのは、将来的に「どの状態がどのDOMに影響するか」を追跡し、必要な部分だけを更新するリアクティブな仕組みにつながる可能性がある点です。ただし、React的なリアクティビティがすぐそのまま実現するわけではなく、現時点ではそのための基盤づくりという位置づけに近そうです。サーバーサイドレンダリングを中心にしながら、必要なところだけ賢く更新できる方向性はとても魅力的です。ERBが構造を理解できる開発しやすいUI記述として進化していくなら、小規模なアプリや管理画面では、Reactを持ち込まずにこの方向性を選ぶ場面も増えていくかもしれません。 ERBの問題（HTMLの構造に問題があっても何も検出しない）とそれを解決するためにherbが生み出され、herbに何ができるか？といった話。herb-toolsでHTMLをパースしたり、dev serverでホットリロードできたりするの知らなかったので勉強になりました。 Matz Keynote Matz Keynote RubyKaigi 2026, #rubykaigi rubykaigi.org Rubyのソースコードをコンパイルして、実行ファイルを生成する取り組み。CRubyに比べて大幅な性能向上を実現していた（YJITとは別のアプローチ）。全てのRubyの機能が利用できるわけでなく、Ruby on Railsの置き換えは現時点で原理的に不可とのこと。CLIツールなどの一部のユースケースでは利用できる仕組みかもしれないと感じた。 弊社スポンサーセッション 最終日にはスポンサーセッションとして、弊社の宍戸（執行役員 医療プラットフォーム本部 CTO）がトークしました。 ご聴講いただいた皆さま、ありがとうございました！ 公立はこだて未来大学学生への支援活動 事前告知ブログにも記載していますが、弊社の新卒採用において開催地（函館）は深い繋がりがあり、 社内にははこだて未来大学のOB・OGが複数名在籍し、第一線で活躍しています✨ RubyKaigi 2026 にRubyスポンサーとして協賛します！ | MEDLEY Developer Portal はじめに こんにちは！メドレーDevRelの重田（@Shige0096）です。 今年もついに、Rubyistたちの祭典 RubyKaigi 2026 の季節がやってまいりました！ 昨年の最終日に「次は函館！」と発表されてから、日本三大夜景と... developer.medley.jp そこで今回は、RubyKaigi への参加費用の支援と弊社社員との懇親会への招待を行いました。 ご参加いただいた皆様、ありがとうございました！ 短い時間でしたが、弊社一同楽しい時間を過ごすことができました！少しでもメドレーについて知っていただき、興味を持っていただけていたら幸いです！ おまけ RubyKaigiへの参加を通して、北海道の魅力にもたくさん触れることができました。 美味しい水と空気がある場所はご飯がとにかく美味しい！！そして自然も感じられた3日間でした🌱 思い出の写真をいくつかご紹介します🙋‍♀️ 2日目の夜に希望メンバーで、日本三大夜景でもある函館山からの夜景を見に行きました⛰️ 新鮮度がまるで違う北海道の海鮮！ 活きたまま水揚げ・輸送され、直前まで生きていたイカ（=活イカ）をいただきました🦑味はもちろん、コリコリした食感が最高でした👏 帰りのタクシーで運転手さんにオススメしていただいたソフトクリーム🍦 北海道最古の珈琲店「カフェ美鈴」で食べられます☕️疲れた体に沁みる甘さでした🙏 おわりに 改めて、RubyKaigi にて弊社ブースにお越しいただいた皆様、はこだて未来大学の皆様、そして運営の皆様、ありがとうございました！！！ 全国のRubyistの皆さんと交流ができたことを弊社一同嬉しく思います！ 今後もRubyコミュニティへ少しでも貢献できたらと考えていますので、引き続きよろしくお願いいたします。 それでは、来年は宮崎でお会いしましょう！！（頑張って申し込むぞ💪🔥） メドレーでは、Rubyが大好きなエンジニアを募集しています！（もちろんそれ以外のエンジニア職種も大歓迎・大募集中です！） まずはカジュアル面談でざっくばらんにお話しできるので、会場でお会いできない方はぜひこちらでお話ししましょう！お待ちしております！ 株式会社メドレー 正社員 エンジニア の求人一覧 株式会社メドレー 正社員 エンジニア の求人一覧です。| HRMOS hrmos.co

こんにちは！メドレーDevRelの重田（ @Shige0096 ）です。 4/22(水)-24(金) に函館で開催されたRubyKaigi に今年も参加してきたので、その参加レポートをお送りします👟 はじめに 株式会社メドレーはRubyスポンサーとして協賛し、現地でブース出展しました。 弊社のプロダクトの半数以上でRubyを用いていることもあり、 Rubyコミュニティへの貢献は、協賛活動の中でも特に重要視している活動です！ １番最初にロゴを掲載していただきました🙌 弊社VPoEの倉林（ @terukura ）が書き込み中✍️ 今年は役員を含め総勢13名で参加し、RubyKaigi を堪能しました✨ 本レポートでは、現地の様子や弊社のブース企画のご紹介を写真メインで雰囲気が伝わるようお伝えします！ ぜひ楽しんでご覧いただけると嬉しいです🙌 会場の様子 本年の開催場所は「函館」。（昨年の発表から心待ちにしていました!!!） 採用人事の福島さんとともに前日入りし、ブース設営⚒️ ブースの完成形。Rubyスポンサーは長机2つなので広々としていました🚩 上から見た会場。 弊社ブースのご紹介 ブース企画その１_Ruby×AIアンケート調査 以下3つのAIに関するアンケートをとりました！🔍 ご回答いただいた皆様、ご協力ありがとうございました！！ AI（生成AIなど）を開発に取り入れ始めたのはいつ頃ですか？ 使っている具体的なルールを教えて下さい AIを活用したRuby開発における成功体験やお困りごとを教えて下さい アンケート結果サマリ✍️ 1.AIを開発に取り入れ始めた時期 2024年前半： 早期導入層が一定数存在し、この時期から活用が始まる。 2024年後半〜2025年前半： ボリュームゾーン です。この期間に圧倒的多数のエンジニアが導入を開始。 2025年後半〜2026年： 導入が一段落し、ほぼ全てのエンジニアが当たり前に利用しているフェーズに移行。 2.使っている具体的なツール 圧倒的シェア: Claude Code 併用・特定用途: Cursor, Codex, GitHub Copilot, Devin, Gemini など 結果としては単なる「コードの補完」ではなく、Claude Code や Code x、Devin のような「自律的にタスクを完了させるエージェント型」が主流であることが顕著に現れていました。 3.Ruby開発における成功体験・お困りごと ☀️ ポジティブ（成功体験）※一部抜粋 開発スピードの向上: 「実装が早くなった」「コードを書く時間が減った」「爆速」「PR（プルリクエスト）出すまでが早い」といった声が目立ちました。 学習・調査の効率化: 「知らない構文やライブラリをすぐ聞ける」「エラー解消が早い」「Rubyの古いバージョンからの移行に役立った」 テスト・ドキュメント: 「テストコードを書いてくれる」「仕様の言語化が楽になった」 精神的負担の軽減: 「一人で悩む時間が減った」「心理的ハードルが下がった」 ☔️ ネガティブ（お困りごと） ※一部抜粋 精度の問題: 「嘘をつく（ハルシネーション）」「動かないコードが出てくる」「古い情報を出してくる」 レビュー・品質への懸念: 「レビューが大変になった」「AIが書いたコードの意図を追うのが苦労する」「コピペによる技術的負債への不安」 特有の悩み: 「トークン代が高い」「追いつくのが大変」「AIのスピードに人間がついていけない」 ブース企画その2_アンケート or XフォローでノベルティGET🎁 弊社の認知度をはじめとした簡単なアンケートへの回答またはXフォローでガラポンチャレンジをしてノベルティをプレゼントしていました✨ どちらもご協力いただいた方は2回引いていただきました💪 防災7点セットをはじめ絆創膏やポーチなどを用意しました🎁 多くの方にお越しいただき、賑わいを見せた弊社ブースの様子👀✨わいわい。 弊社役員のオフショット📸 Matzさんにお越しいただき記念撮影✨ ありがとうございました！ エンジニアによるセッションレポート エンジニアによるセッションの感想を一部紹介します！ Ruby Committers and the World Ruby Committers and the World RubyKaigi 2026, #rubykaigi rubykaigi.org Rubyの開発体制について。Matzさんがいなくなった場合を考えて、pythonのような合議制への移行などを検討すべきかが話された。Matzさんは大人数での合議制には否定的で、一部の意見によって言語設計が揺らぎやくなる懸念があると話していた。少人数での合議制か、AIでメカMatzを作るべきという意見があった。 RubyコミッターのAI活用について。コミッターも半分以上をAIに実装されている人が多い。Matzさんも一年以上自分でコードを書いていない、エディタも開発目的では使っていない（メールでもemacsを使っている）。CRubyは以前からMatzさんは実装から離れて他のコミッターに任せていた。同レベルのことをAIエージェントに任せてもアウトプットレベルはそんなに変わらないらしい。（言う事を効かないことがあるコミッターたちよりもAIエージェントを使ったほうが良いとのこと） HTML-Aware ERB: The Path to Reactive Rendering HTML-Aware ERB: The Path to Reactive Rendering RubyKaigi 2026, #rubykaigi rubykaigi.org この発表は、ERBを単なる文字列生成の仕組みとしてではなく、HTML構造を理解できるテンプレートとして扱うことで、RailsのView層をより進化させようという内容でした。HerbはHTML+ERBを解析するための文法とパーサを提供し、Prismと組み合わせることで、Ruby構文やHTMLの不整合を実行前に検出できるようにします。普段Reactを書いている立場から見ると、JSXをツールが構造として理解できることがReactの開発体験を支えているように、HerbはERBにもそれに近い土台を作ろうとしているように感じました。Hotwireで進んできたHTML中心のRails開発を、テンプレート解析やエディタ支援の面からさらに押し進める取り組みに見えます。特に面白いのは、将来的に「どの状態がどのDOMに影響するか」を追跡し、必要な部分だけを更新するリアクティブな仕組みにつながる可能性がある点です。ただし、React的なリアクティビティがすぐそのまま実現するわけではなく、現時点ではそのための基盤づくりという位置づけに近そうです。サーバーサイドレンダリングを中心にしながら、必要なところだけ賢く更新できる方向性はとても魅力的です。ERBが構造を理解できる開発しやすいUI記述として進化していくなら、小規模なアプリや管理画面では、Reactを持ち込まずにこの方向性を選ぶ場面も増えていくかもしれません。 ERBの問題（HTMLの構造に問題があっても何も検出しない）とそれを解決するためにherbが生み出され、herbに何ができるか？といった話。herb-toolsでHTMLをパースしたり、dev serverでホットリロードできたりするの知らなかったので勉強になりました。 Matz Keynote Matz Keynote RubyKaigi 2026, #rubykaigi rubykaigi.org Rubyのソースコードをコンパイルして、実行ファイルを生成する取り組み。CRubyに比べて大幅な性能向上を実現していた（YJITとは別のアプローチ）。全てのRubyの機能が利用できるわけでなく、Ruby on Railsの置き換えは現時点で原理的に不可とのこと。CLIツールなどの一部のユースケースでは利用できる仕組みかもしれないと感じた。 弊社スポンサーセッション 最終日にはスポンサーセッションとして、弊社の宍戸（執行役員 医療プラットフォーム本部 CTO）がトークしました。 ご聴講いただいた皆さま、ありがとうございました！ 公立はこだて未来大学学生への支援活動 事前告知ブログにも記載していますが、弊社の新卒採用において開催地（函館）は深い繋がりがあり、 社内にははこだて未来大学のOB・OGが複数名在籍し、第一線で活躍しています✨ RubyKaigi 2026 にRubyスポンサーとして協賛します！ | MEDLEY Developer Portal はじめに こんにちは！メドレーDevRelの重田（@Shige0096）です。 今年もついに、Rubyistたちの祭典 RubyKaigi 2026 の季節がやってまいりました！ 昨年の最終日に「次は函館！」と発表されてから、日本三大夜景と... developer.medley.jp そこで今回は、RubyKaigi への参加費用の支援と弊社社員との懇親会への招待を行いました。 ご参加いただいた皆様、ありがとうございました！ 短い時間でしたが、弊社一同楽しい時間を過ごすことができました！少しでもメドレーについて知っていただき、興味を持っていただけていたら幸いです！ おまけ RubyKaigiへの参加を通して、北海道の魅力にもたくさん触れることができました。 美味しい水と空気がある場所はご飯がとにかく美味しい！！そして自然も感じられた3日間でした🌱 思い出の写真をいくつかご紹介します🙋‍♀️ 2日目の夜に希望メンバーで、日本三大夜景でもある函館山からの夜景を見に行きました⛰️ 新鮮度がまるで違う北海道の海鮮！ 活きたまま水揚げ・輸送され、直前まで生きていたイカ（=活イカ）をいただきました🦑味はもちろん、コリコリした食感が最高でした👏 帰りのタクシーで運転手さんにオススメしていただいたソフトクリーム🍦 北海道最古の珈琲店「カフェ美鈴」で食べられます☕️疲れた体に沁みる甘さでした🙏 おわりに 改めて、RubyKaigi にて弊社ブースにお越しいただいた皆様、はこだて未来大学の皆様、そして運営の皆様、ありがとうございました！！！ 全国のRubyistの皆さんと交流ができたことを弊社一同嬉しく思います！ 今後もRubyコミュニティへ少しでも貢献できたらと考えていますので、引き続きよろしくお願いいたします。 それでは、来年は宮崎でお会いしましょう！！（頑張って申し込むぞ💪🔥） メドレーでは、Rubyが大好きなエンジニアを募集しています！（もちろんそれ以外のエンジニア職種も大歓迎・大募集中です！） まずはカジュアル面談でざっくばらんにお話しできるので、会場でお会いできない方はぜひこちらでお話ししましょう！お待ちしております！ 株式会社メドレー 正社員 エンジニア の求人一覧 株式会社メドレー 正社員 エンジニア の求人一覧です。| HRMOS hrmos.co

はじめに こんにちは。医療プラットフォーム本部ビジネス基盤グループでエンジニアをしている熊本です。 ブログへの登場は久々となりますが、2019年に新卒で入社して以来、長らくプロダクト開発のエンジニアをしてきました。そんな私は現在、医療プラットフォーム全体のMA（マーケティングオートメーション）、SFA（営業支援）、CRM（顧客管理）といったITツールおよび業務フローの設計・改善を通じて、事業パフォーマンスの向上を担う開発組織のマネージャーを務めています。 メドレーでは、患者・生活者と、病院・有床診療所、医科診療所、歯科診療所、調剤薬局といった各医療機関向けに事業・プロダクトを展開していますが、今回は、これらの事業を支えるITツールの Salesforce を kintone へ移行したプロジェクトについてお話しします。 背景 SFAが抱えていた課題 弊社では長年、医療プラットフォームにおける複数の事業部門で共通のSalesforceを利用してきましたが、運用を続ける中で以下のような課題が顕在化していました。 最新・正しい情報の把握が困難 ：正規化されていないデータや重複管理による情報の分散 データ分析の壁 ：分析を見据えた設計になっておらず、プロダクト側の利用状況との突合など、柔軟なデータの加工に工数がかかっていた 非効率な業務フロー ：複数ツールの併用や重複する項目の存在などを背景に、手動での転記やダブルチェックが発生している状態 システム管理の属人化 ：目的が不明な項目が乱立し、メンテナンス・レポート作成ができる人が限られている状態 また、130個近くのライセンスを保有していたため、これらの課題を踏まえるとコスト過多な状況にも陥っていました。 全ての顧客体験をプロダクト側が理解し、設計責任を持つ 私たちは、 営業・カスタマーサクセスといった顧客活動から、契約・請求に至るまでを「一連のプロダクト体験」として捉え 、その設計・実装にエンジニアが深く関わることを大切にしています。 この考えに基づき、単なるツールのリプレイス（お引っ越し）ではなく、より良い顧客体験につながる合理的で整理された事業オペレーションを実現するため、 業務・データ・ツールを一体でエンジニアが設計し直す 。これが本プロジェクトの重要なポイントでした。 取り組み 体制構築とアーキテクチャ設計 前述の通り、Salesforceはこれまで複数の事業部門で活用してきました。1人で各事業の業務フローや必要データを把握し再設計するのは困難ですし、何より私たちが大切にしている考え方も踏まえ、プロダクトエンジニアが各事業に深く潜り込んで再設計すべきだと考えました。そこで、各事業領域からプロダクトエンジニアを1名ずつアサインする体制としました。私はPMとして全体設計や車輪の再発明が起きないよう各部門の連携をコントロールする役割を担い、各環境のデータ設計・構築はその事業領域担当のエンジニアが主導する形をとりました。 kintoneは責務分離やメンテナビリティを考慮し、事業領域ごとに環境を分けるアーキテクチャを採用しました。また、kintoneへの移行に伴い、コストや親和性を加味してMAツールの移行も行いましたが、本記事では詳細を割愛させていただきます。 医療プラットフォーム本部の組織体制 ツールの移行イメージ 業務理解と要件定義 まずは、日々の事業活動の中で発生するデータや、業務上必要となるデータ、およびそのフローの現状とあるべき姿を描くため、事業部とコミュニケーションを重ねました。長年利用してきたこともありデータ項目が膨大となっていたため、「このデータをどう活用するのか」を重点的に会話し、そもそも不要ではないか、より活用しやすくするにはどうすべきか、などの整理に時間をかけました。 データ設計 特に工夫したのは、DB観点での「正規化」とユーザー観点での「入力のしやすさ」のバランスをとったデータ設計です。kintoneはDBとUIが一体型であるため、このバランス調整にとても苦労しました。一般的なRDBMSではデータの履歴を残すために専用のテーブルを設けイミュータブルモデリングなどを採用する場面でも、kintoneだとテーブル≒アプリとなるため、テーブルを分けることは単純にユーザーの画面遷移や入力箇所を増やすことに直結してしまいます。こういった場合は完全な正規化をするのではなく、普段の商談管理で使用するアプリとその商談ステータスの履歴を管理するアプリを分け、それぞれのアプリに同類のフィールド（RDBMSのカラムをkintoneではフィールドと呼びます）を設置することを許容しつつも、JavaScriptを用いた自動転記の仕組みを作ることで、ユーザーは商談管理アプリだけに入力していれば良いようにするといった工夫をしました。 泥臭く戦ったポイント：データ移行と同期システム ここからは、エンジニアとして特に苦労した2つのポイントをご紹介します。 1. 冪等性と再現性を追求したデータ移行 100名以上が利用するシステムにおいて、特にデータ移行には慎重を期しました。具体的な方法としては、Salesforceのスキーマをkintoneのスキーマに変換し、データをマッピングした結果をCSVに出力するという一連の処理を、CLIコマンド等の整備によりスクリプト化しました。 データ移行では、一度kintoneに投入した後、UAT期間中に事業部からのフィードバックを受けて設計を見直し、再投入が必要になるケースがありました。また、リハーサル目的で、本番移行前にも何度でも再実行できる仕組みが必要でした。そのため、前述のように一連の処理をスクリプト化し、「再現性」を確保しました。さらに、「冪等性」も重要なポイントでした。今回のケースでは、それぞれのアプリにユニークキーを設けて常にUPSERT処理を行うことで、元データが同じであれば、何度実行しても同じ状態を再現できるようにしました。 kintoneへのインポート処理自体はレコード数に比例して一定の時間がかかってしまうものの、事前に手順化しリハーサルを重ねたことで、本番稼働前日の夜間作業で無事に移行を完了させることができました。ただし、（一定の想定範囲ではあったものの）移行作業直前にSalesforce側でデータの更新や削除が行われたことで、kintone側で関連データ同士の紐付けがうまく設定できないケースも発生しました。これはエラーログを見て個別に対処するしかなく、大変苦労した部分でもありました。 2. Salesforceとkintoneの双方向同期システム Salesforceは長年活用してきたことから、いわゆるSFAとしての機能だけではなく、請求や契約管理としての役割も担っていました。今回のプロジェクトでは事業部側が利用するSFAとしての機能はkintoneへ移行しつつも、請求や契約管理といったバックオフィス領域に関しては将来的な販売管理システムへの移行も見据えてスコープ外としていました。よって、これまでは一つのシステムの中で顧客・商談から契約・請求まで一元管理していたものを分離したため、システム間でデータを連携させる必要がありました。 詳細は省きますが、Salesforceに残った契約・請求関連データの一部は、営業やカスタマーサクセスなどの事業部側と契約・請求処理を担うバックオフィス部門の双方向による書き込みが業務上必要であったため、単にkintoneから必要なデータを一方向で送るだけでは要件を満たせませんでした。そのため、SFA領域とバックオフィス領域のハブとなる「商談」などのデータに関しては、Salesforceとkintone間で一部のスキーマ定義を揃え、両システムを一定間隔で同期させる仕組みとしました。 具体的な仕組みとしては、両システムのスナップショットを一定間隔で取得し、前回との差分を検知して互いのシステムへ反映し合う形をとりました。 ここで壁となったのが、「準リアルタイム性」の要求と「データの競合」です。両方のシステムで日常的にトランザクションが発生するため、「同じレコードの同じ項目が、それぞれのシステムで同時に別の値へ書き換えられる」可能性がありました。この競合状態を安全に解決するためのロジックを構築する必要があり、非常に苦労しました。 この対応にあたっては、当初想定していた対象項目が、本当に準リアルタイムで同期が必要なのかを関係者と徹底的に精査しました。その結果、同期間隔の調整や同期対象の大幅な絞り込みができ、現在は安定して稼働する仕組みを実現できています。 ※ データ移行や同期処理のディープな話は盛りだくさんな内容となってしまうため、また別の機会にブログ化できればと思います！ 成果 80%以上のランニングコスト削減 契約・請求などを担う組織の必要分を除き、90個ほどのアカウントを削除することができました。kintoneの費用を加味しても、全体のランニングコストとして80%以上削減することができました。 BigQuery集約によるデータ分析・可視化の実現 Salesforceのレポート機能の制約から解放され、より柔軟なデータ活用ができるようになりました。 KPIダッシュボードの構築 ：Looker Studioなどのアセットと連携したデータの分析・可視化が可能に 自律的な分析文化 ：勉強会の開催やマニュアル整備のおかげもあり、事業部メンバーが生成AIも活用しながら、より自律的かつスピーディなデータ分析が可能に 横断的分析 ：kintoneの顧客・商談データ、契約データ、プロダクトデータなどをBigQueryに集約し、多角的な分析を実現 また、横断組織にあるデータ戦略グループが、最近「自然言語でBigQuery等のデータを分析できる社内システム」をリリースしました。今回のプロジェクトによるデータ整備とこのシステムが組み合わさり、よりスピーディにデータ分析を行える環境づくりが加速しています。 関連記事： データ分析AIエージェントの実践 - Slack × Devin × Context Engineering 今後の展望 本プロジェクトによって多くの成果を得られましたが、私たちはまだ「業務やデータの一部をツールの移行と共に再設計し、基盤を整えた」に過ぎません。 今後はこの基盤を活かし、KPIなどの定量的なデータや現場ヒアリングを通じて事業の課題・ボトルネックを特定し、継続的に改善を回すサイクルを作っていきたいと考えています。 また、日々顧客と向き合う事業部のメンバー自身が、データ活用や拡張性を見据えて自律的にツールを改修できる状態こそが、組織のアジリティを最も高く保ちながらスケールできる理想の形だと考えています。その実現に向けて、エンジニアリングの専門性を持つ私たちビジネス基盤グループが、誰もが改修・改善しやすい仕組みづくりを牽引していきたいと考えています。 まとめ エンジニアが事業の深い部分に入り込み、業務・データ・ツールを一体で再設計するプロジェクトについてご紹介させていただきました。 メドレーでは、「医療ヘルスケアの未来をつくる」というミッションのもと、エンジニアがビジネスの根幹に関わり、プロダクトと事業を共に成長させる文化があります。自ら課題を発見し、設計から運用までをエンジニアとしてのリーダーシップを発揮しながら一気通貫で推進できる方を絶賛募集しています。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp 少しでも興味を持っていただけましたら、ぜひメドレーの採用ページをご覧ください！

はじめに こんにちは。人材プラットフォーム ジョブメドレーアカデミー開発グループの池田です。ジョブメドレーアカデミーは、介護や障がい福祉、在宅医療などの各業種に特化した「オンライン動画研修サービス」と「勤怠・シフト管理サービス」をWeb・アプリの両方で提供しています。開発グループでは、これら両サービスの開発・運用を担当しています。 これまで、オンライン動画研修サービスのWebフロントエンドは Next.js で構築されていましたが、長期的な運用を見据えて Vite + TanStack Router への移行を行いました。本記事では、移行に至った理由と移行作業を紹介します。 移行理由について Next.jsからViteへの移行を決定した背景は、以下の3つの理由が同時期に重なったことです。 依存関係による開発の制約 当初、デザインシステムの構築を見据え、Tailwind CSSやPanda CSSといったモダンなCSSライブラリの導入を検討していました。 しかし、当時使用していたNext.js v12が内部で保持するPostCSSのバージョンが古いために設定が競合し、導入には複雑な設定が必要であることが判明しました。また、v12自体がすでにサポート終了（EOL）を迎えており、セキュリティやメンテナンスの面でも使い続けるリスクが高まっていたため、バージョンアップまたは別構成への移行が必要な状況にありました。 デプロイツール「serverless-nextjs」のアーカイブ インフラ構築には serverless-nextjs を使用していました。しかし、同ライブラリは現在アーカイブ（開発停止）されています。将来的なバグ修正などが困難になるため、配信基盤構築の手段を別の選択肢へ置き換える必要が生じていました。 プロダクト特性に合わせた技術スタックの見直し Next.js採用時と現在ではフロントエンドのエコシステムが異なり、現在は多様な選択が可能になったと思います。そこで、改めてプロダクト特性などを踏まえて検討した結果、以下の観点からよりシンプルな構成が最適であると判断しました。 to Bサービスであり、ユーザー体験を優先する性質上、SEO観点での数値最適化(Core Web Vitals等)の必要性が比較的低い バックエンドにGraphQLを採用しており、SSRを活用しようとするとキャッシュ管理等の設計が必要であり、実装コストがかかる 検索やページネーション等のユーザー操作に伴う動的データが画面の大半を占めており、RSCを使用する恩恵を十分に享受できない 以上の理由から、Next.js の使用を継続するよりも、今のサービス特性に合わせた構成にするのが適していると考え、バージョンアップではなく Vite + TanStack Router へのリプレイスを決断しました。 移行作業について ここからは、具体的な移行作業について紹介します。多岐にわたる作業の中から、本記事では特に大きな変更点である「ルーティング」と「インフラ」の2点を取り上げます。 TanStack Routerへの移行 next/router と next/link を使用していたルーティングは、 TanStack Router へ移行しました。採用理由は、次の3点です。 パスやクエリパラメータを型安全に扱い、それに関する実装ミスをコンパイル時に検知したいため 勤怠・シフト管理サービスと技術スタックを揃え、グループ内での知見共有をスムーズにしたいため Next.js使用時と同じようにファイルベースルーティングを維持し、移行に伴う認知負荷を最小限に抑えるため 結果、クエリパラメータが型で管理されるようになったことで、これまで手動テストやE2Eテストでしか気付けなかったような不具合を、コードを書いている段階で（型エラーとして）検知できるようになりました。 加えて、どの画面でどのパラメータが使われているかが型から追いやすくなり、長期的な保守性の向上にもつながっています。 CloudFront Continuous Deployment の活用 Viteアプリケーションを配信するために、serverless-nextjs で構築されたCloudFront + S3 + Lambda@Edgeの構成から、CloudFront + S3の構成に移行することを行いました。 インフラ構成を簡素化できる一方で、大規模な刷新となるため、リリースにあたっては以下の要件を重視しました。 万が一の際に、即座に旧構成（Next.js）へロールバックできること ダウンタイムをゼロにすること(本番環境での正常動作を保証すること) まず、これまで serverless-nextjs が構築していたリソース（CloudFront・Lambda@Edge）をTerraformで再定義しました。ライブラリ任せだったインフラ構成が可視化されたことに加え、旧構成に切り戻せる体制も整えることができました。 一方、ダウンタイムなしの切り替えを実現するために、CloudFront Continuous Deployment を活用しました。 出典 : CloudFront の継続的デプロイを使用して CDN 設定の変更を安全にテストする - Amazon CloudFront （Amazon Web Services, Inc.） 具体的には、既存の Next.js 配信用の設定をPrimary distribution(画像参照)におき、新しく構築したViteアプリケーション配信用の設定をStaging distributionとして用意しました。 CloudFront Continuous Deploymentでは、リクエストヘッダーまたはトラフィックレートに基づいてリクエストを振り分けることができます。今回は特定のヘッダーを付与した場合のみ Staging distribution へリクエストが流れるよう設定し、本番ドメインかつ本番環境と同じ条件下でViteアプリケーションの検証を行いました。 検証の結果、問題がないことを確認した上で、Staging distributionの設定を Primary distributionへ上書き(昇格)させました。このプロセスにより、ダウンタイムを発生させることなく、安全に新環境への切り替えを完了できました。 おわりに 今回は、ジョブメドレーアカデミーが提供するオンライン動画研修サービスのWebフロントエンドを Next.js から Vite + TanStack Router へ移行した取り組みを紹介しました。移行理由として挙げていた、プロダクト特性に合った技術スタックの見直しの達成に加え、他2点の課題も以下のように解決されました。 課題 移行後 依存関係による制約 Vite への移行により、PostCSS起因の競合が消え、Panda CSS などのライブラリが容易に導入可能になった。 デプロイツールの アーカイブ Terraform による IaC 管理に移行し、ライブラリに依存していたインフラ構成が可視化され、メンテナンスが容易になった。 また、上記の内容に加え、ビルド速度や画面遷移速度の向上といった改善も見られました。 プロダクトを長期的に提供できるよう、今後も機能開発と並行して技術基盤の見直しや改善に継続的に取り組んでいきます。 We’re hiring! メドレーでは、プロダクトエンジニアをはじめ「医療ヘルスケアの未来」を共に創っていくエンジニアを大募集中です！少しでもご興味をお持ちいただけましたらぜひ、ご応募お待ちしております！ 株式会社メドレー エンジニア の求人一覧 株式会社メドレー エンジニア の求人一覧です。| HRMOS hrmos.co ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

はじめに こんにちは！メドレーDevRelの重田（ @Shige0096 ）です。 今年もついに、Rubyistたちの祭典 RubyKaigi 2026 の季節がやってまいりました！ 昨年の最終日に「次は函館！」と発表されてから、日本三大夜景と美味しい海鮮と日本酒とビールと、、、ではなく、Rubyistの皆さんと函館でお会いできることを、心待ちにしていました🙌 メドレーは今年も、Rubyコミュニティへの感謝と発展を願い、スポンサーとして現地参加します！ RubyKaigi 2025 入り口での一枚 レポートも公開しているので、ぜひご覧いただけると嬉しいです！ RubyKaigi 2025 参加レポート - Platinum Sponsor として協賛しました！ | MEDLEY Developer Portal はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 1... developer.medley.jp Rubyスポンサーとして協賛します！ 本年はRubyスポンサーとして、ブース出展とスポンサーセッションを通じてRubyKaigi を盛り上げます。 Sponsors RubyKaigi 2026, #rubykaigi rubykaigi.org スポンサーセッション:医療プラットフォーム本部 CTOの宍戸が登壇 執行役員 医療プラットフォーム本部CTOの宍戸が、スポンサーセッションに登壇いたします。 弊社の今とこれからについて、メドレーに入社したくなるような魅力をたっぷりお伝えしますのでぜひご聴講ください！ ブースコンテンツ:AI時代のRubyについて語りましょう（予定） メドレーのブースでは、皆さんと「これからのRuby」について考えるコンテンツとして 「AIを活用したRuby開発における成功体験・お困りごと」などを調査します。 ぜひ皆様のご意見や想いをお聞かせください！ また、簡単なアンケートにご回答いただいた方には、 メドレーオリジナルのノベルティ &弊社のAI活用に関する限定公開資料をプレゼントします！ はこだて未来大学の学生を対象に「学生支援」を実施します！ 実は、メドレーと開催地の函館には深い繋がりがあります。 弊社では毎年、開発職の新卒採用を積極的に行っていますが、実は公立はこだて未来大学のOB・OGが複数名在籍し、第一線で活躍しているのです✨ そんなご縁もあり、はこだて未来大学の学生さんを応援すべく、以下の支援を実施することにいたしました。 チケット支援: 5名の学生さんを対象にチケット代をサポート。 交流会: カンファレンス2日目に、弊社社員（OB/OG含む）との懇親会にご招待。 ※本企画は、対象大学の学生さんへ弊社OB・OGから直接ご連絡させていただく形式をとっております。 おわりに RubyKaigiは、単なる技術カンファレンスではなく、私たちが日々恩恵を受けているRubyという言語の未来が形作られる場所です。 函館の地で、全国のRubyistの皆さんと議論し、交流できることをメドレーチーム一同楽しみにしています。当日ブースで見かけたら、ぜひ「ブログ見ました！」と声をかけていただけると嬉しいです！ それでは、函館でお会いしましょう！ また、メドレーでは、Rubyが大好きなエンジニアを募集しています！（もちろんそれ以外のエンジニア職種も大歓迎・大募集中です！） まずはカジュアル面談でざっくばらんにお話しできるので、会場でお会いできない方はぜひこちらでお話ししましょう！お待ちしております！ 株式会社メドレー 正社員 エンジニア の求人一覧 株式会社メドレー 正社員 エンジニア の求人一覧です。| HRMOS hrmos.co

はじめに こんにちは！メドレーDevRelの重田（ @Shige0096 ）です。 今年もついに、Rubyistたちの祭典 RubyKaigi 2026 の季節がやってまいりました！ 昨年の最終日に「次は函館！」と発表されてから、日本三大夜景と美味しい海鮮と日本酒とビールと、、、ではなく、Rubyistの皆さんと函館でお会いできることを、心待ちにしていました🙌 メドレーは今年も、Rubyコミュニティへの感謝と発展を願い、スポンサーとして現地参加します！ RubyKaigi 2025 入り口での一枚 レポートも公開しているので、ぜひご覧いただけると嬉しいです！ RubyKaigi 2025 参加レポート - Platinum Sponsor として協賛しました！ | MEDLEY Developer Portal はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 1... developer.medley.jp Rubyスポンサーとして協賛します！ 本年はRubyスポンサーとして、ブース出展とスポンサーセッションを通じてRubyKaigi を盛り上げます。 Sponsors RubyKaigi 2026, #rubykaigi rubykaigi.org スポンサーセッション:医療プラットフォーム本部 CTOの宍戸が登壇 執行役員 医療プラットフォーム本部CTOの宍戸が、スポンサーセッションに登壇いたします。 弊社の今とこれからについて、メドレーに入社したくなるような魅力をたっぷりお伝えしますのでぜひご聴講ください！ ブースコンテンツ:AI時代のRubyについて語りましょう（予定） メドレーのブースでは、皆さんと「これからのRuby」について考えるコンテンツとして 「AIを活用したRuby開発における成功体験・お困りごと」などを調査します。 ぜひ皆様のご意見や想いをお聞かせください！ また、簡単なアンケートにご回答いただいた方には、 メドレーオリジナルのノベルティ &弊社のAI活用に関する限定公開資料をプレゼントします！ はこだて未来大学の学生を対象に「学生支援」を実施します！ 実は、メドレーと開催地の函館には深い繋がりがあります。 弊社では毎年、開発職の新卒採用を積極的に行っていますが、実は公立はこだて未来大学のOB・OGが複数名在籍し、第一線で活躍しているのです✨ そんなご縁もあり、はこだて未来大学の学生さんを応援すべく、以下の支援を実施することにいたしました。 チケット支援: 5名の学生さんを対象にチケット代をサポート。 交流会: カンファレンス2日目に、弊社社員（OB/OG含む）との懇親会にご招待。 ※本企画は、対象大学の学生さんへ弊社OB・OGから直接ご連絡させていただく形式をとっております。 おわりに RubyKaigiは、単なる技術カンファレンスではなく、私たちが日々恩恵を受けているRubyという言語の未来が形作られる場所です。 函館の地で、全国のRubyistの皆さんと議論し、交流できることをメドレーチーム一同楽しみにしています。当日ブースで見かけたら、ぜひ「ブログ見ました！」と声をかけていただけると嬉しいです！ それでは、函館でお会いしましょう！ また、メドレーでは、Rubyが大好きなエンジニアを募集しています！（もちろんそれ以外のエンジニア職種も大歓迎・大募集中です！） まずはカジュアル面談でざっくばらんにお話しできるので、会場でお会いできない方はぜひこちらでお話ししましょう！お待ちしております！ 株式会社メドレー 正社員 エンジニア の求人一覧 株式会社メドレー 正社員 エンジニア の求人一覧です。| HRMOS hrmos.co

はじめに 医療プラットフォーム本部 プラットフォーム開発室 SREグループの吉田です。医療機関向けSaaSである CLINICS の安定稼働とシステム信頼性の向上に取り組んでいます。 CLINICSではメインDBとしてMongoDBを使用しており、以下の3つの目標を掲げて、DBM（Database Monitoring）を導入しました。 なおCLINICSでは監視・オブザーバビリティ基盤としてDatadogをすでに活用(*1)していたため、Datadog DBM（Database Monitoring）を採用しました。 クエリのパフォーマンス課題の早期検知 スロークエリの改善サイクルの向上（回数を増やす・サイクルを短くする） スロークエリのナレッジを蓄積 背景・課題 DBM導入前の運用 MongoDB AtlasからログをダウンロードしてCOLLSCANや実行時間を分析するスクリプトを運用していました。分析の粒度はコレクション名とFind/Commandの種別に加えて、クエリシグネチャ単位での詳細な分析も行っていました。この作業を週次で実施し、スロークエリを発見・改善するサイクルを回していました。 課題 先週比の悪化検知ができない：スクリプトによる分析はある時点のスナップショットにとどまるため、時系列での比較・悪化検知が困難だった 本番の実行計画を取得できない：Atlasのログには詳細な実行計画が含まれないため、クエリ改善に必要な情報が不十分だった スロークエリのナレッジが再利用しづらい：Google スプレッドシートにスロークエリの対応履歴を記録していたが、AI エージェントによる検索性に課題があり、過去の対応内容を参照しづらい状況だった 手動ログ取得に工数がかかる：MongoDB Atlas の本番 DB からログを手動でダウンロードする運用となっており、1週間分のログ取得に時間がかることから、毎週約1時間の作業工数が発生していた。 解決策の全体像 DBMの導入により、以下の方法でそれぞれの課題を解消しました。 先週比の悪化検知ができない：Datadog Dashboard を活用することで解消。週次での傾向比較やパフォーマンス悪化が検知可能に。 本番の実行計画を取得できない：DBMに内包されるクエリサンプリング機能により解消。実行計画（explain plan）をリアルタイムで取得・可視化できるため、クエリ改善に必要な情報を直接確認。 スロークエリに関するナレッジが再利用しづらい：対応方針や問題視した観点などをGitHub Issueに記録。 手動ログ取得による作業工数：Datadog DBM によりスロークエリの収集・分析が自動化されたため、この部分の工数がゼロに。 以下が、システム構成図です。 大きく3つのステップで構成されています。 Datadogダッシュボードの構築：DBMを用いてスロークエリ・COLLSCAN・クエリ効率を可視化 Goスクリプトによるデータ取得：ダッシュボードの内容をJSON形式で取得し、Claude Codeが対応優先度を判定 GitHub Issueの自動生成：優先度が高いクエリのみをIssue化し、対応漏れを防ぐ 実装の詳細 Datadogダッシュボードの構築 DBMを導入し、以下の3つの観点でダッシュボードを構築しました。 観点 検出条件 COLLSCAN プライマリーインスタンスで発生しているフルスキャンを特定 クエリ効率 クエリ効率が1,000以上かつドキュメントスキャン数が多いクエリ 新規スロークエリ 先週比で新たに発生したスロークエリを特定 以下は、実際に作成したDatadog Dashboardです。 Goスクリプトによるデータ取得と優先度判定 ダッシュボードで取得している内容をJSON形式で取得するGoスクリプトを作成し、事前に定めたルールに基づいて、Claude Codeが優先度を判定します。 優先度は以下を使用しました。 PrimaryインスタンスでのCOLLSCANが発生しているクエリ クエリ効率が1000以上かつ、ドキュメントスキャン数が多いクエリ 新規発生のスロークエリ 取得しているメトリクスは以下です。 メトリクス 用途 @mongodb.plan_summary ( collscan_count を算出) インデックス未使用のフルスキャン検出 @mongodb.docs_examined , @mongodb.nreturned ( docs_efficiency を算出) クエリ効率の評価 @duration ( avg_duration_ns / p99_ns を算出) 今週・先週の実行時間比較 pup 未対応による直接API呼び出し ダッシュボードの内容取得にあたり、2026年2月にリリースされた https://github.com/DataDog/pup の使用も検討しましたが、DBMのパフォーマンス結果を集計する /api/v2/query/scalar APIに未対応だったため、APIを直接呼び出す形で実装しました。 呼び出し元の特定 なお、CLINICSではAPIと非同期ジョブそれぞれにミドルウェアを自作し、MongoDBクエリにAPIパスやJobクラス名をコメントとして付与する仕組みが既に導入されていました。 コメントがDBMに連携されることで、Datadogコンソール上のクエリ詳細画面にAPIパスやJobクラス名が直接表示されるようになりました。これにより、スロークエリが発生した際にどのコードが起点かをコンソール上で即座に確認できます。以前はMongoDB Atlasからログをダウンロードし、スクリプトを実行してコメントを抽出する必要があったため、1件の呼び出し元特定に数分かかっていました。この手順がなくなり、調査の初動が大幅に短縮されました。 GitHub Issueへの自動登録 QuerySignatureによるIssue管理 スロークエリを一意に識別できるよう、スロークエリ専用のTagをGitHub 上で作成し、IssueのタイトルにQuerySignatureを含めるようにしました。 これにより、同一クエリの重複Issue作成を防ぎ、過去の対応履歴をIssueで追跡できます。 （例） 【スロークエリ改善】sales - 売上月次比較 aggregate クエリ (qs:bed4b54513c9204e) 改善困難クエリのナレッジストック 問題はあるが解消が難しいクエリ（例：クエリ対象をMongoDBからOpenSearchに変更する必要があるケースなど）はIssueにストックしておき、 既知のクエリとして扱うことで新規スロークエリの検出に集中できるようにしました。 以下は、サンプルのGitHub Issueです。(*2) Claude Codeスキルとしての統合 上記の「Goスクリプトによるデータ取得・優先度判定」と「GitHub Issueへの自動登録」の一連のステップは、Claude Codeのスキルとしてまとめています。週次作業時はこのスキルを実行するだけで、スロークエリの検出からIssue生成までが自動的に完了します。 効果 週次の作業工数を1時間から10分に削減：MongoDB Atlasからログをダウンロードして手動で分析していた作業が、Claude Codeスキルにまとめられ、スキルの実行と結果の確認のみになり、週次の作業工数を削減できました。 スロークエリのナレッジを蓄積できる基盤の構築：改善困難なクエリや過去の対応履歴をGitHub Issueにストックすることで、スロークエリに関するナレッジを体系的に蓄積・参照できる基盤を整えることができました。これにより、新規スロークエリの検出に集中できるようになり、チーム内での知見共有も容易になりました。 今後の展望 今回はパフォーマンス課題の発見・Issue化までを自動化しました。最終的には「AIが課題を発見しPRを作成し、人間が責任を持ってリリースする」サイクルの実現を目指しており、次のステップを検討しています。 PR作成の自動化：AI推進グループ(*3)と連携し、インデックス追加などのPR作成まで自動化します。 スロークエリデータの長期保存基盤の構築：Datadog DBMのデータ保持期間は2週間であるため、現状では長期的なトレンド分析ができません。Goスクリプトで取得したデータをS3に蓄積し、Athenaで分析する基盤を構築することで、月単位・四半期単位でのパフォーマンス推移の可視化や、改善施策の効果測定を可能にします。 パフォーマンス評価の自動化：DBメトリクスも合わせて総合的な評価を行います。 まとめ Datadog DBMの結果からルールベースでスロークエリを自動検出し、Claude Codeスキルを活用してGitHub Issueを自動生成する基盤を構築しました。 最終目標はAIがパフォーマンス課題の発見からPR作成までを担い、人間が責任を持ってリリースすることです。 本記事ではその第一歩として、課題の発見・Issue化までの自動化を解説しました。 メドレーでは、SREをはじめ「医療ヘルスケアの未来」を共に創っていくエンジニアを大募集中です！少しでもご興味をお持ちいただけましたらぜひ、ご応募お待ちしております！ 株式会社メドレー エンジニア の求人一覧 株式会社メドレー エンジニア の求人一覧です。| HRMOS hrmos.co SREエンジニア／医療プラットフォーム本部 | 株式会社メドレー SREエンジニア／医療プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。 注釈 *1: CLINICSでのDatadog活用事例については、こちらの記事を参照ください。 CLINICSの信頼性を守るDatadog 導入・活用事例(株式会社メドレー) 株式会社メドレーのDatadogのレビューです。導入に至った背景や導入検討時の悩み、実際に導入してから感じたDatadogのメリットと課題感を導入効果とともにレビューしていただきました。 findy-tools.io *2: 具体的なデータは、全てダミーデータを使用しています。 *3: AI推進グループは、「AIで『医師』と『エンジニア』の生産性を最大化する」というミッションのもとで、プロダクトへのAI機能導入と開発者の生産性向上に取り組む組織です。詳しく知りたい方は、以下を参照ください。 - YouTube Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube. www.youtube.com 「ゼロ距離医療」実現へ。医師とエンジニアの生産性最大化にAIで挑戦｜メドレー公式note 皆さん、こんにちは！ 株式会社メドレーでDevRelをしている重田です。 メドレーの開発組織で働く社員を「入社エントリーブログ」の形式でご紹介します🎉 今月ご紹介するのはAI推進グループ エンジニアの大塚さんです。 ぜひご一読いただき、メドレーに興味を持っていただけたら嬉しいです！ まず初めに自己紹介をお願いします 大塚と申します。現在は医療プラットフォーム本部の医科診療所プロダクト開発室 AI推進グループでマネジャーを務めており、主にクラウド診療支援システム「CLINICS」に携わっています。 AI推進グループとは？ AI推進グループは、「AI で ”医師”と”エンジニア” note.com

はじめまして！コーポレートIT室の種田と申します。 コーポレートIT室では全従業員が利用するデバイス、ネットワークインフラ、 SaaS といった IT 全般を統括しています。 メドレーでは自社開発のプロダクト、M&Aで取得したプロダクト、またローカルおよびグローバルのプロダクトを、会社や国を越えて統一的に管理・運用することを目指す「Global One」という思想を掲げています。 プロセスやシステムにおいても、この思想に基づき、個別最適に陥ることなく、グローバルに共通して適用できる標準的なIT基盤を構築することが求められています。 コーポレートITでシステムを選定するときも、「グローバルで標準的に活用できること」が観点のひとつとなっています。Google Workspace、Slack、Confluence、ServiceNow、GitHubといった、各領域でデファクトスタンダードとなっているものを導入・活用しています。 メドレーの人事基幹システムは、2022年からグローバル共通で「Workday」を利用しています。私はコーポレートITとしてWorkdayの導入プロジェクトに参加し、現在は運用や新規機能の導入検討などを担当しています。 昨年の9/15-18に、サンフランシスコで開催されたWorkdayの年次カンファレンス「Workday Rising 2025」に初めて参加してきました。開催から少し日数が経過していますが、当日の熱気あふれる会場の様子や海外カンファレンス初参加の感想をお届けします。 会場の様子 会場はサンフランシスコ Moscone Centerです。合計で500以上のセッションがありました。会場移動とインプットの繰り返しでかなりタフな4日間を過ごしました（最終日が終わった後、ばっちり風邪を引きました） 事前に参加セッションの計画を立てていたのですが、期間中に発表された新機能に関する追加セッションも多くありました。Workdayの機能ごとのブースや協賛企業のブースも多く、4日間ではとても回りきれません！ほとんどのセッションは後から動画が公開されるので、日程後半は会場でしか体験できないハンズオンセッションやブースを中心に参加していました。 おもしろかったセッション・ブース Keynote: The Workday Platform: Transforming Work with Agentic AI AI関連企業の買収やAIを中心とした新機能の発表など、初めて聞くことばかりでとてもわくわくしました。WorkdayでのAIエージェント開発・管理・実行やWorkday外のさまざまなデータとの連携を加速させる動きを感じました。発表された新機能の中で、Workdayのデータをゼロデータコピーで外部システムと連携できる「Workday Data Cloud」が個人的にとても気になりました。 セッションの中でも、Workdayは人事基幹システムから「エンタープライズAIプラットフォーム」へ位置づけを変化していくと話されていました。 Equipping You to Manage Workday Learning: A Hands-On Lab Workdayの学習管理システム(LMS)である「Workday Learning」の研修コンテンツ作成をハンズオンで学べるセッションがありました。ひとり1台パソコンが準備されており、ガイドに沿って手を動かしていきます。（意外と簡単に実装できそうでした！）Workday Learningのハンズオンは日本では開催されないため、良い経験になりました。 Workdayブース Workdayを開発しているエンジニアの方がブースにいたので、新機能のデモだけではなく、細かな質問にも対応してもらえるのがとてもよかったです！（ただし、私は英語ができないので他の方が質問しているのを聞いて理解するにとどまりました…もっと話せるようになりたい） 協賛企業ブース 協賛企業ブースには、日本ではあまり知られていないHRTechサービスのブースが多かったです。ここでもAI関連のサービスが多かった印象です。気になったサービスがいくつかあったのでご紹介します！ TechWolf TechWolf | The intelligence to act with confidence TechWolf is the foundational data layer for workforce transformation in large enterprises. For the first time ever, you can use accurate skill data to hire smarter, improve learning, fix internal mobility and plan your workforce with confidence. www.techwolf.ai Workdayのスキル管理システムとGoogle Workspace / Slack / Jira / Confluenceを連携することで、自分のスキルプロファイルを生成してくれるSaaSがありました。日々の業務でアウトプットしたデータから自分のスキルを提案されると、自身で気づいていない意外なスキルを発見できる可能性もあって良さそうです！ eduMe Enabling frontline teams to execute consistently eduMe is the frontline enablement platform that helps teams execute consistently at scale - with guidance and support embedded into real work. www.edume.com TikTokのような短時間の動画で隙間時間に学べる、デスクレスワーカーをターゲットとした研修プラットフォームです。コンテンツもPDFなどの資料からAIが自動生成してくれるため、管理者側にもメリットがあって良いと思いました。 まとめ 全体を通しての感想 グローバルシステムの年次カンファレンスへの参加は私にとって初めての経験でした。規模・セッション数ともに桁違いですし、自分が興味があることを開発エンジニアに直接聞くことができるのも年次カンファレンスならではの貴重な機会でした。 また、日本のWorkdayユーザー企業様とも交流する機会が多くありました。ユースケースやお悩みごとなど情報交換をたくさんすることができました。 （おまけ）最終日前日にはサンフランシスコ・ジャイアンツの本拠地であるオラクル・パークを貸し切ったパーティが開催されました。グラウンドやベンチにも入ることができたのがうれしかったです！サンフランシスコに到着した日にドジャース戦を見に行っていたので、大谷選手と同じ場所に立てた…！と思ってしまいました。 Workdayの今後の活用について セッションでは、AIエージェントを含むアプリ開発やエージェントのセキュアな管理、外部とのデータ連携といった、エンジニア向けのトピックが多かったことが印象的でした。 AIエージェントとのやりとりで業務が進められていく世界観も提示されていました。Workdayでの各種申請・承認がAIエージェントとのやりとりだけで完結できると、従業員にとってうれしい未来だなと思っています。今後のアップデートも継続してキャッチアップし、便利な機能は積極的に展開していきたいです。 また、Workdayのタレントマネジメント分野ではAIを使った機能拡充が多く予定されています。従業員のタレント情報（スキル、職歴、興味など）のWorkdayへの集約を進め、新機能を活用できる状態に整えていきたいと考えています。 おわりに Workday Risingへの参加を通して、日本開催のイベントでは得られない多くのインプットを得ることができました。参加する機会をいただけたことを本当に感謝しています。また、このインプットを無駄にせず、今後のメドレーの人事戦略にシステムを通じて貢献していきたいと思ってます。 現在、メドレーでは一緒に働く仲間を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。 株式会社メドレー 株式会社メドレー です。| HRMOS hrmos.co ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。 メドレー公式note｜note 「医療ヘルスケアの未来をつくる」というミッションのもと、様々な医療課題を解決するためのデジタル活用を推進する【株式会社メドレー】の公式noteです。https://www.medley.jp/ note.com

はじめまして！コーポレートIT室の種田と申します。 コーポレートIT室では全従業員が利用するデバイス、ネットワークインフラ、 SaaS といった IT 全般を統括しています。 メドレーでは自社開発のプロダクト、M&Aで取得したプロダクト、またローカルおよびグローバルのプロダクトを、会社や国を越えて統一的に管理・運用することを目指す「Global One」という思想を掲げています。 プロセスやシステムにおいても、この思想に基づき、個別最適に陥ることなく、グローバルに共通して適用できる標準的なIT基盤を構築することが求められています。 コーポレートITでシステムを選定するときも、「グローバルで標準的に活用できること」が観点のひとつとなっています。Google Workspace、Slack、Confluence、ServiceNow、GitHubといった、各領域でデファクトスタンダードとなっているものを導入・活用しています。 メドレーの人事基幹システムは、2022年からグローバル共通で「Workday」を利用しています。私はコーポレートITとしてWorkdayの導入プロジェクトに参加し、現在は運用や新規機能の導入検討などを担当しています。 昨年の9/15-18に、サンフランシスコで開催されたWorkdayの年次カンファレンス「Workday Rising 2025」に初めて参加してきました。開催から少し日数が経過していますが、当日の熱気あふれる会場の様子や海外カンファレンス初参加の感想をお届けします。 会場の様子 会場はサンフランシスコ Moscone Centerです。合計で500以上のセッションがありました。会場移動とインプットの繰り返しでかなりタフな4日間を過ごしました（最終日が終わった後、ばっちり風邪を引きました） 事前に参加セッションの計画を立てていたのですが、期間中に発表された新機能に関する追加セッションも多くありました。Workdayの機能ごとのブースや協賛企業のブースも多く、4日間ではとても回りきれません！ほとんどのセッションは後から動画が公開されるので、日程後半は会場でしか体験できないハンズオンセッションやブースを中心に参加していました。 おもしろかったセッション・ブース Keynote: The Workday Platform: Transforming Work with Agentic AI AI関連企業の買収やAIを中心とした新機能の発表など、初めて聞くことばかりでとてもわくわくしました。WorkdayでのAIエージェント開発・管理・実行やWorkday外のさまざまなデータとの連携を加速させる動きを感じました。発表された新機能の中で、Workdayのデータをゼロデータコピーで外部システムと連携できる「Workday Data Cloud」が個人的にとても気になりました。 セッションの中でも、Workdayは人事基幹システムから「エンタープライズAIプラットフォーム」へ位置づけを変化していくと話されていました。 Equipping You to Manage Workday Learning: A Hands-On Lab Workdayの学習管理システム(LMS)である「Workday Learning」の研修コンテンツ作成をハンズオンで学べるセッションがありました。ひとり1台パソコンが準備されており、ガイドに沿って手を動かしていきます。（意外と簡単に実装できそうでした！）Workday Learningのハンズオンは日本では開催されないため、良い経験になりました。 Workdayブース Workdayを開発しているエンジニアの方がブースにいたので、新機能のデモだけではなく、細かな質問にも対応してもらえるのがとてもよかったです！（ただし、私は英語ができないので他の方が質問しているのを聞いて理解するにとどまりました…もっと話せるようになりたい） 協賛企業ブース 協賛企業ブースには、日本ではあまり知られていないHRTechサービスのブースが多かったです。ここでもAI関連のサービスが多かった印象です。気になったサービスがいくつかあったのでご紹介します！ TechWolf TechWolf | The intelligence to act with confidence TechWolf is the foundational data layer for workforce transformation in large enterprises. For the first time ever, you can use accurate skill data to hire smarter, improve learning, fix internal mobility and plan your workforce with confidence. www.techwolf.ai Workdayのスキル管理システムとGoogle Workspace / Slack / Jira / Confluenceを連携することで、自分のスキルプロファイルを生成してくれるSaaSがありました。日々の業務でアウトプットしたデータから自分のスキルを提案されると、自身で気づいていない意外なスキルを発見できる可能性もあって良さそうです！ eduMe Training that's built for your frontline eduMe is the AI-first frontline training platform that slots invisibly into your existing tools - helping you get better training to your frontline, faster. www.edume.com TikTokのような短時間の動画で隙間時間に学べる、デスクレスワーカーをターゲットとした研修プラットフォームです。コンテンツもPDFなどの資料からAIが自動生成してくれるため、管理者側にもメリットがあって良いと思いました。 まとめ 全体を通しての感想 グローバルシステムの年次カンファレンスへの参加は私にとって初めての経験でした。規模・セッション数ともに桁違いですし、自分が興味があることを開発エンジニアに直接聞くことができるのも年次カンファレンスならではの貴重な機会でした。 また、日本のWorkdayユーザー企業様とも交流する機会が多くありました。ユースケースやお悩みごとなど情報交換をたくさんすることができました。 （おまけ）最終日前日にはサンフランシスコ・ジャイアンツの本拠地であるオラクル・パークを貸し切ったパーティが開催されました。グラウンドやベンチにも入ることができたのがうれしかったです！サンフランシスコに到着した日にドジャース戦を見に行っていたので、大谷選手と同じ場所に立てた…！と思ってしまいました。 Workdayの今後の活用について セッションでは、AIエージェントを含むアプリ開発やエージェントのセキュアな管理、外部とのデータ連携といった、エンジニア向けのトピックが多かったことが印象的でした。 AIエージェントとのやりとりで業務が進められていく世界観も提示されていました。Workdayでの各種申請・承認がAIエージェントとのやりとりだけで完結できると、従業員にとってうれしい未来だなと思っています。今後のアップデートも継続してキャッチアップし、便利な機能は積極的に展開していきたいです。 また、Workdayのタレントマネジメント分野ではAIを使った機能拡充が多く予定されています。従業員のタレント情報（スキル、職歴、興味など）のWorkdayへの集約を進め、新機能を活用できる状態に整えていきたいと考えています。 おわりに Workday Risingへの参加を通して、日本開催のイベントでは得られない多くのインプットを得ることができました。参加する機会をいただけたことを本当に感謝しています。また、このインプットを無駄にせず、今後のメドレーの人事戦略にシステムを通じて貢献していきたいと思ってます。 現在、メドレーでは一緒に働く仲間を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。 株式会社メドレー 株式会社メドレー です。| HRMOS hrmos.co ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。 メドレー公式note｜note 「医療ヘルスケアの未来をつくる」というミッションのもと、様々な医療課題を解決するためのデジタル活用を推進する【株式会社メドレー】の公式noteです。 note.com

はじめに この記事は Medley（メドレー） Advent Calendar 2025 16日目の記事です。 こんにちは。医療プラットフォーム本部 病院プロダクト統括部 開発戦略室の竹本です。re:Invent 2025 が閉幕し、今年も残すところあと僅かとなりました。 今回は Amazon Bedrock に関する記事を書いてみたいと思います。 Bedrockで国内限定のクロスリージョン推論が可能に！ 少し前のAWSアップデートですが、 2025年9月29日に Amazon Bedrock で Claude Sonnet 4.5 が利用可能になると同時に、Claude Sonnet 4.5で日本国内に限定したクロスリージョン推論機能の提供が開始されました。この機能の特徴については、以下の Amazon Web Services ブログの記事に詳細が記載されています。 Amazon Web Services ブログ | Amazon Bedrock で日本国内に閉じた Anthropic Claude 4.5 の推論が可能に！日本国内クロスリージョン推論のご紹介 この機能を利用すると、 生成 AI の推論リクエストを日本国内の東京・大阪リージョンのみに限定して分散ルーティング させることができます。また記事の中で日本国内クロスリージョン推論を選択すべきケースのひとつとして医療業界の例が挙げられており、弊社もその例外ではありません。 しかし金融や医療の業界でも積極的にパブリッククラウドが活用されている近年において、なぜ国内にリクエストを閉じなければならないのかピンと来ない方もいらっしゃるかもしれません。 そこで医療系IT企業の視点から、このアップデートが持つ意義について徹底的に解説したいと思います。 本記事に関する免責事項 本記事の中で AWSをはじめ各社が公開しているサービスの情報や 各省が公開しているガイドラインの内容について言及していますが、それぞれ 2025年12月時点の情報をもとに執筆しております。いずれも内容が改訂される可能性がありますので、最新の情報につきましては各機関より正式に公開されている情報をもとにご判断いただくようお願いいたします。 きっかけ まず、本記事を書くことになったきっかけからお伝えします。 私が所属する開発戦略室では当時、一部のシステムで Amazon Bedrock で Claude 3.5 Sonnet のモデル ( anthropic.claude-3-5-sonnet-20240620-v1:0 ) が利用されていました。 2025年12月時点では Claude 3.5 Sonnet は既に Anthropic社としてはEOSを迎えてしまったモデルであり (1) 、Amazon Bedrock ではレガシーモデルと呼ばれる扱いとして 2026年3月1日 までに別のモデルへ移行することが促されています。(2) そこで、冒頭に記載した日本国内に閉じたクロスリージョン推論機能の利用が 果たして必須となるか否かをこの機会に明らかにすることにしました。 (1) 参考： Anthropic | Claude docs - モデルの廃止予定 (2) 参考： AWS | Amazon Bedrock - モデルのライフサイクル クロスリージョン推論の基本情報 まずはクロスリージョン推論についておさらいをします。 クロスリージョン推論とは、リージョンごとの混雑状況に応じてAWSが基盤モデルを利用可能なリージョンのエンドポイントへ自動的に推論リクエストをルーティングしてくれる機能です。リージョン単位で基盤モデルを呼び出す従来の方式と比較すると、リクエスト数のクォータ (上限) が広がりスロットリングエラーの発生を回避しやすくなります。 Amazon Bedrock モデル推論 b.実践編 【Amazon Bedrock Series #02b】 より引用 Claude Sonnetでは、Claude 3.5 Sonnet以降のモデルはすべてクロスリージョン推論が実行される推論プロファイルのみ提供されています。 ところが、クロスリージョン推論は ユーザーが利用するリージョンを選択することはできません。 利用する推論プロファイルごとに既定のいずれかのリージョンへ送信される仕様であり、冒頭のアップデートが発表されるまではいずれも日本国外にあるリージョンが含まれておりました。(3) 詳細は次章で解説しますが、医療情報システムでは 日本国外にある情報機器を使えない ことが原則です。 では果たして医療情報システムは海外の優れた最新AIを利用することが困難なのでしょうか。 (3) 参考情報： AWS | Amazon Bedrock - 推論プロファイルでサポートされているリージョンとモデル 3省2ガイドラインの存在 医療情報を取り扱うシステムにおいて、避けて通れないのがいわゆる 3省2ガイドラインです。3省2ガイドラインとは、厚生労働省・総務省・経済産業省が策定した、医療情報を安全に取り扱うための2つの指針の総称です。 厚生労働省 | 医療情報システムの安全管理に関するガイドライン　第6.0版（令和5年5月） 経済産業省 | 医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン 病院等の医療機関だけでなく、弊社のように医療情報を扱うシステムを提供する事業者もまたこれらのガイドラインに記載された安全管理措置やセキュリティに対する対策を講じることが求められます。 そしてこのガイドラインに含まれる項目のひとつに、 情報を格納する情報機器は日本国内法の適用が及ぶ場所に設置すること が求められています。 厚生労働省 | 医療情報システムの安全管理に関するガイドライン 第 6.0 版 企画管理編 ─ 7章より抜粋 では、いかなる場合も日本国外のサービスを利用できないのでしょうか。 この疑問点を考える上で、ポイントが大きく分けると 2 点あります。 1. 送信された推論リクエストは、Amazon Bedrock内で情報機器に情報が格納・保存されるのか 2. もし Amazon Bedrock で情報が保存されないならば日本国外にリクエストして良いのか 1. Amazon Bedrock は “情報を格納“ するのか 結論として、Amazon Bedrock では入出力するデータが保存・記録されないことが公式ドキュメントに明記されており (4) 、クロスリージョン推論であってもこの方針は変わりません。 (4) 参考： AWS | Amazon Bedrock - データ保護 ▼ 該当箇所を抜粋 プロンプトおよび AI のレスポンスを保存またはログに記録することはありません。 この点については、Amazon Bedrockを既に利用されている方によく知られていることかと思います。 2 . それなら国外サーバーを利用してもよいのか では医療情報を取り扱うシステムにおいて、グローバルクロスリージョン推論のように日本国外のサーバーに対してリクエストを送信してもよいのでしょうか。 これについては、厚生労働省が公開している別の資料の中に手がかりがありました。 厚生労働省 | 「医療情報システムの安全管理に関するガイドライン 第 6.0 版」 に関するＱ＆Ａ ─ P.45 より抜粋 この資料によると、以下の条件に該当する場合には国内法の適用を受けていないサーバーを利用可能であると記載されています。 ▼ 該当箇所を抜粋 医療情報が保存されないことが、契約等において担保されている場合は国内法の適用を受けていないサーバを利用可能 AWSドキュメント = 契約…？ ここでまた新たな疑問が生まれます。 AWSドキュメントに明記されていることはこれに該当するのでしょうか。 結論として、「契約等において担保されている」に相当するとまでは言えない でしょう。 なぜなら AWSドキュメントは、個別具体的な当事者間の合意内容をもとに作成した契約書とは性質が大きく異なるからです。AWSドキュメントはサービスアップデートの中で AWS社によって内容が一方的に変更されることもあり、サービスユーザーである我々はこれを受け入れる or 利用を停止する のいずれかしか選択肢がありません。 したがって、グローバルクロスリージョン推論の利用は明確に禁止されているとまでは言えないものの、医療情報システムのサービス提供者としては日本国内に限定したクロスリージョン推論を採用する方が無難であると考えられます。 今回の結論 以上のことから冒頭のサービスアップデートは、 多くの推論リクエストを処理可能になる・ガイドラインを確実に準拠できる・最新のモデルを利用できる と多くのメリットを含む内容でした。 入出力トークン数が大きい AIワークロードの場合、料金が 10% 上乗せになってしまう点は痛手になりますが、プロダクトの付加価値とコンプライアンス要件の両立を可能にする選択肢が生まれたことは大きな一歩となりました。 多くのイノベーションが安全性とトレードオフの関係になっている中で、国内の厳格な安全基準を守りつつ最高水準のベンチマークを誇る高性能モデルを安定したインフラで利用できるようになる。 そんな選択肢を提供してくれた事こそ、医療業界にもたらす一番の恩恵と言えるでしょう。 最後に 本記事では、医療業界における日本国内に閉じたクロスリージョン推論の有用性について解説させていただきました。 私が所属する医療プラットフォーム本部では、医師の偏在や医療従事者の人材不足が引き起こす長時間労働という課題に対し 生成 AI のテクノロジーを用いた業務効率化によって、医療従事者の負担を軽減する試みに取り組んでいます。 メドレー、病院向け電子カルテ「MALL」で医療文書作成をAIで支援する新機能のパイロット版を提供開始 このような取り組みの陰には、厳格なルールの中で技術選定を行うエンジニアの苦労と「医療ヘルスケアの未来をつくる」弊社ならではのやりがいがあることを、より多くの人に知ってもらえればと願っております。 本記事がどなたかの参考になれば幸いです。 次回予告 Medley（メドレー） Advent Calendar 2025 もいよいよ後半戦！ 次回 17 日目の担当は QA エンジニアの @daishu さんです！🎉 明日も是非お楽しみに〜！！ We’re hiring! メドレーでは、「医療ヘルスケアの未来」を共に創っていくエンジニアを大募集中です！少しでもご興味をお持ちいただけましたらぜひ、ご応募お待ちしております！ 株式会社メドレー 株式会社メドレー です。| HRMOS hrmos.co ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

こんにちは。人材プラットフォーム本部でプロダクトマネージャーをやっている渥美です。 メドレーは2025年12月4日に開催された「pmconf 2025」に、ゴールドスポンサーとして協賛しました。 プロダクトマネージャーカンファレンス 2025 | pmconf 2025 プロダクトマネージャー⼀⼈ひとりの成⻑と挑戦が、新たな未来を⽣み出す。pmconfは、それを信じています。 pmconf 2025は、プロダクトマネージャーの成⻑意欲と挑戦への熱量がぶつかり合う場へと進化します。 登壇者は、より良い未来を切り拓く挑戦のリアルを語る 。参加者は、切磋琢磨の渦に⾶び込み、挑戦のエネルギーを⾼める。スポンサーは、この挑戦の場を⽀え、熱狂を共に創り上げる。そして、ここで⽣まれる熱量が、未来を動かす原動⼒となる。 2025.pmconf.jp 会場の様子 年に一度開催される日本最大のPMイベント「pmconf」は、2016年に始まり今年で10回目。 東京会場では2つのホールと5つのルームに分かれて約30本ものトークセッションや、OST、PMフィッシュボウルなどの実践セッションが行われました。 弊社ブースの様子 ブースでは、プロダクトマネージャーとしての強みを4つのタイプに診断する「PMタイプ診断」を行い、参加していただいた方にはノベルティをお渡ししました。 新しいロゴのステッカーも初お披露目です！ 医療にちなんで、総合診療医・臨床研究医・外科医・看護師長の4つのタイプに診断。 開場時間からたくさんの方にお越しいただき、メドレーのプロダクトにも多くの関心をいただきました。 実践型セッションの様子 トークセッションと同じく盛り上がりを見せたのは、OST（Open Space Technology）。 セッション開始時に話したいテーマを紙に書き出し、一緒に議論する仲間に呼びかけます。 参加者はそのテーマを選んで、セッションに加わります。 皆さん真剣に議論されていて熱気がすごかったです！ 弊社のwatanabeも参加。 PMフィッシュボウルでは、「そもそもプロダクトマネージャーって必要？」という核心的なテーマのもと、白熱した議論が行われました。自社でもプロダクト横断でやってみると面白いかも？ 戦利品 狙っていたスタンプラリーのパーカーは間に合わなかったけど、ロゴ入りタンブラーをゲットできました。 RevenueCatさんの靴下は来場したときから一目惚れだったので当たって嬉しかったです！（猫ちゃんモチーフで全てがかわいかった） 最後に 初めてのブース参加でしたが、とても楽しかったです。次回はもっとセッションや交流を楽しみたいと思います。 （開場後まだ元気な私。すぐに軟弱な足腰が悲鳴をあげ、マツキヨで湿布を買いました） メドレーはこれからも、医療ヘルスケアの未来を作るために、様々なプロダクト・サービスを開発し提供していきます。 現在、メドレーでは一緒に働く仲間を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。 株式会社メドレー 求人一覧

こんにちは。人材プラットフォーム本部でプロダクトマネージャーをやっている渥美です。 メドレーは2025年12月4日に開催された「pmconf 2025」に、ゴールドスポンサーとして協賛しました。 プロダクトマネージャーカンファレンス 2025 | pmconf 2025 プロダクトマネージャー⼀⼈ひとりの成⻑と挑戦が、新たな未来を⽣み出す。pmconfは、それを信じています。 pmconf 2025は、プロダクトマネージャーの成⻑意欲と挑戦への熱量がぶつかり合う場へと進化します。 登壇者は、より良い未来を切り拓く挑戦のリアルを語る 。参加者は、切磋琢磨の渦に⾶び込み、挑戦のエネルギーを⾼める。スポンサーは、この挑戦の場を⽀え、熱狂を共に創り上げる。そして、ここで⽣まれる熱量が、未来を動かす原動⼒となる。 2025.pmconf.jp 会場の様子 年に一度開催される日本最大のPMイベント「pmconf」は、2016年に始まり今年で10回目。 東京会場では2つのホールと5つのルームに分かれて約30本ものトークセッションや、OST、PMフィッシュボウルなどの実践セッションが行われました。 弊社ブースの様子 ブースでは、プロダクトマネージャーとしての強みを4つのタイプに診断する「PMタイプ診断」を行い、参加していただいた方にはノベルティをお渡ししました。 新しいロゴのステッカーも初お披露目です！ 医療にちなんで、総合診療医・臨床研究医・外科医・看護師長の4つのタイプに診断。 開場時間からたくさんの方にお越しいただき、メドレーのプロダクトにも多くの関心をいただきました。 実践型セッションの様子 トークセッションと同じく盛り上がりを見せたのは、OST（Open Space Technology）。 セッション開始時に話したいテーマを紙に書き出し、一緒に議論する仲間に呼びかけます。 参加者はそのテーマを選んで、セッションに加わります。 皆さん真剣に議論されていて熱気がすごかったです！ 弊社のwatanabeも参加。 PMフィッシュボウルでは、「そもそもプロダクトマネージャーって必要？」という核心的なテーマのもと、白熱した議論が行われました。自社でもプロダクト横断でやってみると面白いかも？ 戦利品 狙っていたスタンプラリーのパーカーは間に合わなかったけど、ロゴ入りタンブラーをゲットできました。 RevenueCatさんの靴下は来場したときから一目惚れだったので当たって嬉しかったです！（猫ちゃんモチーフで全てがかわいかった） 最後に 初めてのブース参加でしたが、とても楽しかったです。次回はもっとセッションや交流を楽しみたいと思います。 （開場後まだ元気な私。すぐに軟弱な足腰が悲鳴をあげ、マツキヨで湿布を買いました） メドレーはこれからも、医療ヘルスケアの未来を作るために、様々なプロダクト・サービスを開発し提供していきます。 現在、メドレーでは一緒に働く仲間を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。 株式会社メドレー 求人一覧

はじめに この記事は Medley（メドレー） Advent Calendar 2025 4日目の記事です。 医療プラットフォーム本部 プラットフォーム開発室 SRE グループの山田です。 医療機関向け SaaS である CLINICS の安定稼働とシステム信頼性の向上に取り組んでいます。 本記事では、 VPCフローログ / Amazon Athena / ネットワークACL を用いて NATゲートウェイ への通信内容を調査する方法について紹介します。 タイトルにもありますが、かなり力技になりますので本番環境で実施は控えてください。 背景 CLINICSには外部サービスと連携して機能を提供するAPIが多く存在します。 また、システム間通信にもNATゲートウェイを経由して通信することがあるため、サービスの成長に伴いECS Taskのスケールアウトによって、NATゲートウェイを経由する通信量は着実に増えていきます。 日常の運用では問題が見えにくくても、万が一NATゲートウェイで障害が発生してしまった場合、その影響は広範囲に及び、サービスの復旧に時間を要する可能性があります。 特に懸念される障害シナリオの一つが、トラフィック集中による「ポート割り当てエラーの増加」です。 これにより、NATゲートウェイへの新規接続が失敗し、通信が遮断される可能性があります。 参考： Amazon VPC の NATゲートウェイで発生する「エラーポートアロケーション」エラーを解決するにはどうすればよいですか？ こうしたリスクを未然に防ぐためには、「NATゲートウェイの冗長化」や、「NATゲートウェイ経由の通信が必須か」を見直し、可能な通信はVPCエンドポイントへ移行させるといったアーキテクチャの最適化が求められます。 CLINICSでは、この課題への第一歩として、現状のNATゲートウェイの利用実態を詳細に把握する調査を実施しました。 具体的には、NATゲートウェイを介して通信しているシステムと通信先のサービスを洗い出すことに取り組みました。 次章からは、この調査で得られた具体的な知見と、それに基づきどのようにインフラアーキテクチャの改善を進めたのかを紹介します。 調査方法 ここからは、NATゲートウェイ経由でのトラフィックを調査し、CLINICSが通信している外部のサービスを特定する方法について紹介します。 大枠、以下のような流れで調査を進めていきました。 VPCフローログを有効化 Athena からVPCフローログを解析 通信先のAWSサービスを特定 通信先のAWS以外のサービスを特定 VPCフローログを有効化 VPCフローログはVPC内部の通信内容をキャプチャする機能です。 もちろん、「VPC内部の通信」にはNATゲートウェイの通信も含まれます。 ログはAmazon CloudWatch Logs、Amazon S3、Amazon Kinesis Data Firehoseへ保存することができますが、本記事ではS3へ保存する想定で解説していきます。 ログレコードの形式 VPCフローログのフォーマットはデフォルト設定でもある程度調査が可能ですが、調査をする上で追加で以下のフィールドを追加しました。 tcp-flags: TCP接続の状態（SYN、ACK、FINなど）を確認するために使用します。NATゲートウェイはアイドルタイムアウト時にRSTパケットを送信するため、調査目的で追加しました pkt-srcaddr: NAT変換前の元の送信元IPアドレス。NATゲートウェイ経由の通信では、送信元を特定するために変換前のIPを追跡するために使用します pkt-dstaddr: NAT変換前の元の送信先IPアドレス。実際に通信しようとしている外部サービスのIPを特定するために使用します pkt-src-aws-service: 送信元IPがAWSサービスのIP範囲に該当する場合、そのサービス名が記録されます pkt-dst-aws-service: 送信先IPがAWSサービスのIP範囲に該当する場合、そのサービス名が記録されます。EC2やS3など、どのAWSサービスと通信しているかを判別できます traffic-path: トラフィックがどの経路を通っているかを確認できます。NATゲートウェイ経由かどうかの判定に役立ちます 参考: フローログレコード フローログに追加できる情報はかなり種類があり定期的に更新されるので、設定するときは用途に合わせたフォーマットになるようドキュメントを一読することをお勧めします。 また、既存のフローログのフォーマットを変更することはできないので注意が必要です。 VPCフローログを分析するための基盤を作成 VPCフローログを有効化したので、S3にVPC内のトラフィックに関する情報が保存されるようになりました。 次に、これらのログを集計して通信内容に関するより詳細な情報を取得できるようにするためにAthenaテーブルを用意します。 Athena テーブル作成 CREATE EXTERNAL TABLE IF NOT EXISTS vpc_flow_logs ( flowlog_version INT , account_id STRING, interface_id STRING, srcaddr STRING, dstaddr STRING, srcport INT , dstport INT , protocol INT , packets BIGINT , bytes BIGINT , start_time BIGINT , end_time BIGINT , traffic_action STRING, log_status STRING, tcp_flags INT , pkt_srcaddr STRING, pkt_dstaddr STRING, pkt_src_aws_service STRING, pkt_dst_aws_service STRING, traffic_path INT ) PARTITIONED BY (dt STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY ' ' LOCATION 's3://bucket-name/AWSLogs/XXXXXXXXXXXX/vpcflowlogs/region' TBLPROPERTIES ( "skip.header.line.count" = "1" ); 作成したテーブルに対してパーティションを追加して、データを取り込ませたら準備完了です。 ALTER TABLE vpc_flow_logs ADD PARTITION (dt= '20YY-MM-DD' ) LOCATION 's3://bucket-name/AWSLogs/XXXXXXXXXXXX/vpcflowlogs/region/20YY/MM/DD/' ; 通信対象の特定 実際にクエリを実行してNATゲートウェイを介してどこと通信しているかを調査します。 下記のクエリでは、特定の日付でNATゲートウェイを介した通信回数を通信元と通信先のIPで集計しています。 SELECT pkt_srcaddr, srcaddr, dstaddr, pkt_dstaddr, dstport, pkt_dst_aws_service, COUNT ( 1 ) AS c FROM vpc_flow_logs WHERE srcaddr LIKE 'x.x.%' -- VPC CIDR AND dstaddr IN ( 'y.y.y.y' , 'z.z.z.z' ) -- NAT Gateway IP AND dt = '20YY-MM-DD' GROUP BY pkt_srcaddr, srcaddr, dstaddr, pkt_dstaddr, dstport, pkt_dst_aws_service ORDER BY c DESC ; すると以下のような結果が返ってきます。（もちろんダミーデータです。） # pkt_srcaddr srcaddr dstaddr pkt_dstaddr dstport pkt_dst_aws_service c 1 x.x.a.a x.x.a.a y.y.y.y a.a.a.a 443 EC2 1600 2 x.x.b.b x.x.b.b z.z.z.z b.b.b.b 443 AMAZON 1500 3 x.x.c.c x.x.c.c y.y.y.y c.c.c.c 443 - 700 4 x.x.d.d x.x.d.d y.y.y.y d.d.d.d 443 - 400 通信先のAWSサービスを特定 通信先がAWSサービスの場合は、 pkt_dst_aws_service を確認することで対象を特定することができます。 フローログに記載される pkt-src-aws-service と pkt-dst-aws-service は EC2 のように具体的なAWSサービスが記載されていることもあれば、 AMAZON のようにどのエンドポイントと通信しているかわからない場合もあります。そのような場合は、AWS Route53 リゾルバーのクエリログ記録を確認することで特定できたりします。 参考: リゾルバーでのクエリのログ記録 また、EC2ダッシュボードから確認できるネットワークインターフェース一覧からパブリックIPで検索することで通信先のリソースを特定することも可能です。 通信先のAWS以外のサービスを特定 基本的にIPアドレスからどのサービスなのかを完全に特定することはできません。 逆引きDNS（PTRレコード）が設定されている場合は dig を使ったり whois でIP所有者の特定はできるかもしれませんが、外部サービスがIPアドレスの範囲を公開していなければどのサービスかを絞り込むのは難しいです。 では、AWS以外のサービスをどのように特定すれば良いでしょうか？ A. 「特定のIPアドレスへの通信を遮断すれば、システムアラートからどのサービスとの通信が確立できなかったか確認できるのでは？」 以下のような仕組みを考えてみました。 CLINICS APIが外部サービス（IPがx.x.x.x）へリクエストを送信する 特定のIPアドレスへの通信を遮断する 外部サービスへのリクエストがタイムアウトすることでアラートが発報される 筋が良くはないかもしれませんがやってみました。冒頭にも記載しましたが、本番環境での実施は控えてください。 特定のIPアドレスへの通信を遮断する方法 特定のIPアドレスへの通信を遮断する手段として「ネットワークアクセスコントロールリスト（ネットワークACL）」があります。 ネットワークACLはサブネットレベルで特定のトラフィックを許可/拒否することができる仕組みです。 参考： ネットワークアクセスコントロールリストを使用して、サブネットのトラフィックを制御する 実際にネットワークACLを作成してみます。 先ほど実行したクエリ結果をもとにブロックしたいIPアドレスをアウトバウンドルールを設定していきます。 作成したネットワークACLをプライベートサブネットに関連付ければ、NATゲートウェイを介した通信が遮断されるようになります。 全てのIPアドレスをしらみつぶしに検証していくとキリがないので、トラフィックが特に多いものに絞って調査を進めました。 調査結果 上述した方法を用いて、NATゲートウェイを介して通信する外部サービスの特定ができました。 特にトラフィック量が多く、NATゲートウェイを経由しなくても良いサービスは以下のようになりました。 Amazon Kinesis Datadog NATゲートウェイを通らないアーキテクチャへ変更 ここからは、NATゲートウェイ経由で通信していたトラフィックをVPCエンドポイントへ逃していきます。 NATゲートウェイとVPCエンドポイントどちらを採用するかを検討する場合、損益分岐点を計算する必要がありますが本記事では割愛します。 Amazon Kinesis Amazon Kinesis はインターフェイスVPCエンドポイントがサポートされているため、VPCエンドポイントを作成して向き先を変えてあげます。 参考: AWS のサービス と統合する AWS PrivateLink Datadog DatadogはPrivateLinkを提供しているため、これを採用します。 参考: AWS PrivateLink を介して Datadog に接続する 後になって知りましたが、DatadogさんはIPアドレスの範囲を公開されていたんですね。 以下から確認できました。 curl -X GET "https://ip-ranges.datadoghq.com/" -H "Accept: application/json" 参考: IP 範囲 効果検証 VPCエンドポイントやPrivateLinkへの移行が完了した後、実際にNATゲートウェイを経由するトラフィック量が削減されたかを確認しました。 NATゲートウェイ経由のトラフィック削減 VPCエンドポイントやPrivateLinkへの移行後、NATゲートウェイを経由するトラフィック量が大幅に削減されました。 VPCエンドポイントへトラフィックが流れた後のNATゲートウェイの送信先へのバイト数の変化 具体的には、移行前と比較して以下のような結果が得られました。 送信パケット数の削減 : NATゲートウェイを経由するパケット数が約50%削減 データ量の削減 : NATゲートウェイを経由するデータ量が約82%削減 まとめ 本記事では、VPCフローログとAmazon Athenaを用いてNATゲートウェイを経由する通信内容を分析し、ネットワークACLを活用した力技で通信先のサービスを特定する方法を紹介しました。 調査の結果、NATゲートウェイを経由する主な通信先としてAmazon KinesisとDatadogが特定できました。これらをVPCエンドポイントやPrivateLinkに移行することで、NATゲートウェイを経由するトラフィック量を削減することができました。 NATゲートウェイのポート割り当てエラーなどのリスクを事前に回避するためには、定期的に通信内容を見直し、可能な限りVPCエンドポイントやPrivateLinkを活用したアーキテクチャに最適化していくことが重要です。 ただし、VPCエンドポイントやPrivateLinkを導入することでかえってインフラコストが増加する可能性もあるため、アーキテクチャの最適化によるリスク低減とインフラコストのバランスを慎重に検討する必要があります。 本記事が、同様の課題に取り組む方々の参考になれば幸いです。 We’re hiring! メドレーでは、SREをはじめ「医療ヘルスケアの未来」を共に創っていくエンジニアを大募集中です！少しでもご興味をお持ちいただけましたらぜひ、ご応募お待ちしております！ 株式会社メドレー エンジニア の求人一覧 株式会社メドレー エンジニア の求人一覧です。| HRMOS hrmos.co ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

こんにちは、人材プラットフォーム本部CTO室の奥澤です。株式会社メドレーの人材プラットフォーム本部では現在、Flutterを用いて複数のモバイルアプリを開発しています。Flutterに興味を持つメンバーが増え、注目度も高まっています 2025年11月13日、日本最大級のカンファレンス「 FlutterKaigi 2025 」が開催されました。 FlutterKaigi は有志により開催され、メドレーからも複数のメンバーが参加しています。メドレーでは、Bronzeスポンサーとして協賛しており、技術カンファレンスへ継続的に協賛を通じて、技術コミュニティの支援を行っています。 本記事では、FlutterKaigi 2025への参加レポートを報告します。 会場の様子 FlutterKaigi 2025は、大手町プレイス ホール＆カンファレンスで開催されました。会場に着くと、巨大な Dashちゃん に迎えられました。FlutterKaigiを盛り上げるぞという気持ちが高まります。また、写真では小さいですが、このボードにはBronzeスポンサーとしてメドレーの社名も出ています。 会場の2階には、メッセージボードも設置されていました。遠方から参加された方のコメントも多数残されていました。見知らぬ参加者同士でコミュニケーションできるのは良いですね。 また会場では、スポンサーブースをまわってスタンプを集めるスタンプラリーが開催されていました。自分も各社のブースをまわり、技術、プロダクト、開発体制などの話を聞かせていただきました。いくつかのブースではかなり長い時間にわたって情報交換させていただき、とても有益な時間になりました。スタンプを集めて引けるクジでは当たりを引き、Dashちゃんのぬいぐるみをいただきました。宝物にします。 セッションの紹介 印象に残ったセッションを紹介します。 Flutterにしてよかった？ 出前館アプリを2年運用して気づいたこと全部話します 出前館には複数のモバイルアプリがあり、2年前にそのすべてをFlutterに統一したとのこと。それからの2年間で遭遇した技術面・運用面での課題とその課題をどう解消したのかを発表されていました。 まず、2年前まではReact NativeのCode Pushを利用してアプリを配信していたが、Flutterへの移行に伴い2週間のリリーストレインで運用するようになった、という話がありました。モバイルアプリにおけるリリーストレインの事例自体は多いと思いますが、フレームワークの移行に伴ってリリースフローも変更したという話は興味深く聞きました。「ユーザーに素早く価値を提供すること」を起点にリリースフローを再定義されていた点は素晴らしいなと感じました。 次に、Flutter Webを活用して開発中のフィードバックを受けるようにした、という話も良かったです。Flutterで開発しているモバイルアプリを、開発中のフィードバックを得るために社内に向けてWeb版で提供するようにした、とのことです。開発中のアプリをモバイル端末で動かしてもらってフィードバックを受ける、というのは実は心理的な障壁が高く、Web版を動かしてもらってフィードバックを受ける方が心理的障壁が低くフィードバックが集まりやすい…という点は驚きでした。Flutterを使って開発しているからこそ実現できた活用事例でした。 顧客価値を実現するFlutter：KPI・SLOから考えるキャリア支援アプリのUIUX設計 顧客価値を実現するためにFlutterをどう活用しているか？について実践してきた内容を発表されていました。提供したい顧客価値を定義し、重要指標を特定し、Flutterを用いて重要指標をどうやって改善するか、という事例の話でした。例えば以下のような事例です。 入力内容の即時ローカル保存によってフォーム入力における離脱率の指標を改善した UIを楽観的更新することによって体感レイテンシの指標を改善した 発表されていた内容は、顧客価値を実現するためにモバイルアプリエンジニアから提案できるものだと思います。こういった取り組みについては、他社の具体的な事例を知る機会はなかなかないため、ありがたい発表でした。 アクセシビリティ、まだ完璧じゃないけど ── “今から”できること アクセシビリティは重要な品質特性のひとつですが、モバイルアプリにおけるアクセシビリティへの取り組みはまだまだ発展途上にあると思います。しかしながら、カンファレンスでのアクセシビリティに関するセッションも増えつつあり、本セッションもそのひとつです。本セッションでは、Flutterにおけるアクセシビリティの基本や遭遇したトラブルについて発表されていました。 まず、Flutterにおけるアクセシビリティ対応ではSemantics Widgetを利用することが重要である、という説明がありました。その上で、Semantics Widgetの基本的な使い方の説明がありました。またこれまで遭遇したトラブルとしていくつかの事例が共有され、例えば標準WidgetではなくGestureDetectorを使用して実装した場合にスクリーンリーダーが適切に読み上げできない事例などが共有されました。 Flutterにおけるアクセシビリティの実装を再確認できたと共に、どのような場合に適切な読み上げができなくなってしまうのかを認識できました。非常に実用的な、有益なセッションでした。 最後に メドレーの人材プラットフォーム本部では、Flutterエンジニアを積極採用中です。Flutterを活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひカジュアル面談にお越しください！ hrmos.co hrmos.co

こんにちは、人材プラットフォーム本部CTO室の奥澤です。株式会社メドレーの人材プラットフォーム本部では現在、Flutterを用いて複数のモバイルアプリを開発しています。Flutterに興味を持つメンバーが増え、注目度も高まっています 2025年11月13日、日本最大級のカンファレンス「 FlutterKaigi 2025 」が開催されました。 FlutterKaigi は有志により開催され、メドレーからも複数のメンバーが参加しています。メドレーでは、Bronzeスポンサーとして協賛しており、技術カンファレンスへ継続的に協賛を通じて、技術コミュニティの支援を行っています。 本記事では、FlutterKaigi 2025への参加レポートを報告します。 会場の様子 FlutterKaigi 2025は、大手町プレイス ホール＆カンファレンスで開催されました。会場に着くと、巨大な Dashちゃん に迎えられました。FlutterKaigiを盛り上げるぞという気持ちが高まります。また、写真では小さいですが、このボードにはBronzeスポンサーとしてメドレーの社名も出ています。 会場の2階には、メッセージボードも設置されていました。遠方から参加された方のコメントも多数残されていました。見知らぬ参加者同士でコミュニケーションできるのは良いですね。 また会場では、スポンサーブースをまわってスタンプを集めるスタンプラリーが開催されていました。自分も各社のブースをまわり、技術、プロダクト、開発体制などの話を聞かせていただきました。いくつかのブースではかなり長い時間にわたって情報交換させていただき、とても有益な時間になりました。スタンプを集めて引けるクジでは当たりを引き、Dashちゃんのぬいぐるみをいただきました。宝物にします。 セッションの紹介 印象に残ったセッションを紹介します。 Flutterにしてよかった？ 出前館アプリを2年運用して気づいたこと全部話します 出前館には複数のモバイルアプリがあり、2年前にそのすべてをFlutterに統一したとのこと。それからの2年間で遭遇した技術面・運用面での課題とその課題をどう解消したのかを発表されていました。 まず、2年前まではReact NativeのCode Pushを利用してアプリを配信していたが、Flutterへの移行に伴い2週間のリリーストレインで運用するようになった、という話がありました。モバイルアプリにおけるリリーストレインの事例自体は多いと思いますが、フレームワークの移行に伴ってリリースフローも変更したという話は興味深く聞きました。「ユーザーに素早く価値を提供すること」を起点にリリースフローを再定義されていた点は素晴らしいなと感じました。 次に、Flutter Webを活用して開発中のフィードバックを受けるようにした、という話も良かったです。Flutterで開発しているモバイルアプリを、開発中のフィードバックを得るために社内に向けてWeb版で提供するようにした、とのことです。開発中のアプリをモバイル端末で動かしてもらってフィードバックを受ける、というのは実は心理的な障壁が高く、Web版を動かしてもらってフィードバックを受ける方が心理的障壁が低くフィードバックが集まりやすい…という点は驚きでした。Flutterを使って開発しているからこそ実現できた活用事例でした。 顧客価値を実現するFlutter：KPI・SLOから考えるキャリア支援アプリのUIUX設計 顧客価値を実現するためにFlutterをどう活用しているか？について実践してきた内容を発表されていました。提供したい顧客価値を定義し、重要指標を特定し、Flutterを用いて重要指標をどうやって改善するか、という事例の話でした。例えば以下のような事例です。 入力内容の即時ローカル保存によってフォーム入力における離脱率の指標を改善した UIを楽観的更新することによって体感レイテンシの指標を改善した 発表されていた内容は、顧客価値を実現するためにモバイルアプリエンジニアから提案できるものだと思います。こういった取り組みについては、他社の具体的な事例を知る機会はなかなかないため、ありがたい発表でした。 アクセシビリティ、まだ完璧じゃないけど ── “今から”できること アクセシビリティは重要な品質特性のひとつですが、モバイルアプリにおけるアクセシビリティへの取り組みはまだまだ発展途上にあると思います。しかしながら、カンファレンスでのアクセシビリティに関するセッションも増えつつあり、本セッションもそのひとつです。本セッションでは、Flutterにおけるアクセシビリティの基本や遭遇したトラブルについて発表されていました。 まず、Flutterにおけるアクセシビリティ対応ではSemantics Widgetを利用することが重要である、という説明がありました。その上で、Semantics Widgetの基本的な使い方の説明がありました。またこれまで遭遇したトラブルとしていくつかの事例が共有され、例えば標準WidgetではなくGestureDetectorを使用して実装した場合にスクリーンリーダーが適切に読み上げできない事例などが共有されました。 Flutterにおけるアクセシビリティの実装を再確認できたと共に、どのような場合に適切な読み上げができなくなってしまうのかを認識できました。非常に実用的な、有益なセッションでした。 最後に メドレーの人材プラットフォーム本部では、Flutterエンジニアを積極採用中です。Flutterを活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひカジュアル面談にお越しください！ Flutterエンジニア／人材プラットフォーム本部 | 株式会社メドレー Flutterエンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co

はじめまして！人材プラットフォーム本部のプラットフォームチームで、プラットフォームエンジニアリングとしてジョブメドレープラットフォームを開発している安藤雄飛と申します。（←プラットフォーム×4がお気に入りの自己紹介） さて今回は、2025年11月6日と7日に島根県松江市の「くにびきメッセ」で開催された Ruby World Conference 2025 に、当社メドレーは Goldスポンサー として参加しました。また、メドレーの歯科診療所事業部長であり、Omotesando.rbのオーガナイザーやRuby関連執筆で活動されている牧さんの講演を聴講しましたので、そのカンファレンスの熱気をお届けします。 カンファレンスのサマリ Rubyコミュニティの懐の深さ : 30年続くRubyのOSSコミュニティは、産学官連携や地域、国際文化交流まで有機的に発展しており、その間口の広さと懐の深さが際立っていました。 エコシステムの進化と拡充 : Rubyで爆速リリースされたプロダクトが急成長し、次のフェーズに進むにあたり、Rubyエコシステムとメソドロジーがさらなる拡充と進化を遂げていること。 オープンな知識共有 : Rubyのオープンなマインドに共感した「つよいRubyist」たちが、成功事例だけでなく、課題や失敗、挑戦を共有することで、コミュニティ全体の一体感と共有資産を生み出していること。 Ruby World Conference 2025会場 会場となった「くにびきメッセ」はJR松江駅から徒歩圏内ながらも、澄んだ少し冷たい風を感じながら大橋川を渡っているうちに、どこか神聖な雰囲気に包まれます。メドレーの松江エンジニアリングオフィス 「Tech Studio MATSUE」 も、このすぐ先にあります。 オープニングセレモニーでは、Rubyの父Matz（まつもとゆきひろ氏）をはじめ、島根県知事、松江市長の挨拶があり、Rubyが地域に深く根付いた文化であることが伝わってきました。 2日間にわたる27の講演・プログラムは、Rubyが様々な分野で活用されていることを示していました。主な活用事例は以下の3点です。 アフリカ東部を中心とした銀行口座を持たない14億人に向けて、金融排除問題をオフラインのフィーチャーフォンとRubyで解決したBernard Banta氏（ アフリカRubyコミュニティ 議長）の基調講演をはじめ、東日本大震災から首都圏のガスインフラを守った防災システムや事業継続（BCP）マネジメントシステム、政府案件として複雑な台湾語をRubyで解析するなどの 「喫緊の社会イシューをRubyで解決」 した事例 PicoRuby によるマイコンやIoT・ビジュアルアートのファンダムや、 ruby.wasm を活用した学生向けプログラミングゲームやメタプログラミングRuby問題集、社内のDXやキャリアチェンジにRubyを活用した人材育成、そしてPythonが優勢なAI/機械学習分野におけるRubyの導入事例や機能移植へのモチベートなど 「Rubyの更なる可能性」 を示唆する講演 ビジネスのスケールに伴うシステムと開発組織の拡大、そしてそれに付随する社会的インパクトに対応するための品質とアジリティの両立に 「Rubyのエコシステムとコミュニティを活用したリアーキ戦略」 の紹介 どの講演も自社サービスや担当システムへの愛とRuby愛に溢れるものばかりでした。 歯科医療DXを支えるRuby職人の魂 Day1のトリを務めたメドレー歯科診療所事業部長、牧さんの 「歯科医療DXを支えるRuby - クラウド歯科業務支援システム『DENTIS』の開発事例」 の講演の様子がこちらです。 メドレーのミッション 「医療ヘルスケアの未来をつくる」 と、松江の拠点、そして「MEDLEY AI CLOUD」による未来の医療体験の紹介の後、牧部長が牽引するクラウド歯科業務支援システム 「DENTIS」 のデモが披露されました。 単なるサービス紹介に留まらず、歯科医療というドメインの持つ難しさが会場に伝わりました。そして牧さんは、その複雑さを以下の3点にまとめました。 医療会計の難しさ 保険診療の難しさ 歯科特有の情報処理 具体的な事例を用いたエッジケースや計算ツリーの複雑さの説明では、指数的なカバレッジの増加や、2年に1度見直しが入る診療報酬の改定と、その施行までの期間のタイトさ（本当に開発者にとっては驚くほど短期間です）がとても印象的でした。 そして、保険点数と医療費（月の算定エラーやアラートを含む）のメインロジックをActive Recordのコールバックから interactor gem にリプレースすることと、予約システムデータ連携と電子カルテ・レセコンエンジン部を分離し、独立してスケールできるようなアーキテクチャに進化させ、この複雑なドメインをモデリングするための技術的挑戦を惜しみなく語り、Ruby職人の魂を感じさせました。 最後に、牧さんはこのシステムの「医療・ヘルスケアの未来を作る仲間」を募集していますと締めくくりました。会場にはたくさんのRubyistと学生さんもいましたが、私は、はたしてここまで複雑な事業ドメインを抱えるシステムに対してどれだけのエンジニアがチャレンジしようと思ってくれるのかと一縷の不安がありました。 ところが、質疑応答では、はじめに「大変やりがいのあるシステムだと思います。」と好意的な前置きをした上で「歯科診療のドメイン知識の取得が鍵になると思いますが、どのように解決されていますか？」と質問がありました。 牧さんは、「元々社内に数名の医療ドメインエキスパートがいることや専門家がジョインしていること、エンジニアも厚労省のPDFを読み込んだり勉強会などを通じてキャッチアップしていることにより、社内で情報のインデックス化が進んでいる。」との回答でした。 まとめと、未来を作る仲間へ Rubyが入門のし易さや、開発者体験の良さといった スタートアップ事業における迅速性 のみならず、 ビジネス環境の変革に合わせた柔軟性 や、 システムや組織のスケールの適応性 も兼ね備えている事を再認識した機会でした。特にRubyの 高い生産性 で開発フェーズを圧縮し、結果としてテストに時間を費やせるようになり、金融や防災、医療といった ミッションクリティカルなシステムでも品質を高められる という技術的判断に大きく納得させられました。 さらに、このRubyの発展と進化を支えているのが、このRubyコミュニティです。冒頭申し上げましたとおり、OSSコミュニティとして技術者同士のみならず、産学官、地域・国際文化交流がとても自然な形で融合しており、あらゆる形でコミュニティに参加するギバー達の貢献がエコシステムやナレッジとして、Rubyそのものとそれを使っている多様な企業や機関を通じて人々の幸せに還流されていく様子は、まさにOSSコミュニティの理想形ではないでしょうか。 以上、 Ruby World Conference 2025 のレポートでした！ メドレーでは今後もRubyを含めて様々なOSSコミュニティへの協賛、オーガナイズ、登壇、コントリビュートなどを通じてOSSの発展に寄与してまいります。 そして、私たちと一緒に 「医療・ヘルスケアの未来をつくる仲間」 を大募集しています！メドレーの事業や、OSSを通じた医療DXと医療人材不足解消への挑戦に興味を持たれたエンジニアの方は、ぜひこちら メドレー採用資料 もご覧になってください。 左から安藤、登壇された牧さん、Tech Studio MATSUEの三原さん（積極的にご質問されてました） レセプションで松江の太鼓「鼕（どう）」を体験するMatz氏とBernard Banta氏 レセプション後の流れで自然と2次会にお集まり頂いた、牧さんと親交の深い色々な会社の #rubyfriends の皆さんと記念撮影 メドレー松江エンジニアリングオフィス 「Tech Studio MATSUE」 の皆さんと一緒に We’re hiring! 現在、メドレーでは一緒に働く仲間を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。 カジュアル面談も実施しています！ 株式会社メドレー 求人一覧

はじめまして！人材プラットフォーム本部のプラットフォームチームで、プラットフォームエンジニアリングとしてジョブメドレープラットフォームを開発している安藤雄飛と申します。（←プラットフォーム×4がお気に入りの自己紹介） さて今回は、2025年11月6日と7日に島根県松江市の「くにびきメッセ」で開催された Ruby World Conference 2025 に、当社メドレーは Goldスポンサー として参加しました。また、メドレーの歯科診療所事業部長であり、Omotesando.rbのオーガナイザーやRuby関連執筆で活動されている牧さんの講演を聴講しましたので、そのカンファレンスの熱気をお届けします。 カンファレンスのサマリ Rubyコミュニティの懐の深さ : 30年続くRubyのOSSコミュニティは、産学官連携や地域、国際文化交流まで有機的に発展しており、その間口の広さと懐の深さが際立っていました。 エコシステムの進化と拡充 : Rubyで爆速リリースされたプロダクトが急成長し、次のフェーズに進むにあたり、Rubyエコシステムとメソドロジーがさらなる拡充と進化を遂げていること。 オープンな知識共有 : Rubyのオープンなマインドに共感した「つよいRubyist」たちが、成功事例だけでなく、課題や失敗、挑戦を共有することで、コミュニティ全体の一体感と共有資産を生み出していること。 Ruby World Conference 2025会場 会場となった「くにびきメッセ」はJR松江駅から徒歩圏内ながらも、澄んだ少し冷たい風を感じながら大橋川を渡っているうちに、どこか神聖な雰囲気に包まれます。メドレーの松江エンジニアリングオフィス 「Tech Studio MATSUE」 も、このすぐ先にあります。 オープニングセレモニーでは、Rubyの父Matz（まつもとゆきひろ氏）をはじめ、島根県知事、松江市長の挨拶があり、Rubyが地域に深く根付いた文化であることが伝わってきました。 2日間にわたる27の講演・プログラムは、Rubyが様々な分野で活用されていることを示していました。主な活用事例は以下の3点です。 アフリカ東部を中心とした銀行口座を持たない14億人に向けて、金融排除問題をオフラインのフィーチャーフォンとRubyで解決したBernard Banta氏（ アフリカRubyコミュニティ 議長）の基調講演をはじめ、東日本大震災から首都圏のガスインフラを守った防災システムや事業継続（BCP）マネジメントシステム、政府案件として複雑な台湾語をRubyで解析するなどの 「喫緊の社会イシューをRubyで解決」 した事例 PicoRuby によるマイコンやIoT・ビジュアルアートのファンダムや、 ruby.wasm を活用した学生向けプログラミングゲームやメタプログラミングRuby問題集、社内のDXやキャリアチェンジにRubyを活用した人材育成、そしてPythonが優勢なAI/機械学習分野におけるRubyの導入事例や機能移植へのモチベートなど 「Rubyの更なる可能性」 を示唆する講演 ビジネスのスケールに伴うシステムと開発組織の拡大、そしてそれに付随する社会的インパクトに対応するための品質とアジリティの両立に 「Rubyのエコシステムとコミュニティを活用したリアーキ戦略」 の紹介 どの講演も自社サービスや担当システムへの愛とRuby愛に溢れるものばかりでした。 歯科医療DXを支えるRuby職人の魂 Day1のトリを務めたメドレー歯科診療所事業部長、牧さんの 「歯科医療DXを支えるRuby - クラウド歯科業務支援システム『DENTIS』の開発事例」 の講演の様子がこちらです。 メドレーのミッション 「医療ヘルスケアの未来をつくる」 と、松江の拠点、そして「MEDLEY AI CLOUD」による未来の医療体験の紹介の後、牧部長が牽引するクラウド歯科業務支援システム 「DENTIS」 のデモが披露されました。 単なるサービス紹介に留まらず、歯科医療というドメインの持つ難しさが会場に伝わりました。そして牧さんは、その複雑さを以下の3点にまとめました。 医療会計の難しさ 保険診療の難しさ 歯科特有の情報処理 具体的な事例を用いたエッジケースや計算ツリーの複雑さの説明では、指数的なカバレッジの増加や、2年に1度見直しが入る診療報酬の改定と、その施行までの期間のタイトさ（本当に開発者にとっては驚くほど短期間です）がとても印象的でした。 そして、保険点数と医療費（月の算定エラーやアラートを含む）のメインロジックをActive Recordのコールバックから interactor gem にリプレースすることと、予約システムデータ連携と電子カルテ・レセコンエンジン部を分離し、独立してスケールできるようなアーキテクチャに進化させ、この複雑なドメインをモデリングするための技術的挑戦を惜しみなく語り、Ruby職人の魂を感じさせました。 最後に、牧さんはこのシステムの「医療・ヘルスケアの未来を作る仲間」を募集していますと締めくくりました。会場にはたくさんのRubyistと学生さんもいましたが、私は、はたしてここまで複雑な事業ドメインを抱えるシステムに対してどれだけのエンジニアがチャレンジしようと思ってくれるのかと一縷の不安がありました。 ところが、質疑応答では、はじめに「大変やりがいのあるシステムだと思います。」と好意的な前置きをした上で「歯科診療のドメイン知識の取得が鍵になると思いますが、どのように解決されていますか？」と質問がありました。 牧さんは、「元々社内に数名の医療ドメインエキスパートがいることや専門家がジョインしていること、エンジニアも厚労省のPDFを読み込んだり勉強会などを通じてキャッチアップしていることにより、社内で情報のインデックス化が進んでいる。」との回答でした。 まとめと、未来を作る仲間へ Rubyが入門のし易さや、開発者体験の良さといった スタートアップ事業における迅速性 のみならず、 ビジネス環境の変革に合わせた柔軟性 や、 システムや組織のスケールの適応性 も兼ね備えている事を再認識した機会でした。特にRubyの 高い生産性 で開発フェーズを圧縮し、結果としてテストに時間を費やせるようになり、金融や防災、医療といった ミッションクリティカルなシステムでも品質を高められる という技術的判断に大きく納得させられました。 さらに、このRubyの発展と進化を支えているのが、このRubyコミュニティです。冒頭申し上げましたとおり、OSSコミュニティとして技術者同士のみならず、産学官、地域・国際文化交流がとても自然な形で融合しており、あらゆる形でコミュニティに参加するギバー達の貢献がエコシステムやナレッジとして、Rubyそのものとそれを使っている多様な企業や機関を通じて人々の幸せに還流されていく様子は、まさにOSSコミュニティの理想形ではないでしょうか。 以上、 Ruby World Conference 2025 のレポートでした！ メドレーでは今後もRubyを含めて様々なOSSコミュニティへの協賛、オーガナイズ、登壇、コントリビュートなどを通じてOSSの発展に寄与してまいります。 そして、私たちと一緒に 「医療・ヘルスケアの未来をつくる仲間」 を大募集しています！メドレーの事業や、OSSを通じた医療DXと医療人材不足解消への挑戦に興味を持たれたエンジニアの方は、ぜひこちら メドレー採用資料 もご覧になってください。 左から安藤、登壇された牧さん、Tech Studio MATSUEの三原さん（積極的にご質問されてました） レセプションで松江の太鼓「鼕（どう）」を体験するMatz氏とBernard Banta氏 レセプション後の流れで自然と2次会にお集まり頂いた、牧さんと親交の深い色々な会社の #rubyfriends の皆さんと記念撮影 メドレー松江エンジニアリングオフィス 「Tech Studio MATSUE」 の皆さんと一緒に We’re hiring! 現在、メドレーでは一緒に働く仲間を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。 カジュアル面談も実施しています！ 株式会社メドレー 求人一覧