Product Engineering Conference 2026 について こんにちは！人材プラットフォームエンジニアの山河です。 弊社メドレーは、先日中野セントラルパークで開催された、Product Engineering Conference 2026 にゴールドスポンサーとして協賛しました。 Product Engineering Conference は、今年初めて開催されたカンファレンスです。「職能の壁を越え、プロダクト価値を最大化させるための『技術』と『知恵』を共有し、議論し、高め合う場を作る」を目的としたカンファレンスで、当日はエンジニアをはじめ、PMやデザイナーなど、様々なロールの方が参加していました。 初開催のカンファレンスながら、300名以上の方が参加し、とても賑やかな一日でした！ ジョブボードの様子。様々な企業の方が、ブースの案内やエンジニアの募集案内などを書いていました。 当日の様子 メドレーブース 今回メドレーのブースでは、「複雑度耐性診断」として、課題解決に向かう思考タイプの診断をご用意しました。この診断では、5つの設問に答えることで、どのような考え方のタイプかを診断することができます。また、メドレーの中のどのプロダクトがマッチしそうか、というものも一緒に提示させていただきました。 診断結果の一例です。「安心設計型」の場合はCLINICSがマッチしそう、とさせていただきました！ 当日は60名ほどの方にご参加いただき、最終的にはこのような結果となりました。 半分がロジカル構造化型のジョブメドレーでした！午前中の時点ではジョブメドレーと現場密着型のmelmoが半々であり、午後から安心設計型のCLINICSが増えていくなど、時間による変化も見られて非常に面白かったです。 ご参加いただいた皆様、ありがとうございました！ ノベルティ 診断に参加いただいた皆様には、このようなノベルティの配布も行いました。 今回配布したノベルティです。全部で5種類と、パンフレットをご用意しました。 今回特に人気だったのがエマージェンシーキットでした！コンパクトなポーチの中に、緊急時に必要なものがまとまっているので、とても便利なグッズです。今後のイベントでも配布予定ですので、見かけた際はぜひブースに立ち寄ってくださいね。 登壇セッション AI Transformation in Healthcare Product Development 2026/09/05 開催の Product Engineering Conference2026 での登壇資料です。 登壇者 : 医療プラットフォーム 本部CTO 宍戸展志 イベント URL : https://product-engineering.jp/2026/ speakerdeck.com また、今回のカンファレンスでは、医療プラットフォームのCTO宍戸が「分けた境界を、もう一度超える -医療プロダクト開発組織のAI再編」というタイトルで登壇いたしました。 メドレーの歴史と、その中で変わらない「誰よりも詳しく」「建設的に進める」という価値観に触れながら、弊社でのAI活用の事例や、新職種 「Applied AI Developer」 についての紹介などが行われました。また、AIを活用するために弊社で行なっている基盤の整備や仕組み化についても触れていました。 メドレーのAIに関する取り組みは こちら にも詳細がございますので、併せてご覧いただけると幸いです！ セッション参加 当日は、招待講演・スポンサーセッション合わせて33のセッションが行われました。本ブログでは、そのうちの2つをご紹介します。 営業・CSを「開発の当事者」にする — 少人数チームで複数プロダクトを動かすDev<>Ops連携の方法 このセッションは、Dev側・Ops側からそれぞれ登壇され、2名で発表が行われました。 業務でのAIの活用が進み、職種を越境して業務を行うようになった中で、どのようにそれぞれの職種で行う業務が変わっていったか、そしてどのように協働しているかが紹介されました。また、越境に必要不可欠な、AIを使った開発を安全に行うための工夫もお話しいただきました。 特に、職種の境界は薄くなったが、それぞれが全く同じことをするわけではなく、専門性を持って進めていくべきだ、という主張が非常に良いなと思いました。AIを活用しつつも、それぞれの知識や経験を活かして協力することで、今までより早く良いプロダクトを作成できる、そんな組織を目指していきたいと改めて思いました。 営業・CSを「開発の当事者」にする — 少人数チームで複数プロダクトを動かすDev<>Ops連携の方法 AIで開発スピードがコモディティ化した今、プロダクトの競争力は「どれだけ速く作れるか」から「顧客がお金を払ってでも解決したい課題を、いかにシャープに見極めて作れるか」へ移りつつあります。一方で、現場では「営業・CSから上がる要望をどう開発に活かすか」「作ったものが本当に刺さるのか」が見えづらい、という悩みは少なくないはずです。 estieの私たちが所属する開発チームではPdMを置かず、少人数で複数プロダクトを開発しています。この体制では、Dev（開発）とOps（営業・CS）が同じ目的を共有し、議論を通じて「何を作るか」を決められるかが、プロダクトの価値に直結します。 本セッションでは、営業・CSが「開発の当事者」になるために私たちが設計した仕組みを、明日から取り入れられる粒度で紹介します。一方的な共有で終わらせず議論の時間を明示的に設ける「Dev<>Ops定例」、preview環境とAIで爆速に作ったプロトタイプをその場でOpsに当てる検証、Dev側メンバーの商談同席、CS含めたVoCの棚卸方法、等々。Dev視点では価値がないと思った機能が顧客に刺さったり、Ops視点で難しいと思った要望が実は簡単に作れたり。議論の場だからこそ生まれる発見と、「Devが売上に」「Opsが開発に」コミットする当事者意識がどう育つかを、具体的な運用とともにお話しします。 営業、CSメンバーからも、実際の変化も具体的にお話しします。営業は「言っても変わらない」と諦めていた要望が、商談同席→その場で議論→AIで爆速プロトタイプ→顧客のWOW、を経て「届ければ形になる」へと変わりました。CS側でも、プロセスを通した迅速な開発と早期デリバリによって、顧客との信頼醸成に繋がったり、VoCシートの文言だけでは埋もれていた声が「より温度感が高い課題」「複数顧客に共通する課題」だと判明して優先順位を組み替える、といった発見が生まれています。 こういった発見や変化の積み重ねで、dev、opsともに、要望を集めるだけではなく、顧客課題そのものを見るといった意識に変化しています。 fortee.jp 営業・CSを「開発の当事者」にする ～少人数チームで複数プロダクトを動かすDev<>Ops連携の方法～ AIで開発スピードがコモディティ化した今、プロダクトの競争力は「どれだけ速く作れるか」から「顧客がお金を払ってでも解決したい課題を、いかにシャープに見極めて作れるか」へ移りつつあります。一方で、現場では「営業・CSから上がる要望をどう開発に活かすか」「作ったものが本当に刺さるのか」が見えづらい、という悩… speakerdeck.com AIで実装は速くなった。なのにプロダクトは速くならない。職能の壁を越えて価値のフローを設計する AIを使ってプロダクトを作る時代に、早くならない、と感じる理由や、その対処方法を体系立てて説明されているセッションでした。まず、AIを使って早くなるのは主に「アウトプット」であり、本来見るべき価値が届くまでの時間、すなわち「アウトカム」が期待通り起きるまでが早くなったわけではないという話がありました。また、「アウトプット」も、実際に作業している時間と待ち時間があり、AIで早くなるのは主に作業の時間である、という話がありました。その前提のもとで、何を計測していけば良いか、どう進めていくべきかについて、さまざまな視点での整理が説明されました。 AIで実装は速くなった。なのにプロダクトは速くならない。職能の壁を越えて価値のフローを設計する ■セッション概要 AIは実装の経済を変えました。動くコードを書くコストは下がり続け、エンジニア個人の生産量は確かに増えました。それでも、プロダクトが価値を届ける速度はほとんど変わっていません。増えた生産量はどこに消えているのか。 チームでコミットからリリースまでの時間を計測したことがあります。実作業は全体の10%、残りの90%は判断待ち、レビュー待ち、他チーム待ちでした。この構造のまま実作業をAIで半分にしても、全体は5%しか縮みません。制約は手を動かす速度ではなく、職能の間の合意と判断の待ち時間にあります。 計測には罠もある。生産量やPR数といった測りやすい数字は、AIで伸びます。しかしそれは作った量であって、価値が届いたのではありません。測りやすいものを測ると、速く作れるほど速く、使われない機能が積み上がります。 では「作るべきか」は何を基準に判断するのか。ユーザーは機能を買っているのではなく、片付けたい用事のためにプロダクトを雇っています。作れるものがいくら増えても、ユーザーの用事は増えません。コアだと信じた領域がマネージドサービス数十行に置き換わった誤算も、半年計画の大規模刷新を4ヶ月目にロールバックした失敗も、振り返れば「誰のどの用事を片付けるのか」を問わないまま、作れるものを作っていました。 本セッションでは、この構造を設計し直す方法を話します。価値が届くまでの流れを測って制約の位置を特定する。職能ごとに違う風景を見ているPM・エンジニア・SREの前提を、一枚の絵で揃える。そして機能ではなくユーザーの用事を起点に「作るべきか」「いつやめるか」を判断する。「作れるか」にはAIが答えてくれる。「作るべきか」には誰も代わりに答えてくれない。その判断を計測と用事の理解で支えることが、プロダクトエンジニアの中心的な仕事になると考えています。 ■Learning Outcome 対象: エンジニアを中心に、PM・デザイナー・SREなど、プロダクト開発の意思決定に関わるすべての職種 - AIで実装が速くなってもプロダクトが速くならない、構造的な理由 - 測りやすい生産量ではなく、価値が届くまでの流れを測って制約を見つける方法 - 「作るべきか」「いつやめるか」をユーザーの用事から判断するための基準 fortee.jp AIで実装は速くなった。なのにプロダクトは速くならない。職能の壁を越えて価値のフローを設計する 生成AIによって開発者の指は光の速さで動いている。なのに、リリースは相変わらず「来期のどこか」。 では、犯人は AI なのか？ AI がコードを爆速で吐き出したあと、その成果物が「PdM 待ち」「デザイン待ち」「QA 待ち」「法務待ち」「偉い人の気分待ち」という職能ごとの待合室を巡り、気づいたら実… speakerdeck.com セッションまとめ 全体として、これまで参加したカンファレンス、特に昨年までに開催されたカンファレンスでは「AIでこんなことをやりました！」という紹介が多かった印象ですが、今回のカンファレンスはAIとともにプロダクト開発を進めていくための仕組みや、それに伴うペインの話が多かった印象を受けました。また、これまでとは違い、ほとんどがAIについて触れながらのセッションであるという印象を受けました。人がAIを受け入れて使い始めた時代を強く感じた一日でした。 懇親会 カンファレンスの最後には懇親会も行われました！ 懇親会では、CloudBase様提供のビールで乾杯し、その後は自由に参加者同士で交流を楽しみました。 職種や経歴、年代もバラバラの方の集まりでしたが、セッションの感想から自社の開発体制、今後のプロダクト開発の未来まで、話題が尽きることはありませんでした。2時間半ほどの長い時間でしたが、非常に盛り上がった良い懇親会だったと思います。 おわりに 今回が初開催のProduct Engineering Conference。職種の垣根を越え、さまざまな議論を行うことができたカンファレンスだったのではないでしょうか。運営の皆様、ありがとうございました。 また、改めて、弊社ブースおよびセッションにお越しいただいた皆様にもお礼申し上げます。 弊社は年間を通して様々な技術コミュニティやイベントへ協賛・貢献を行っております。ぜひ今後も様々なイベントでお会いできることを楽しみにしています。 メドレーではエンジニアを積極採用中です！ メドレーではAIをはじめとしたテクノロジーを活用して、医療ヘルスケアの未来をつくるプロダクトを開発しています。エンジニア、デザイナー、PM、様々な職種で募集しておりますので、ご興味のある方はぜひ、カジュアル面談へのお申し込みをお待ちしております！ エンジニア オープンポジション | 株式会社メドレー エンジニア オープンポジション（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co プロダクト企画責任者／人材プラットフォーム本部 | 株式会社メドレー プロダクト企画責任者／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co プロダクトデザイナー／人材プラットフォーム本部 | 株式会社メドレー プロダクトデザイナー／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co Applied AI Developer | 株式会社メドレー Applied AI Developer（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co

こちらの記事は「MEDLEY Summer Tech Blog Relay」の28日目・最終日の記事です。 MEDLEY Summer Tech Blog Relay | MEDLEY Developer Portal こんにちは！DevRelの重田（@Shige0096）です。 メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 7/13(月)〜8/21(金)まで毎日異なるメンバーが... developer.medley.jp みなさん、こんにちは。株式会社メドレー 人材プラットフォーム本部 VPoE の倉林（ @terukura ）です。全社のAI活用を支えるAI基盤開発室の室長も兼務しています。 7月13日から28日間、平日毎日つないできたリレーも今日でゴールとなります。社内の皆さん、完走お疲れ様でした！！ はじめに 先日、社内でこんな光景がありました。 法務のメンバーが Pull Request を出し、AIエージェントがレビューコメントを付け、それを受けて修正がマージされる。 ここまでなら、開発チームの日常です。ただしこのPRの中身はコードではなく、契約書レビューの観点をまとめたskill定義でした。出したのはエンジニアではなく、法務のメンバー本人です。 昨年4月に「メドレーのAI活用戦略：AI for All」という記事を書きました。「全職種が全業務で当たり前にAIを活用する」—当時はまだ宣言に近かったこの言葉が、この1年でどこまで現実になったのか。 メドレーのAI活用戦略：「AI for All」 | MEDLEY Developer Portal メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林(@terukura)です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組ん... developer.medley.jp その答えを一言でいうと、こうなります。 全職種にAIを届けようとした結果、全職種がGitHubを使う会社になってきた。 この記事では、なぜそうなったのか、そしてそれを支えている仕組みの一部を紹介します。 室長を務めているAI基盤開発室は、AI共通基盤の構築、ツールの選定・開発・運用、環境整備といった土台づくりと、それを現場に行き渡らせるAI活用推進（いわゆるAI Enabling）の両方を担っています。基盤は、作るだけでは使われません。作って、届けて、使われるところまでが仕事です。 この1年の活動を貫いていたテーマは、次の3つです。 エージェントが速く、安全に走れる環境（ハーネス）を整える 業務知識（skill）を流通させる 効果を計測し、見える化する この記事では、この3つを軸に振り返ります。 なぜ「全社AIハーネス」が必要になったのか AIエージェントに仕事を任せようとすると、すぐに気づくことがあります。 エージェントには「働く場所」が要る、ということです。 業務の文脈（ルール、過去の判断、ドメイン知識）はどこに置くのか 成果物はどこに出すのか 人間によるレビューと承認はどこで回すのか 改善の履歴はどこに積むのか チャットUIも最近はメモリやプロジェクト機能を備え、「使うほど賢くなる」方向に進化しています。ただ、その蓄積は個人とツールの中に閉じがちです。隣のチームからは発見できず、レビューも履歴も残らず、別のエージェントには持ち運べない。個人の生産性は上がっても、組織の資産にはなりにくいと感じています。 エージェントの実行環境（ハーネス）に必要な要件を並べてみると— エージェントに必要なもの それを満たすもの 文脈の蓄積と版管理 リポジトリ + バージョン管理 成果物の置き場 リポジトリ 人間の承認フロー Pull Request 自動実行 GitHub Actions 作業キュー Issues 並べてみて、気づきました。この要件は、すべてGitHubが満たしています。 新しいAI基盤ツールを探すまでもなく、エンジニアが20年近く使い続けてきた道具が、AI時代の全社ハーネスの要件をそのまま満たしていた。私たちはこの事実を受け入れ、GitHubを軸に全社のハーネスを整えていくことにしました。 エージェントの生産性は、モデルの賢さだけでは決まりません。整備された道路の上でこそ車がスピードを出せるように、同じモデルでも、走る環境—ハーネス—次第で出せる速度と安全性はまるで変わります。私たちがこの1年やってきたのは、この道路を全社に敷くことでした。 部門ごとに .claude/ を持つ 現在のメドレーでは、エンジニア組織の外にも部門ごとのリポジトリがあります。実際の構成の一部を挙げると— legal-compliance/ # 法務・コンプライアンス .claude/skills/ # contract-review(契約レビュー), ops-ringi(稟議)… human-capital/ # 人事 .claude/skills/ # jd-review(求人票レビュー), workflow-review(業務フロー)… corporate-it/ # コーポレートIT .claude/skills/ # support-L1(ヘルプデスク一次対応), isms-take-inventory-github(ISMS棚卸し)… internal-audit/ # 内部監査 .claude/skills/ # draft-jsox-rcm(J-SOX文書ドラフト), review-audit-workpaper(監査調書レビュー)… 契約レビューの観点も、稟議の通し方も、J-SOXの文書化も、部門の業務知識そのものが .claude/ （skillsやCLAUDE.md）としてバージョン管理されていっているのがポイントです。 業務ルールの変更はPRになる。つまりレビューと履歴が残る 新メンバー（人間もAIも）は、リポジトリをcloneすれば部門の文脈を持てる 会議室の空きを探すskillから監査調書レビューまで、粒度の大小を問わず「その部門のやり方」が形式知になる 集めて、共有して、配布する skillが各部門のリポジトリに散らばると、今度は同じようなskillの乱立や、車輪の再発明が起きます。そこで、収集→共有→配布の3層で流通させる仕組みを作りました。 収集（collect） : 毎日早朝、グループ全org・400超のリポジトリをスキャンして、AI設定ファイルを横断収集。集めたskillは名前・説明・出典リポジトリつきの全社カタログとして自動整理され、日々の差分がSlackに流れる 共有（share） : 良さそうなものは共有リポジトリに持ち寄る。 npx skills add で使いたい人が自分で引いていく、気軽な置き場 配布（marketplace） : 全社標準と判断したものだけを、プラグインとして版管理つきで正式配布。Claude Codeの /plugin install と、非エンジニアが使うClaude Coworkで同一のmarketplaceを共用し、さらにClaude Teamの組織設定で本人が何もしなくても届く 共有と配布の違いは、届け方と責任です。共有は使う人が引く（pull）、配布は全社に押して届ける（push）。持ち寄りの気軽さと標準装備の信頼性は求められるものが違うので、同じ場所に混ぜないようにしています。 私たちの仕組みが少し珍しいのは、「共通リポジトリを用意したので、ここで共有してね」から始めなかったことだと思っています。 skillやルールは、業務のあるところで生まれます。各プロダクトのリポジトリには、そのチームのskill、エージェント向けのルール、CLAUDE.md、カスタムエージェント定義やhooksが既に大量に育っています。多いリポジトリではskillだけで90近く。これを「中央のリポジトリに引っ越して共有してね」と言った瞬間、現場の文脈から切り離されて陳腐化するか、そもそも誰も引っ越しません。 だから順番を逆にしました。skillは現場のリポジトリに置いたまま、収集する側が毎日全部を読みに行く。書き手には何の作業も求めない。良いものはカタログの中から発見され、必要になった段階で初めて共有・配布へ昇格する。中央は「正」ではなく、現場の写像です。 収集は書き手に、配布は使い手に、作業を求めない。 両端がゼロタッチであること が、全社に広げるうえで一番効いたと思います。 この仕組みで見えるようになったskillの数は— 指標 収集開始時（2026-03） 現在（2026-08） スキャン対象リポジトリ 280 445 CLAUDE.md の数 147 370 Claude Skills の数 212 1,221 約5ヶ月でskillは6倍近くに増えました。「発見できる」ようにしただけで、隣の部門のskillを参考に自部門版を作る動きが自然に生まれています。 skillにもテストを書く skillが1,000を超えると、「作ったのに発火しない」「関係ない場面で発火する」が品質問題になります。そこで共有リポジトリのskillにはトリガー評価セットを同梱しています。 should_trigger: true のクエリだけでなく、「このクエリでは発火してはいけない」というネガティブ例も書く。発火しすぎるskillは、発火しないskillと同じくらい有害だからです。 さらに、Claude用に書いたskillがCodexでも機能するかを codex exec でsmoke testする自作evalも運用しています。1つのskillをClaude Code / Cowork / Codexの3つのハーネスに向ける以上、テストもハーネス横断です。 非エンジニアはGitHubを使えるのか 正直に言うと、いまも簡単ではありません。 「コミット」「ブランチ」という語彙の壁 コンフリクトで完全に手が止まる そもそもローカル環境を持っていない 「非エンジニアもPRを出す会社」の先行例といえば、 GitLabのhandbook文化 が有名です。全社員がMerge Requestでハンドブックを直す。ただしあれは、採用からオンボーディングまで長い時間をかけて根付かせた文化があってこそ成立するもので、同じやり方をすぐに真似するのは難しい。私たちが選んだのは、 人がGitに歩み寄るのを待つのではなく、AIとハーネスの側から人に歩み寄るやり方でした 。 それでも前に進めているのは、書く作業の大半をAIエージェントが肩代わりするからです。契約レビューのskillを直したい法務メンバーがAIに「こう直して」と伝えれば、ブランチもコミットもPRもAIが作る。本人に残るのは、Gitの操作スキルではなく「レビューして承認する」ことだけ。PRという承認フローは、むしろ非エンジニアにとって自然だったのです。 そしてもうひとつ大事なのは、 そもそも「GitHubを使えるようになること」を目的にしていなかったことです 。「まずGitを覚えましょう」という研修から入ったわけではありません。非エンジニアの目的はあくまで「AIに仕事を任せること」であり、GitHubはエージェントが働く場所として、その後ろに静かについてきただけです。タイトルの「AIを届けようとしたら、GitHubを使う会社になってきた」は、文字通りこの順番の話です。 全部収集する 〜 それを支えるAI Usage ハーネスが整うと、良いことがあります。全部が見えるようになるのです。 私たちはAI利用の状況を「AI Usage」という内製ダッシュボードに集約しています。収集しているのは— コーディングエージェントのテレメトリ : Claude Code / Claude Cowork / Codex からOpenTelemetryで直接収集 各AIツールのAPI : Cursor、Devin、GitHub Copilot、Claude / OpenAI Platform API 基盤ツールの利用状況 : n8n、Dify LLMアプリの品質データ : Langfuseのtraceと評価スコア 開発成果 : GitHubのPRデータ（Four Keys） 組織データ : 人事データと突合して本部別・職種別の活用率を算出 ちなみに、集めたデータの出口はWebのダッシュボードだけではありません。MCPサーバーとしても提供していて、Claude Codeから「今月の自分のAI利用状況を教えて」と聞けます。 トークン数の「先」まで測る 「誰がどれだけ使ったか」だけなら、各ツールの管理画面でも分かります。本題はその先です。 Skill実行とMCP呼び出しを計測している。どのskillが何回使われたかに加えて、自動発火したのか・明示的に呼ばれたのかまで分かる。skillを作った側が「ちゃんと発火しているか」を検証できる AI利用と開発成果を重ねている。チーム別に、AIトークン投入量とContributorあたりマージPR数をバブルチャートで可視化している AI活用レベルは、聞かずに測る 社員やチームのAI活用度を把握する方法として、アセスメント—自己申告アンケートやスキル検定でレベル分けする—を採る会社は多いと思います。私たちも一度は考えて、やめました。ハーネスが整っていれば、聞かなくても行動ログから算出できるからです。 チームのページを開くと、Skills利用、MCP活用、エージェントへの委任、高度活用メンバーの数といった指標が自動で表示されます。アセスメントとの違いは3つ。回答負荷がゼロであること、常に最新であること、そして申告と実態のズレがないこと。アンケートによる定点観測では、この速度の技術変化には追いつけません。 必要だったのは、常時観測です 。 おわりに 〜 リレーの裏側にあったもの この28日間、メンバーたちはハーネスエンジニアリングから権限設計、LLM API設計、ローカルMLLMまで、それぞれの持ち場の実践を書いてきました（全記事は リレーの紹介記事 からたどれます）。いくつか挙げると— 素晴らしい提案をしよう！君もハーネスエンジニアにならないか？ 生成AIを活用した自動化に必要な権限設計の考え方 LLM API を叩くときに考えること — AIを機能に組み込む前に確認する6つの観点 Jetson Orin Nano Super によるローカルMLLM活用について 個々のメンバーが28日間書いてきた実践の裏には、今回ご紹介させていただいたような計測と推進の仕組みがあります。 「AIでエンジニアリングは不要になる」という言説を見かけますが、私たちの現場で起きているのは逆です。バージョン管理、コードレビュー、CI—エンジニアが20年かけて磨いてきた道具と規律は、AI時代になって初めて「全社の標準装備」になってきています。エンジニアリングは要らなくなるどころか、会社全体の働き方の中心を担いはじめています。非エンジニアがGitHubに来つつあるのは、そこにしかない規律の価値を、AIが翻訳してくれているからです。 「AI for All」と宣言してから1年。全職種がAIを使う会社を目指した私たちは、気づけば全職種がGitHubを使う会社になっていました。AIの民主化とは、実はハーネスの民主化のことだったのかもしれません。 その意味で、私たちはGitHubそのものに賭けているわけではありません。今年6月にはCursorが、エージェント時代を前提に設計したGitフォージ「 Origin 」を発表しました。賭けているのはバージョン管理・レビュー・自動化という「ハーネスの型」であって、Git互換である限り、この記事で書いた仕組みは持ち運べます。次の道路がどこに敷かれるのか、こうした動きにも注目しています。 メドレーは今期、 AX Project を始動しました。「AIを足す」のではなく、 AIを前提に会社をゼロから設計し直す 取り組みです。全部門のワークフローを「人が担う工程」と「AIに任せる工程」に仕分けし、組織構造や要員計画のあり方まで変えていく。全社AI活用の統括責任者としてCAXO（Chief AI Transformation Officer）が置かれ、AI基盤開発室はその直下で、全社の環境と基盤を作る役割を担います。自律型AIを業務やプロダクトに組み込む新職種「 Applied AI Developer 」の新設も、この流れの一部です。 社内で共有されている問いがあります。 今日、AIを取り上げたら会社が回らなくなるか？ 回るなら、それはまだAIを「足している」だけの会社である。 AX Projectは、全社のワークフローを書き出し、skillとして整備するところから始まります。この記事で書いたGitHubハーネスも、skillの流通も、AI Usageも—すべては、この問いに「回らなくなる」と胸を張って答えられる会社になるための土台です。 メドレーでは「医療を人間中心へ」というミッションのもと、一緒にこの仕組みを進化させてくれる仲間を大募集しています。この記事や本リレーの記事にピンときた方、ぜひカジュアルにお話ししましょう！ メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp

こんにちは。 人材プラットフォームジョブメドレープラス開発室長の德永です。 この記事では、人材紹介の業務基盤を TypeScript と CQRS＋イベントソーシングで0から構築し、約4か月で本番リリースするまでを振り返ります。 私は PdM と実装を兼ね、構想の検証から本番稼働、その後の運用まで関わっています。 こちらの記事は「 MEDLEY Summer Tech Blog Relay 」の27日目の記事です。 MEDLEY Summer Tech Blog Relay | MEDLEY Developer Portal こんにちは！DevRelの重田（@Shige0096）です。 メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 7/13(月)〜8/21(金)まで毎日異なるメンバーが... developer.medley.jp 人材紹介サービス「ジョブメドレーエージェント」では、2022年の立ち上げから3年あまり、数千行のスプレッドシートを複数並行で使って業務を回してきました。 システム化の構想を始めたのは2025年12月です。 翌月に内製を決め、2026年4月に業務を切り替えました。 現在も運用しています。 構想から本番リリースまでのおよそ4か月で、約1,200本の PR をマージしています。 アーキテクチャには CQRS とイベントソーシングを選びました。 データを上書きせず、起きた出来事を順に記録していく作り方です。 0→1の立ち上げにしては作り込みすぎではないか。 着手前から何度も議論し、開発中も判断を見直してきました。 リリースから4か月が経ったいま、この事業では過剰な選択ではなかったと考えています。 もちろん、安く作れたわけではありません。 実装量は増え、リリースを優先して負債として残した課題もあります。 それでも、仕様を決めきれないまま開発とデータ移行を並行でき、リリース後の変更にも対応できました。 私たちの条件では、そのためにかけたコストに見合っていました。 スプレッドシートで支えていた業務 ジョブメドレーエージェントは、医療介護求人サイト「ジョブメドレー」を運営するメドレーが、2022年に立ち上げた人材紹介サービスです。 求人サイトが求職者と事業所を直接つなぐのに対し、人材紹介ではキャリアアドバイザーが求職者と面談し、求人を探し、応募から入職まで伴走します。 この業務を支えていたのが、冒頭で触れたスプレッドシート群です。 求職者、面接、顧客、求人、社内の依頼、KPI など、用途ごとにシートが分かれていました。 シートが用途ごとに分かれているため、同じ情報を何度も書き写していました。 求職者にその場で求人を紹介したくても、現在の状況を知るには複数のシートとツールを行き来しなければなりません。 マニュアルはあっても、手順やシートの使い方には人ごとの差が残り、新しいメンバーが業務を覚えるまでにも時間がかかっていました。 実際に使っていた管理シートの一部です。画面下部には、用途別のタブが並んでいます。個人情報にあたる内容はぼかしています。 システム化で解決したかったことは、次の4つです。 情報をひとつにまとめて状況把握を速くしたい 手作業の転記をなくして、担当者の時間を求職者と向き合うことに使いたい 業務の手順を形式知として残し、新しいメンバーがすぐ立ち上がれるようにしたい データを構造化し、AI を業務に組み込める土台を作りたい 目指しているのは、各メンバーが顧客や求職者と向き合う交渉や提案だけに集中できる状態です。 すぐに実現できる状態ではないため、まずは業務をシステムに載せ、日々起きていることを構造化して記録し、分析するところから始めます。 どの課題も、事業が小さいうちは対応を急ぐものではありません。 しかし、扱う職種と人数が増えるほど、影響は大きくなります。 2025年12月、さらなる規模拡大と体制強化を前に、システム導入の起案が出ました。 外部SaaSと内製を比べる 最初から内製を決めていたわけではありません。 人材紹介の業務管理には導入実績の豊富な外部SaaSがあるため、外部SaaSの導入と内製を並行して検討しました。 起案の直後には、最も不確実だった求人検索から検証を始めました。 ジョブメドレーの求人データと OpenSearch を借りると、半日で最初の画面ができました。 事業部にその画面を触ってもらいながらヒアリングを進め、並行して職種ごとの業務フローを文書化し、システム内で完結できる業務の範囲と運用コストを試算しました。 翌月に内製を決めた時点では、比較資料だけでなく、実際に動くシステムも手元にありました。 どの期間と利用者数で比べるかによって、コストの結論は変わりました。 外部SaaSの費用は利用アカウント数に応じて増えますが、内製の構築費は利用者数では増えません。 単年では外部SaaSが安くても、当時見込んでいた利用者の増加を含めて数年で比べると、差は縮まります。 どちらかが明らかに安いとは判断できませんでした。 内製に決めた理由は、社内のデータとのつなぎ方でした。 求人や事業所のデータを、ジョブメドレー側の更新に追従して取り込む必要があります。 さらに、ジョブメドレーに蓄積された求人や応募のデータをリアルタイムでつなぎ、社内で活用できる範囲を広げたいと考えていました。 検討した外部SaaSでは、この連携を運用できませんでした。 CQRS＋イベントソーシングを選んだ理由 起案直後に作った検証用リポジトリでは、CQRS とイベントソーシング（Event Sourcing、以下 ES）を前提にしました。 ドメイン層は関数型 DDD で書いています。 状態を持つオブジェクトに振る舞いを持たせるのではなく、不変なデータと純粋関数を使い、状態遷移をステートマシンとして表す方針です。 ES を選んだ理由のひとつは、テーブル設計を早々に固めたくなかったことです。 現場ではスプレッドシート上の業務が毎週変わり、職種ごとのヒアリングもこれからでした。 この時点で引いた設計が3か月後までそのまま残るとは思えません。 開発中も事業の施策は続くため、システム化を理由に現場の変化を止めてもらうわけにもいきませんでした。 早く決めるほど、決め直す回数も増えます。 かといって、仕様が固まるまで待てば、リリースは遅れます。 実際に業務を整理すると、すでに固まっているものと、使い始めてから決めたいものが混ざっていました。 すでに固まっていたのは、業務で使う言葉です。 キックオフ直後に5人全員で、DDD の設計手法であるイベントストーミングを行いました。 求職者の獲得から初回面談、求人探索と提案、面接と選考、入職と請求までを並べました。 顧客側についても、開拓と契約、求人の掲載と運用、利用停止と解約までを洗い出しました。 法人名の変更や、事業譲渡による運営法人の変更など、頻度は低くても起きると困る流れも付箋にしました。 数時間で出てきたドメインイベントは、およそ100個です。 このときの言葉がすべて残ったわけではなく、開発中に概念ごと捨てたものもあります。 付箋の個別内容ではなく、扱った業務範囲と量を示すための全景です。 画面で何を目立たせるか、何をどう測るかは事情が違いました。 分析やヒアリングだけでは決めきれず、現場で使い始めてから分かることが多い領域です。 この部分まで先に固めて作り直すより、業務上の出来事を先に記録し、表示や集計は後から足せる構造にしたほうが速いと考えました。 この考え方は目新しいものではありません。 リーン開発の7つの原則にも「決定を遅らせる（Defer Commitment）」があります。 Many people like to get tough decisions out of the way, to address risks head-on, to reduce the number of unknowns. However, in the face of uncertainty especially when it is accompanied by complexity, the more successful approach is to tackle tough problems by experimenting with various solutions, leaving critical options open until a decision must be made. — Mary Poppendieck, Tom Poppendieck『Implementing Lean Software Development: From Concept to Cash』（Addison-Wesley, 2006。邦訳は『リーン開発の本質』日経BP） 難しい決定を早く片付け、未知を減らしたくなる。 しかし、不確実さと複雑さが重なる場面では、いくつかの解決策を試しながら、決める必要が生じるまで選択肢を残したほうがよい、という考え方です。 私たちが決定を遅らせたのは、画面での見え方と、業務の測り方です。 この二つを後から変えられるように、イベントを一次記録にするアーキテクチャだけは先に決めました。 CRUD で作り、仕様が変わるたびに migration を書く進め方もあります。 実際、その方法でもリリースはできたと思います。 ただし、状態を上書きする設計では、状態の持ち方を変えると、テーブル定義の変更や過去データの補正が必要になることがあります。 変化の多い立ち上げ期に、この作業を何度も繰り返すことが気になりました。 ES では、「起きた事実」を表すイベントを記録します。 画面や集計が参照するテーブルは、そのイベントから作ります。 書き込みと読み取りでモデルを分ける考え方が CQRS で、読み取り側のテーブルを Read Model、それを作る処理を projector と呼びます。 事実と見え方を分けておけば、表示や集計の仕様が変わっても、記録済みのイベントを書き換える必要はありません。 Read Model は作り直しますが、必要な事実がイベントに含まれていれば、表示や集計の変更を投影側に閉じられます。 イベントストーミングで整理した業務上の事実はイベントへ、使い始めてから決める表示や集計は投影へ置きました。 表示や集計が変わり続ける0→1では、この分離に手間をかける価値があると考えました。 この選択が合うかどうかは、後から決めたいことがどれだけ残っているかで変わります。 表示や集計まで仕様が固まっている場合、固める時間を取れる場合、変更が少ない場合には、最初からテーブルを設計したほうが速いはずです。 TypeScript での実装 実装は TypeScript のモノレポです。 イベントの payload と集約の状態は Zod スキーマを一次情報とし、型はそこから導出します。 以降のコード例は、説明に必要な部分だけを残して簡略化しています。 export const memberRegisteredPayloadSchema = z . object ({ memberId: memberIdSchema , name: z . string (). trim (). min ( 1 ), registeredAt: isoDateTimeSchema , }); export type MemberRegisteredPayload = z . infer < typeof memberRegisteredPayloadSchema >; ドメイン層は、ドメイン駆動設計（DDD）の集約ごとに、 decide と evolve の2つの純粋関数で構成します。 集約とは、一度に整合性を保つ単位です。 decide(command, state) は、現在の状態でコマンドを実行できるか判定し、イベントを返します。 evolve(state, event) は、イベントを状態に適用します。 どちらも DB や時刻に依存しないため、状態遷移のテストは入出力だけで書けます。 この構成は、Decider パターン（ Functional Event Sourcing Decider ）として知られています。 decide の戻り値には Result を使い、失敗時には業務ルールを表す union を返します。 承認を挟む集約の例として、早期離職時の紹介料を扱う返金ケースの型を挙げます。 export type DecideRefundCaseError = | { kind : "refund_case_not_created" } | { kind : "refund_case_closed" } | { kind : "refund_case_cannot_update_while_approval_pending" } | { kind : "refund_case_cannot_update_refund_content_after_content_approval" } | { kind : "refund_case_cannot_update_invoice_before_content_approval" }; API 層はエラーの kind で分岐し、画面に出すメッセージを決められます。 ドメイン層で throw したエラーを、ハンドラが文字列で判別する必要はありません。 集約の状態も、ひとつの大きなオブジェクトに optional な項目を足すのではなく、判別可能な union で表します。 たとえば、「退会済みなのに面談予定が残っている」という矛盾した状態は型の上で作れません。 optional は、それぞれの状態で本当に任意な項目にだけ使います。 export const memberStateSchema = z . discriminatedUnion ( "kind" , [ z . object ({ kind: z . literal ( "initial" ) }), z . object ({ kind: z . literal ( "active" ), memberId: memberIdSchema , interviewScheduledAt: isoDateTimeSchema . optional (), }), z . object ({ kind: z . literal ( "withdrawn" ), memberId: memberIdSchema , withdrawnAt: isoDateTimeSchema , }), ]); export type MemberState = z . infer < typeof memberStateSchema >; API には Hono.js と zod-openapi を使い、リクエストの検証から OpenAPI 契約の生成までをスキーマに寄せています。 フロントエンドは React Router の SPA で、契約から生成したクライアントを使います。 一般的な構成と異なる3つの判断 CQRS＋イベントソーシングでは、イベントストアに追記したイベントを非同期で投影し、Read Model を作る構成をよく見かけます。 私たちの実装は、この構成と3つの点で異なります。 投影を同期にする Read Model への投影は非同期にせず、イベントの追記と同じトランザクションで行っています。 CQRS の解説では、投影を非同期にし、保存直後の画面に少し前の状態が見えることを許容する構成がよく紹介されます。 ただし、CQRS が分けるのは書き込みと読み取りのモデルであって、投影のタイミングではありません。 たとえば .NET の Marten には、投影の実行方式として Inline、Live、Async があります。 Inline を選ぶと、イベントの追記と同じトランザクションで Read Model が更新されます。 非同期投影でも、読み取り側を工夫すれば、保存直後の画面に最新の状態を見せられます。 その場合は、投影の遅延を考慮した画面、遅延の監視、失敗した投影の再試行を最初から用意することになります。 今回ほしかったのはイベントを一次記録にする設計であり、非同期投影によるスケーラビリティではありませんでした。 利用者は社内のオペレーター数十名で、同時に書き込む人数はさらに限られます。 一般公開のサービスとは、想定する負荷が違います。 そこで、初期構成は同期投影にしました。 規模が変われば判断を見直しますが、イベントが一次記録として残っている限り、投影の方式は後から変えられます。 同期投影にも代償はあります。 投影と書き込みが同じトランザクションにいるため、projector に不具合があり、投影に失敗すると、登録や更新そのものも失敗します。 失敗するのは操作した1件で、システム全体が止まるわけではありません。 非同期投影なら書き込みは通り、画面への反映だけが遅れます。 私たちは、誤った表示のまま業務が進むより、その場で操作が失敗して原因を追えるほうが、立ち上げ期には扱いやすいと判断しました。 そのぶん、投影には CI で AST レベルの制約をかけ、projector のテストを書くことも規約にしています。 イベントストアを MySQL のテーブルにする イベントストアには、 EventStoreDB のような専用のミドルウェアではなく、 Aurora MySQL の通常のテーブルを使いました。 agent_events には INSERT しか行わないと決め、追記専用のテーブルとして運用しています。 業務基盤のデータベースは、ジョブメドレーが使っている Aurora クラスタ内に置いています。 新しいデータベース基盤を立てずに済み、バックアップや監視、社内のデータ基盤へ送るパイプラインも共用できます。 同じクラスタを使うため、権限は接続ごとに分けました。 ジョブメドレーのデータはリードレプリカから読むだけで、書き込み権限はありません。 取り込める範囲も権限で絞っています。 業務基盤への書き込みに使う接続は、自分たちの論理データベースの外に出られません。 データベースの配置を決めたあと、イベントストアも MySQL のテーブルにしました。 イベントと Read Model を同じ MySQL トランザクションで更新するため、両方を同じデータベースに置いています。 4か月という期間に、新しいミドルウェアの学習と運用を持ち込まずに済むことも判断材料でした。 export const agentEvents = mysqlTable ( "agent_events" , { eventSeq: bigint ( "event_seq" , { mode: "number" }) . autoincrement (). primaryKey (), streamKey: varchar ( "stream_key" , { length: 255 }). notNull (), streamVersion: int ( "stream_version" ). notNull (), eventType: varchar ( "event_type" , { length: 100 }). notNull (), payload: json ( "payload" ). notNull (), occurredAt: datetime ( "occurred_at" , { fsp: 6 }). notNull (), }, ( t ) => ({ streamVersion: unique ( "uk_stream_version" ) . on ( t . streamKey , t . streamVersion ), })); テーブルをシンプルにしたぶん、イベントの型はドメイン層で厳密にしています。 Zod の enum を一次情報にして、集約ごとに eventType と payload の組み合わせを union で定義します。 export const EventTypeSchema = z . enum ([ ` ${ EVENT_TYPE_PREFIX } .introduction.refund-case-created.v1` , ` ${ EVENT_TYPE_PREFIX } .introduction.refund-case-closed.v1` , // ... ]); export type EventType = z . infer < typeof EventTypeSchema >; export type RefundCaseEvent = | ( StoredEventBase & { eventType : typeof EVENT_TYPES . introductionRefundCaseCreated ; payload : RefundCaseCreatedPayload ; }) | ( StoredEventBase & { eventType : typeof EVENT_TYPES . introductionRefundCaseClosed ; payload : RefundCaseClosedPayload ; }); // ... evolve では switch (event.eventType) で分岐し、各 case の中で event.payload の型を絞り込めます。 DB に保存される eventType は文字列ですが、書き込む側と読み出す側は型で制約されています。 ひとつの集約に積まれたイベントの並びをストリームと呼び、 streamKey で識別します。 イベントを追記するときは、ストリームを読み込んだ時点の版に1を足した値を streamVersion に書きます。 同じ集約を並行して更新すると、複合ユニーク制約が後から来た書き込みを弾きます。 専用のイベントストアが expectedVersion で提供する楽観的並行制御を、複合ユニーク制約で実装した形です。 制約が担うのは衝突の検出で、書き込みに成功したイベントは streamVersion によってストリーム内で順序づけられます。 「1トランザクション1集約」を守る限り、集約の不変条件も維持できます。 競合した操作は自動でやり直さず、画面にエラーを返します。 同じ求職者を同時に操作する場面はまれなので、裏で再実行するより、操作した人に競合を伝えることにしました。 専用のイベントストアが持つ機能のうち、必要だったのは追記と競合検出だけでした。 購読や、すべてのイベントを対象にした順序保証は使っていません。 Read Model を再投影するときは、 eventSeq の昇順でイベントを流します。 eventSeq は autoincrement の採番順であり、コミット順とは一致しません。 同じストリームへの並行追記はユニーク制約で競合するため、正常に保存された同一ストリームのイベントでは、 eventSeq と streamVersion の順序が一致します。 いまの projector は集約をまたいだ順序に依存しないので、この方法で足りています。 将来、非同期投影へ移す場合は、採番済みで未コミットのイベントを飛ばして読む可能性があるため、順序の追い方から見直す必要があります。 スナップショットを作らない スナップショットを作らないと積極的に決めたわけではありません。 まだ必要になる規模に達していないだけです。 ストリームが長くなると再生に時間がかかるため、途中の状態を保存し、そこから後のイベントだけを読むのが一般的です。 私たちは decide のたびに、そのストリームのイベントを最初から読み直しています。 ひとつの求職者や契約に積まれるイベントはまだ少なく、現状の再生時間で問題ありません。 必要になった時点で追加するつもりです。 移行専用イベントでデータ移行を先に進める ES を前提にしたことは、データ移行で役に立ちました。 一般的なデータ移行では、先に移行先のスキーマを固め、旧データを新しい構造へ変換します。 今回は、移行先であるシステムの仕様自体が、事業部へのヒアリングと並行して変わっていました。 理想のデータ構造が固まるまで待っていると、データ移行がリリースのクリティカルパスになります。 早くリリースしたかったのは、日程だけが理由ではありません。 イベントは、システムが使われ始めてから蓄積されます。 理想形まで仕上げてから出すより、現場が使える状態を早く作り、業務上の事実を記録し始めたいと考えていました。 蓄積を早く始めるほど、後から追加する集計や施策で参照できる期間も長くなります。 そこで、スプレッドシートの1行をほぼそのまま payload へ写し取る、移行専用のイベント型を定義しました。 移行イベントには「移行時点でシートにこう書かれていた」という事実だけを記録します。 アプリケーションの操作や、移行後に目指すデータ構造とは切り離し、移行元の値を Read Model にどう表すかは projector に任せました。 移行元の記録と解釈を分けたため、抽出、クレンジング、投入、検証からなる移行処理を、仕様の確定を待たずに準備できました。 Read Model の仕様が変わっても、projector を直し、移行専用イベントの生成と投入の手順は保てました。 ただし、移行専用イベントは負債として残ります。 ES では過去のイベントを書き換えないため、移行イベントも履歴から消えません。 集約の evolve と Read Model の projector は、通常イベントと移行イベントの両方を解釈し続ける必要があります。 欠損値の扱いなど、移行イベントにしか必要のない分岐も残りました。 機能を追加するたびに、この分岐を考慮する手間がかかり始めています。 将来は、移行イベントを通常イベントの並びへ分解して投入し直し、この分岐をなくす計画です。 CRUD との比較 コードを書く作業だけなら、CRUD のほうが速かったはずです。 ES 固有の投影基盤や再生処理を先に用意する必要がなく、集約ひとつあたりのコードも減ります。 ただし、今回想定していた CRUD の構成では、移行先のスキーマを固めてから旧データの変換を準備することになります。 仕様の確定を待つぶん、リリース日までの余裕はさらに少なくなっていたと考えています。 ここで比較しているのは、今回検討した構成です。 CRUD に履歴テーブルや変更データキャプチャ（CDC）を組み合わせれば、保持できる記録は変わります。 比較軸 CRUD CRUD＋履歴・CDC ES 初期実装 小さい 履歴基盤が加わる 再生・投影基盤を含み大きい 先に決めるもの 現在状態のスキーマ 残す列、または全変更の取得方法 イベントの境界と payload 残る記録 基本は現在状態 行や列の変更差分 業務上の出来事 後から集計できる範囲 上書き前の状態は復元できない 記録した差分と、列の意味が保たれる範囲 必要な事実がイベントに含まれる範囲 向く条件 仕様と測り方が安定している 必要な履歴を先に設計できる 表示と集計を後から変えたい 人材紹介では、ファネルの通過率やリードタイムが施策の判断材料になります。 その詳しい測り方が決まったのは、リリース後です。 ファネルの到達履歴テーブルはリリースから1か月半後、分析用の Read Model 群は3か月後に作りました。 どちらも過去に遡ってデータが埋まっています。 イベントには、「ステータス列が A から B に変わった」ではなく、「打診を始めた」「面接を希望した」「NG になった」と記録していました。 ファネルの各段階も同じ業務用語で定義されるため、投影を書くときに、行の変更を業務上の出来事へ読み替える必要がありませんでした。 CRUD でも、履歴テーブルを最初から用意すれば同じ分析はできます。 ただし、その場合はどの列の履歴を残すかを先に決めます。 ファネルの到達履歴に何が必要か分かったのはリリース後なので、必要な履歴をリリース前にすべて選ぶのは難しい状況でした。 列を選ばず、すべての変更を記録する方法もあります。 Fivetran のようなツールで CDC を行うか、監査ログを使い、テーブルの全変更を分析基盤へ送る方法です。 集約や decide を実装しないぶん、アプリケーション側は軽くなります。 CDC で残るのは行の差分です。 「いつ NG になったか」のように、ある時点で起きた事実なら、変更履歴から復元できます。 難しくなるのは、業務上の概念自体を作り替えた場合です。 開発中に、求人サイトの「応募」をそのまま持ち込んだ設計を捨て、人材紹介の「紹介」へ一本化したことがありました。 この変更では、同じ列でも前後で意味が異なります。 どの変更が業務上何を意味したのか、別に記録を残して補うこともできます。 ただ、業務上の意味まで別に記録して復元できるようにすると、ES と同じく、記録時の意味を設計して保つコストが生じます。 もちろん、ES でもすべてを後から決められるわけではありません。 イベントの境界と payload に何を含めるかは、記録する時点で決めます。 後から項目を追加しても、過去のイベントにその値は入りません。 今回遅らせられたのは、記録済みの事実から何を表示し、どう集計するかという判断です。 AI エージェントに渡しやすかった実装 ES は実装量の多いアーキテクチャです。 ひとつの機能に、イベント定義、 decide 、 evolve 、projector、テストが必要で、似た構成のファイルが並びます。 一例として、返金ケースの集約は実装コードが2,215行、テストを含めると4,487行になりました。 人材紹介の業務には、契約、承認、解約、返金、ヒアリングなど、似た構造を持つ集約が数多くあります。 最終的に実装した集約は20種です。 投影や再生の共通基盤も、機能開発に先立って用意する必要があります。 この実装量は、ES を採りにくくする理由のひとつでした。 リポジトリを作った週に、コーディング規約とドメインの前提を AI エージェント向けの指示ファイルに書き、CI のガードも整備しました。 各ファイルの責務を狭くし、型と CI で規約違反を検出できるようにしたことで、同じ形の実装を繰り返す部分は AI エージェントに渡せました。 AI エージェントに渡す作業の境界は、CRUD でも作れます。 ES が定めるのはイベントを一次記録にするところまでで、関数の分け方までは決まりません。 私たちは前述の Decider パターンを組み合わせ、業務上の決定を decide 、イベントによる状態遷移を evolve に分けました。 evolve が扱うのは、「このイベントを適用すると状態のどこが変わるか」です。 イベント型を追加したのに evolve の case を書き忘れると、 default 節の never 代入がコンパイルエラーになります。 default : { const unhandled: never = event ; return err ({ kind: "refund_case_unhandled_event" , eventType: String ( unhandled ) }); } decide には業務ルールが集まるため、人が内容を読んで判断します。 同じ集約の中でも、定型的な状態遷移と、業務上の判断を伴う処理を関数単位で分けられました。 CRUD のハンドラでは、AI エージェントに渡す作業の境界があらかじめ引かれているわけではありません。 入力の検証、業務ルールの判定、テーブルの更新をひとつの関数に置くなら、どこまで任せるかを実装ごとに判断する必要があります。 開発の中盤からは、進め方が固まった作業を、AI エージェント向けの手順書（skill）として切り出しました。 集約の実装、イベントのバージョニング、migration の生成、ローカル DB の再構築などです。 リリース時点で62本になりました。 ただし、ガードを用意せずにボイラープレートだけを生成させると、形の整ったコードに概念的な誤りが紛れ込みます。 本格的に作り始める前、アーキテクチャを理解するため、小さなアプリを作っては壊していました。 動くところまではすぐにたどり着くのに、機能を追加すると数日で行き詰まることが何度かありました。 後から確認すると、ドメインの分け方を誤ったまま、ファイルの形だけが揃っていました。 設計判断は ADR（Architecture Decision Record）として残し、リリースまでに57本になりました。 ADR は、AI エージェントに判断の背景を渡せるように整えました。 AI エージェントによって、実装のコストは下がり続けています。 ただし、速く作れるぶん、設計を誤ったときに直すコードも増えます。 作って確かめる開発では、書く速さだけでなく、間違いに気づいたときにどこまで戻るかが進み方を左右します。 事実と見え方を分けたことで、画面や集計に関する変更の多くは projector の書き換えで済みました。 リリース後の評価 2026年4月のリリース当日、最初のチームの業務をスプレッドシートから内製システムへ切り替えました。 切り替え後の1か月は細かなデータ修正が続き、本番の Read Model を3回再投影しました。 それでも業務は止まりませんでした。 記録済みのイベントには手を入れず、projector を直して Read Model を作り直せたためです。 この結果だけを見て、どんな0→1にも CQRS＋イベントソーシングを勧めたいわけではありません。 今回の判断には、少なくとも次の条件がありました。 リリース後も画面や測り方が変わり続ける 業務上の事実を後から何度も参照する 移行元データの品質を事前に読み切れない これらの条件がなければ、もっとシンプルな設計を選んだと思います。 AI を組み込める業務基盤へ このシステムで目指しているのは、事業部のメンバーが顧客や求職者と向き合う交渉や提案だけに集中できる状態です。 業務の流れがシステム上で見えるようになり、事務作業や報告、マネジメントを AI が引き受けられれば、人は求人サイトだけでは代替できない人材紹介の仕事に時間を使えます。 業務プロセスの可視化と AI ネイティブ化は、メドレー全体で進めている方針です。 今回の業務基盤も、人材紹介の領域でその方針を進める取り組みのひとつです。 業務の事実を構造化して記録しておけば、その記録をもとに AI が業務の流れを把握し、判断や実行に関われるようになります。 メドレーでは生成AI利用のガイドラインを社内に展開し、各部門はそのガイドラインに沿って生成AIを利用しています。 MEDLEY Summer Tech Blog Relay 28日目の記事は倉林さんです！ メドレーでは、「医療ヘルスケアの未来をつくる」仲間を募集しています。 少しでも興味をお持ちいただけましたら、ぜひカジュアル面談にお越しください。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp

こちらの記事は「MEDLEY Summer Tech Blog Relay」の17日目の記事です。 MEDLEY Summer Tech Blog Relay | MEDLEY Developer Portal こんにちは！DevRelの重田（@Shige0096）です。 メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 7/13(月)〜8/21(金)まで毎日異なるメンバーが... developer.medley.jp はじめに 株式会社メドレー 人材プラットフォーム本部でエンジニアをしています、佐藤です。 直近の7月にエンドユーザー向けの開発担当チームのリーダーから、プラットフォーム開発担当のチームへリーダーとして異動しました。1ヶ月半ほど経ちましたので、異動後のマインドセットの変化や学びを記載させていただければと思います。 プラットフォームチームについて 弊社人材プラットフォーム本部でのプラットフォームチームでは、開発者体験の向上やプロダクト開発のスピード・品質の持続的な向上を目的とし、現状以下のような取り組みを実施しています。 システムとして必須のサブドメインを共通基盤として切り出し・MSA化 Ruby on Railsをはじめとした利用ライブラリのバージョンアップの仕組み化 CI/CD・監視アラート等の最適化 AIを利用したバグ検出→自動解消の仕組み化 AIでの開発を前提とした開発環境の整備　など ※メドレーでは生成AI利用のガイドラインが社内で展開されており、各部門の業務ではそのガイドラインに沿って利用をしています。 異動前にやっていたこと エンドユーザー向けの開発を行っていたときは、当然ですが担当ドメイン領域においての価値の最大化を目的としていました。PdMと協力しながら、比較的短期のプロジェクトや改善施策を継続的にリリースする体制を作る、という動きです。 品質問題がない状況で、早く出し、早くフィードバックを得て、KPIに対し効果が出ればそのまま継続、悪影響が出たら切り戻し、という形でフィードバックサイクルを高速に回すことを主眼においていました。 いち開発者としてのペインも感じる場面が多かったため、プラットフォームチームへの異動後はそういったものを高速で解消していこうというマインドセットでいました。 異動後の戸惑い 異動後は、チームの現状の取り組みを把握しつつ、以下のような業務を実施していました。 共通基盤への機能追加 既存コードの管理体制とCDの整備 運用業務の定義と対応計画の立案 開発環境の整備 実施する中で、「1〜2日程度で終わると思っていたものが思ったよりかかる」「一つ一つの理解に時間がかかる」といった、自分の中の見込みとのズレを感じるようになり、想定よりスピードが出せないことに焦りと戸惑いを感じていました。 技術スタック自体は異動前と大きく変わっていないのにうまくいかない。この違和感の正体を振り返ると、開発の性質の違いとして以下の2点があったように思います。 実感した違い 1. サービス間の責務を慎重に取り扱う必要がある 異動前は基本的に単一ドメインとそれに紐づくシステムの開発が中心だったため、責務の境界をコードレベル以上に意識することはあまりありませんでした。自分のドメインの中か外かが自明で、外なら別のチームに相談すれば済んだためです。 一方で、共通基盤と各システムをまたぐ開発では、どちらに責務を持たせるべきか、依存はどの程度にとどめるべきかを、こちらが決める側に回ります。 象徴的だったのが、共通基盤側で起きた状態変化を各アプリケーションへ伝える仕組みを検討したときのことです。最初に着手したのは手段の比較でした。 双方向で通信できるようにし、共通基盤側からアプリケーション側のAPIを叩く 共通基盤が非同期のイベントとして流し、アプリケーションが受け取る アプリケーション側でポーリングする などいくつか手段を比較検討し、方式を決めかけていました。 途中で気づいたのは、比較していた案のいくつかが 「共通基盤が各アプリケーションのことを知っている」 形になっていたことでした。基盤側から各アプリケーションへ通信するには、少なくとも宛先のURL・認証情報など、個々のアプリケーションによって変わる情報を基盤が知っている必要があります。 ネットワーク的には、経路を用意すれば双方向の通信自体は実現できます。共通基盤化して間もない時期で、利用するアプリケーションもまだ少ない状況でした。それでもこの形を採らなかったのは、共通基盤は利用する側が増えていく前提のものなので、 利用側が1つ増えるたびに基盤が知るべきことが増える 構造は許容しないほうがよいと判断したためです。 最終的には要件の再定義により、リアルタイム性の要否を再検討した上で、共通基盤側で起きた状態変化をアプリケーション側が特定のトリガーで取得しに行く形に落ち着き、責務も依存もむやみに増やさずに済みました。 ただ、初手で実装の手段検討から入ってしまったぶん、時間のロスは大きかったように思います。 時間のロス以上に気にしていたのは、判断を誤ったまま進めてしまう可能性のほうでした。依存の形は、各アプリケーションがそれに乗ったあとで変えようとすると、相応のコストがかかる可能性が否定できません。誤った判断がそのまま負債として残り得ますし、問題として表面化するのは利用側が増えたあとになりがちです。責務や依存を慎重に取り扱う必要があると感じたのは、この後戻りのしにくさがあるためでした。 2. 「利用者」として理解していたつもりの環境を、「提供者」としては理解できていなかった エンドユーザー向けの開発を行っていた際は、自身が「利用者」として開発環境を利用しており、その特徴は十分に把握しているつもりでした。「提供者」の目線で見ると、まったく足りていませんでした。 開発用のテストデータの修正をメンバーと進めていたときのことです。利用者としては「夜間の複数のデータ処理バッチによって、テストデータが投入されたサンドボックス環境が作られ、始業時には利用可能になる」という理解でした。しかし実際には、環境ごとのデータ反映条件に差分があることが、事前検証で明らかになりました。 提供者としては、そのデータがどのようなワークフローで作られるのか、どの環境には自動で投入されてどの環境には投入されないのか、参照元が環境ごとにどう切り替わるのかまでを把握している必要があります。どこに手を加えるとどこに副作用が出るのかも、そこが分かっていなければ判断できません。これらが十分でなかったため、協業していたメンバーからの問題提起を理解するのに時間を要してしまいました。 利用者としての習熟は、提供者としての理解の代わりにはならない というのが率直な実感でした。「一つ一つの理解に時間がかかる」と感じていた原因の多くは、必要な理解の種類が変わっていたことに気づけなかったことにありました。 この一件をきっかけに、提供側の視点で環境全体のワークフローを把握し直しました。利用者と提供者の違いは、同じプロダクトを触っていても気付きにくいものだと思います。 おわりに 異動前は「早く出して、早くフィードバックを得る」体制を作ることを優先していました。可逆性のあるものは出す、という判断軸で見込みを立てていたということです。 一方で、上記のような経験から、現在は事前の調査・検討・理解にリソースを割いた上で判断することを重視するよう、軸が変わってきています。 今回の異動で2つの立場を経験したことは、開発における判断軸が場所によって変わるものだと知る良い機会になりました。同じようにプラットフォームエンジニアへの転身を控えている方の参考になれば幸いです。 We’re hiring メドレーでは、SREをはじめ「医療ヘルスケアの未来をつくる」ことに取り組むエンジニアを募集しています。ご興味をお持ちいただけましたら、ぜひご応募ください。 ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp MEDLEY Summer Tech Blog Relay 18日目の記事は牧さんです！お楽しみに！！

こちらの記事は「MEDLEY Summer Tech Blog Relay」の20日目の記事です。 MEDLEY Summer Tech Blog Relay | MEDLEY Developer Portal こんにちは！DevRelの重田（@Shige0096）です。 メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 7/13(月)〜8/21(金)まで毎日異なるメンバーが... developer.medley.jp はじめに メドレー 医療プラットフォーム開発室 SREグループに2026年4月に入社した柏木と申します。 これまでの経歴は以下のとおりです。 1社目: 人事給与系企業の子会社に入社し、パッケージソフトウェアの導入設定やビジネスチャットのAndroidアプリ開発などを担当 2社目: メール配信SaaSのインフラ構築から開発、レンタルサーバー事業のエンジニアなどを担当 3社目: メドレー 医療プラットフォーム開発室 SREグループ（現職） このような流れで幅広い技術領域の経験を積んできたエンジニアです。 本記事では、社内向けの業務Webアプリを短期間で開発した経験を通じて、「AIによってWebアプリ開発がどう変わったか」についてお伝えします。 メドレーでは生成AI利用のガイドラインが社内で展開されており、各部門の業務ではそのガイドラインに沿って利用をしています。 何を作ったのか この1〜2週間で、社内業務の運用に必要な一部機能を備えた社内向けWebアプリを開発しました。 なぜ作ったのか（背景） メドレーの医療プラットフォームでは、医療事業者向けに複数のSaaSプロダクトを提供しています。私は社内業務の運用改善にも関わっています。 対象となる管理データは、運用しながら改善を重ねてきました。今後さらに効率的かつ再現性高く管理するため、一部の作業では Claude も活用しながら、データを正規化して仕組みとして管理できる状態を目指すことにしました。こうした課題感から、今回の開発をスタートしました。 「Webアプリ作りが簡単になった」と感じた3つの瞬間 「単なるCRUDのWebアプリならAIを使わずとも簡単に作れるのでは?」と思われるかもしれません。しかし今回は、既存のExcel形式を踏襲したスプレッドシート風の入力画面に加え、コメント機能、バージョン管理、差分比較、さらには管理メニューでの組織ツリー管理など、それなりの規模のアプリケーションになっています。 このアプリを開発する中で、「Webアプリ作りが本当に簡単になった」と確信した瞬間が3回ありました。 1. インフラ構成と要件を少し伝えただけで形になったとき AIに伝えたのは、インフラ構成、使用言語、開発の流れだけでした。文字数にすると、本記事のここまでの文章よりも少ない分量です。 その程度のプロンプトでほぼ全機能のコードが完成したとき、「最小限の知識とプロンプトで、新しいものをゼロから作れる時代になった」と実感しました。 2. Playwrightにテストを任せて、デグレを自動で発見・修正してくれたとき スプレッドシート風の入力画面は、手作業でのテストに非常に手間がかかり、デグレ（意図しない機能の後退や不具合）を見つけるのが困難です。 そこで Playwright によるテストの追加をAIに依頼し、すべてのテストをパスする状態を作りました。すると、次の修正を入れた際にAIがデグレを発見し、自律的に修正まで完了させてくれたのです。 開発の中でもっとも地道で骨の折れる作業が不要になった瞬間でした。 3. MCP（Model Context Protocol）サーバーを活用したとき 一番驚いたのはここです。 初期データの整備では、 MCP（Model Context Protocol） サーバーの機能を追加し、Claude経由で「自然言語による処理内容の設計からシェルスクリプトの作成まで」を行いました。 これが成功したとき、「Webアプリは、データを保持する『箱』と『インターフェース』に過ぎなくなったのだ」と深く納得しました。 なお、AIにデータベースを直接操作させるのではなくシェルスクリプトを出力させたのは、処理内容をコードとして固定化し、実行前にレビューできるようにすることでリスクを抑えるためです。 まとめ 上記の3点を、開発サイクルとして表現すると次のような形です。 この開発サイクルを通して、「業務Webアプリは誰でも簡単に作れる時代になった」ということを実感しました。 この学びから、エンジニアとしての今後の向き合い方は2つあると考えています。 AIを使い倒して開発プロセスを「シフトレフト」するか、AIを圧倒的に上回る専門性を磨くか 自分が作るプロダクトには積極的にAI機能を組み込んでいく AIを機能として組み込んだプロダクト開発ができれば、SaaS企業が提供できる価値はまだまだ広がりますし、AI時代を生き抜くエンジニアになれるはずです。 またどこかで体験談や知見を共有できればと思いますので、ぜひメドレーのDeveloper Portalのフォローをお願いします。 We’re hiring メドレーでは、SREをはじめ「医療ヘルスケアの未来をつくる」ことに取り組むエンジニアを募集しています。ご興味をお持ちいただけましたら、ぜひご応募ください。 ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp MEDLEY Summer Tech Blog Relay 21日目の記事は山本さんです！お楽しみに！！

こちらの記事は「MEDLEY Summer Tech Blog Relay」の6日目の記事です。 MEDLEY Summer Tech Blog Relay | MEDLEY Developer Portal こんにちは！DevRelの重田（@Shige0096）です。 メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 7/13(月)〜8/21(金)まで毎日異なるメンバーが... developer.medley.jp はじめに 医療プラットフォーム本部 プラットフォーム開発室 SRE グループの山田です。医療機関向け SaaS である CLINICS の安定稼働とシステム信頼性の向上に取り組んでいます。 本記事では、CLINICS が長きにわたって使用してきたクライアント認証サーバを OpenResty から Nginx へ移行するに至った経緯について紹介します。 特に実際に直面したビジネス課題や技術選定にフォーカスを当ててお話しします。 なお、本記事の主眼は「OpenResty vs Nginx」のツール比較ではありません。比較検討を進めるなかで「そもそも電子署名が要らないのではないか」という気づきに至り、結果として認証サーバ単体ではなくアーキテクチャ全体を見直すことになりました。本記事ではその評価軸と判断の過程を共有します。 想定読者: 既存システムの技術選定・刷新に取り組むエンジニア 検証環境: AWS (ALB / NLB / NAT Gateway / VPC) を前提 執筆時点: 2026年3月。OpenResty / Nginx のバージョン記述は当時の情報 本記事のポイント 本記事は CLINICS のクライアント認証サーバを OpenResty から Nginx へ移行した事例ですが、話の中心はツール置き換えそのものではなく、「そもそも認証サーバは何を解決しているのか」を問い直した過程にあります。 入口の問い : OpenResty の後継として何を選ぶか 見直した問い : 認証サーバに残すべき役割は本当に何か 辿り着いた答え : 経路をネットワーク層で分離すれば、アプリ層の電子署名は不要となり、認証サーバの役割は mTLS 検証のみに縮む 技術選定の決め手 : 「新規ユーザーがクライアント証明書なしでアクセスできる導線が必要」という CLINICS 固有の仕様が、ALB mTLS ではなく Nginx 単体を選ぶ根拠となった ここに至れた理由をひとことで言えば、「OpenResty の代替を探す」ことをやめて、アーキテクチャの前提そのものを問い直したためです。ツール比較は入口にすぎず、本質は技術スタックの外側 — アーキテクチャの前提とサービスの使われ方 — にありました。 前提: なぜクライアント認証 (mTLS) が必要なのか 本題に入る前に、CLINICS のような医療プロダクトにおいて、なぜクライアント認証 (mTLS) を行う認証サーバが必要なのかを整理します。 CLINICS は医療機関で利用される情報システムであり、厚生労働省「医療情報システムの安全管理に関するガイドライン 第6.0版」(2023年5月) の対象となります。同ガイドラインの システム運用編 [Control] 13. ネットワークに関する安全管理措置 では、オープンなネットワークを介した通信について次のように明記されています ( 厚生労働省 ガイドライン公式ページ )。 ⑥ オープンなネットワークにおいて、IPsec による VPN 接続等を利用せず HTTPS を利用する場合、TLS のプロトコルバージョンを TLS1.3 以上に限定した上で、クライアント証明書を利用した TLS クライアント認証を実施すること。ただしシステム・サービス等の対応が困難な場合には TLS1.2 の設定によることも可能とする。その際、TLS の設定はサーバ/クライアントともに「TLS 暗号設定ガイドライン 3.0.1 版」に規定される最も安全性水準の高い「高セキュリティ型」に準じた適切な設定を行うこと。 — 医療情報システムの安全管理に関するガイドライン 第6.0版 システム運用編 [Control] つまり、CLINICS がオープンなネットワーク経由でクライアントと通信する以上、TLS 1.3 (または高セキュリティ型設定の TLS 1.2) + mTLS はガイドライン上の要請になります。IPA「TLS 暗号設定ガイドライン」の高セキュリティ型については、公式ページ ( IPA 公式ページ ) を参照してください (執筆時点の最新版は第3.1.1版 (2025年4月25日公開)。上記引用文中の「3.0.1 版」は医療情報ガイドライン第6.0版本文の記載に基づきます)。 CLINICS にクライアント認証サーバが存在する根本理由はここにあります。「ベストプラクティスとして導入している」のではなく、医療情報を扱うサービスとして満たすべき要件として、ネットワーク経路上に mTLS 検証を担うコンポーネントが配置されています。 この「mTLS をどこで終端し、誰が検証するか」が、本記事で扱う設計判断の出発点となります。 旧構成と OpenResty 採用の背景 CLINICS のクライアント認証サーバは、約4年にわたって OpenResty で運用されてきました。サービスがスケールアップしていく時期に設計され、その後も大きな改修を加えずに動き続けてきたものです。 なぜ当時 OpenResty が選ばれたのか、要件と設計判断の順に追ってみます。 要件: mTLS によるクライアント認証 前項で述べたとおり、CLINICS がオープンなネットワーク経由でクライアントと通信する以上、医療情報ガイドラインの要請として mTLS の実装が必要です。クライアント認証サーバは、その mTLS 検証を担うコンポーネントとして配置されています。 設計判断: Web サーバの共通化 一方、CLINICS の Web サーバは、性質の異なる複数経路からのリクエストを単一で捌く構成になっていました。ここでいう「複数経路」とは、次の3種類のユーザーからのリクエストです。 社内オペレーター: サポートデスクなど、社内のオペレーション業務を担うユーザー melmo ユーザー: 患者向けアプリ melmo の利用者 医師 / 医療事務 (本記事では「カルテ利用ユーザー」とも表記): CLINICS カルテをご利用いただいている医療機関のユーザー 追加要件: リクエスト経路の識別 Web サーバを共通化した結果、受け取ったリクエストが「どの経路を辿ってきたか」を判定する必要が生まれました。 設計判断: 電子署名によるリクエスト経路の識別 CLINICS ではこの「経路識別」を、クライアント認証サーバが付与する電子署名で実現していました。 つまり、認証サーバは「mTLS の実装」と「リクエスト経路の識別」の2つの要件を同時に満たす必要がありました。特に経路識別を電子署名で実現するには、リクエストの各種情報を Lua スクリプトから Nginx の変数経由で取り出す必要があります。両方を1つの技術スタックで実現できる選択肢として OpenResty を採用していました。当時の要件に対しては、合理的な選択だったと言えます。 ただし、システムは要件と一緒に古びるものです。約4年の間に、サービスのスケール、ユーザー属性の多様化、AWS 側で利用できる機能の進化があり、当初の前提が少しずつズレてきていました。 旧構成で見えてきた2つの課題 長年運用するうちに、構成上の課題が顕在化してきました。 1. NAT Gateway 依存による経路構成の課題 Web サーバの ALB が Internet-facing スキームのため、ドメイン解決ではパブリック IP が返されます。OpenResty から proxy_pass で ALB へリクエストを送る経路は、結果として VPC 外を経由するルーティングとなり、NAT Gateway を必ず通る構成になっていました。 加えて、OpenResty の Docker Hub 上で公開されている公式イメージ ( openresty/openresty ) は執筆時点で 1.29.2.3 (Nginx 1.29.2 ベース) までが公開されており、Nginx 本家で upstream への keep-alive がデフォルト化された 1.29.7 の変更 ( NGINX Community Blog ) を取り込むには、自前で Docker イメージをビルドする必要がありました。proxy_pass の度に新規 TCP セッションが張られるオーバーヘッドも、サービスを提供する上でのパフォーマンス課題の一つでした。 さらに問題なのは、この経路上にいる NAT Gateway が単一障害点として機能してしまうことです。検討当時、AWS の NAT Gateway は AZ 単位 (Zonal) 動作のみで、CLINICS の構成では認証サーバから Web App への経路が単一の NAT Gateway を経由していました (執筆時点では複数 AZ へ自動展開する Regional NAT Gateway も選択肢に加わっています)。これが落ちると、次の2方向が同時に止まります。 インバウンド方向: 認証サーバ → Web App へのリクエスト経路が遮断され、カルテ利用ユーザーのリクエスト受付が停止する アウトバウンド方向: Web App → 外部 SaaS への連携が不能になる 本来であれば、この経路を NAT Gateway のような単一障害点に依存させることは避けたいところでした。 2. 障害発生時の影響範囲の広さ 社内オペレーター / melmo ユーザー / カルテ利用ユーザーが同じ Web サーバを共有しているため、Web サーバで障害が起きると、性質の異なる全ユーザーに同時に影響が波及する構造になっていました。サービスの成長に対して、リスクが線形以上に膨らんでいた状態とも言えます。 解決の方向性 — 経路の分離と VPC 内閉域化 2つの課題を、打ち手に対応させると次のようになります。 NAT Gateway 依存による経路構成の課題 → ALB を Private Subnet に配置し、認証サーバから Web App までの通信を VPC 内に閉じる 障害発生時の影響範囲の広さ → カルテ利用ユーザーの経路を、社内オペレーター・melmo ユーザーの経路から分離する つまり今回の刷新では、「カルテ利用ユーザーの経路を分離し、VPC 内で完結させる」というアーキテクチャの方針が先に決まります。認証サーバをどう作り直すかは、この方針のあとに続く問いです。 分離の帰結 — 電子署名の存在理由が消える 方針が決まったところで、OpenResty が担ってきた役割を分解し直します。 mTLS によるクライアント認証 — 医療情報ガイドラインの要請 電子署名による経路識別 — 単一の Web サーバが全経路を捌くための仕組み 1 は外せない。では 2 はどうか。 電子署名で経路を識別しなければならなかったのは、「社内オペレーター / melmo ユーザー / カルテ利用ユーザーのすべての経路を、単一の Web サーバが捌いている」からです。経路がネットワーク的に区別できないからこそ、アプリ層の電子署名で区別していました。経路をネットワーク層で分けるなら、電子署名そのものが要らなくなります。 これは何かを工夫して削った結果というより、分離という方針の論理的な帰結です。ただし、この帰結が持つ意味は大きく、認証サーバに残る役割は mTLS によるクライアント認証ただ1つになります。「OpenResty の後継に何が必要か」という問いは、この時点で「mTLS だけなら、何で実装するか」という、ずっと小さな問いに変わっています。 検討した選択肢 — mTLS だけなら、何で実装するか 認証サーバに残る役割が mTLS のみに絞れたことで、選択肢は次の2つになります。 選択肢 A: AWS ALB の mTLS 機能 — クライアント認証をマネージド機能で代替し、認証サーバそのものを廃止する 選択肢 B: Nginx 単体 — 認証サーバは残し、Lua スクリプト (OpenResty) を抜いて標準機能のみで再構成する まず魅力的に見えたのは選択肢 A でした。mTLS しか担わないコンポーネントのために、サーバを自前で運用し続ける理由はないかもしれません。運用負荷を下げ、構成も単純にできると考えていました。 選択肢 A: AWS ALB の mTLS 機能 AWS は ALB に mTLS 機能を提供しています ( ALB Mutual TLS 公式ドキュメント )。ALB の mTLS には verify モード と passthrough モード の2つがあり、それぞれ動作と責務範囲が大きく異なります。 A-1. verify モード ALB がクライアント証明書を直接検証するモードです。クライアントが提示した X.509 証明書を、ALB に紐付けた Trust Store の CA 証明書および CRL (失効リスト) と照合し、検証を TLS ハンドシェイク内で完結させます。検証結果は X-Amzn-Mtls-Clientcert-Serial-Number ・ X-Amzn-Mtls-Clientcert-Issuer ・ X-Amzn-Mtls-Clientcert-Subject ・ X-Amzn-Mtls-Clientcert-Validity などのヘッダでバックエンドに渡されます。 検証・失効確認まで ALB に委任できる: Web App 側に証明書処理コードが不要となり、認証関心をネットワーク基盤側に閉じ込められる 検証失敗の負荷がバックエンドに及ばない: ハンドシェイク段階で検証が完結するため、不正な証明書が Web App に到達することがない 証明書を提示しないクライアントは TLS ハンドシェイクが成立しない: これは「不正アクセスを早期に遮断できる」というメリットでもあり、「正当な理由で証明書を持たないクライアント」を一切通せないという制約でもある A-2. passthrough モード 検証ロジックをアプリ側で自由にカスタマイズできる: Subject や Issuer に応じた認可、組織固有のポリシー適用などが、アプリのコードベースで完結する 検証ポリシーをコードでバージョン管理しやすい: Trust Store の更新を ALB の管理画面ではなくデプロイパイプラインで扱える 証明書チェーン検証・失効確認のコストはすべて Web App 側に乗る: 検証ロジックの実装責任に加え、性能チューニング (チェーン検証のキャッシュ、CRL/OCSP の取得経路) も Web App で持つ必要がある セッション再開 (Session Resumption) はサポートされない: AWS 公式ドキュメント上、passthrough と verify の両モードで Session Resumption は無効化される旨が明記されている ( Mutual authentication with TLS - Before you begin ) 選択肢 B: Nginx 単体 電子署名を捨てたあとの認証サーバに必要なのは、TLS の終端、クライアント証明書の検証、バックエンドへの proxy_pass だけです。これらはすべて Nginx の標準機能で完結します。 そもそも OpenResty を採用していた理由は「電子署名のためにリクエスト情報を Lua で柔軟に扱える」ことでした。Lua を使う動機がなくなった以上、本家 Nginx に戻るのが自然な選択肢になります。本家に戻れば、upstream への keep-alive がデフォルト化された 1.29.7 のような、本家のリリースにも直接追従できます。 比較と評価 — ALB mTLS を採用しなかった理由 ALB mTLS は魅力的に見えましたが、CLINICS のアプリケーション仕様と照らし合わせると採用できませんでした。 CLINICS の仕様 — カルテ利用ユーザーでも mTLS なしで通る経路が必要 CLINICS には、カルテ利用ユーザーであっても、新規ユーザーのクライアント証明書発行時はクライアント証明書を持たない状態でサービスにアクセスできる必要があるという仕様があります。 ALB の verify モードを採用すると、証明書を持たないクライアントは TLS 接続自体が確立しないため、ユーザー登録の導線が壊れてしまいます。 この仕様は、QA チームと「現状どんなパターンのアクセスを通しているか」を一緒に棚卸ししたタイミングで整理できたものでした。コードを読んだだけでは見えてこない「使われ方」が、QA チームの実機検証ノウハウから浮き上がってきた形です。「機能要件」ではなく「サービスの使われ方」の文脈で捉え直す必要がありました。 passthrough モードの場合の難点 では passthrough モードはどうか。ALB は証明書チェーンをヘッダで渡すだけなので、実際の mTLS 検証は Web App 側で行うことになります。これは次のような別種のオーバーヘッドを生みます。 認証ロジックを Web App に持ち込むため、認証関心とビジネス関心が混ざる mTLS の検証コスト (証明書チェーンの検証、失効確認) が Web App の応答時間に直接影響する 「認証サーバを廃止して ALB に寄せる」つもりが、結局 Web App 側に複雑性が移るだけの結果となります。 こうして、mTLS の実装は選択肢 B の Nginx に決まりました。方針 (経路の分離と VPC 内閉域化) と技術選定 (Nginx) を合わせた結果が、次の新構成です。 新構成 各コンポーネントの役割と設計意図 NLB (L4 ロードバランサ) NLB は TCP のままパススルーする L4 ロードバランサとして残しました。理由は、TLS 終端を Nginx に置きたかったためです。ALB を最前段に置くと L7 で TLS を終端することになり、mTLS 検証の選択肢は ALB の verify/passthrough モードに限定されてしまいます。NLB を前段にして TCP のまま Nginx に届けることで、TLS の終端と mTLS 検証を Nginx 側で完結できます。 Nginx (TLS 終端 + mTLS 検証) Nginx を TLS 終端の位置に置いた設計意図は次のとおりです。 Web App を TLS 終端にしない: Web App 側に TLS 終端と mTLS 検証ロジックを持たせると、認証関心とビジネス関心が混ざる (ALB passthrough モードで指摘した課題と同じ理由) 認証ロジックを「単一の場所」に閉じ込める: 認証は Web App より手前で完結させ、Web App はビジネスロジックに集中させる OpenResty 時代の Lua スクリプトが不要になる: 経路識別 (= 電子署名) を捨てたことで、Nginx の標準機能のみで構成できる Private Subnet ALB (L7 ルーティング + ヘルスチェック) ALB は Internet-facing から Private Subnet 配置に変更しました。これにより、Nginx から ALB への通信が VPC 内に閉じ、NAT Gateway を経由しなくなります。 ALB を完全に外して Nginx から Web App に直結する案もあり得ましたが、ALB を残したのは次の役割分担を意図したためです。 L7 ルーティング (パスベース・ホストベース) を ALB に任せ、Nginx は認証に集中させる ヘルスチェックとデプロイ時のローテーションを ALB に委ねる Nginx は認証、ALB は配送 — 関心の分離をネットワーク上の役割としても明示する設計としました。 変更がもたらしたもの 整理すると、新構成は次の4点を同時に実現しています。1 と 3 が2つの課題への直接の回答、2 は分離の帰結、4 はその副産物です。 スコープを「カルテ利用ユーザーからのリクエスト」に限定。社内オペレーター・melmo ユーザーは別経路へ分離 経路がネットワーク的に分かれたため、電子署名による経路識別が不要に。OpenResty で Lua を使う動機がなくなり、Nginx 単体で十分な構成に NAT Gateway を経由しなくなり、構成上の単一障害点が消滅 VPC 内閉域通信になったことで、Nginx 1.29.7 のデフォルト upstream keep-alive ( NGINX Community Blog ) の恩恵もそのまま享受できる構成に 移行で苦戦した点 — 「設計図に書かれていない経路」が一番怖い 新構成を絵に描くこと自体は比較的早く終わりました。本当に時間がかかったのは、その後の「現状どう使われているか」の棚卸しです。 CLINICS には、カルテ利用ユーザーであっても、新規ユーザーのクライアント証明書発行時はクライアント証明書を持たない状態でアクセスできる必要があるという仕様があります。 これは設計図ではなく、サービスの使われ方として存在する仕様です。 この経路の存在に気づくことができたのは、QA チームに依頼した E2E テストの結果を確認したときでした。 SRE 側で設計図やコードを追いかけていた段階では拾えなかった仕様が、その資産を通した検証で表に出てきた、というのが正直なところです。机上の設計図だけを追いかけていたら、リリース後に登録導線が壊れていたかもしれません。 ここで大きかったのは、他チームが積み上げてきた資産を、SRE の移行検証としてそのまま活用できたことです。QA チームが整備している E2E テストは、この移行のために作られたものではなく、日常的な品質担保のなかで育ってきたものです。それを移行検証にも転用できるという、チームをまたいで資産にアクセスできる状態が、机上の設計だけでは見えない仕様を移行前に洗い出すセーフティネットになっていました。 加えて、デグレ検証も大きな工数を割いた工程でした。「動いている既存サーバを置き換える」とは、既存のすべての挙動を保証する必要があるということでもあります。本番と等価な振る舞いをするか、QA チームに新環境での機能の総ざらいを依頼して確認しました。SRE 単独で同等の観点をゼロから組み立てようとしていたら、この検証は成立していなかったと思います。 教訓 — ツール比較の前に、役割の分解があった 今回の移行を通じて残った教訓は、次の2つです。 1. 技術選定の前に、役割の分解がある 「OpenResty の移行」として検討を始めると、現行サーバが担っている役割をすべて引き継ぐことが暗黙の前提になります。その前提のままでは、「Lua 相当の柔軟性を持つ後継」を探し続けていたはずです。 実際には、アーキテクチャの前提 — 単一の Web サーバが全経路を捌く — を先に見直したことで、引き継ぐべき役割は mTLS だけに縮みました。そこまで来れば、ツールの比較はほとんど自明です。言い換えると、OpenResty の代替を探すのをやめたら、OpenResty が要らなくなったということです。 「OpenResty vs Nginx」「ALB mTLS を使うか否か」というツールの比較は、入り口にすぎませんでした。本質は「何を解決しているのか」を問い直すことであり、その答えは多くの場合、技術スタックの外側 — アーキテクチャの前提 — にあります。 2. それでも、最後の決め手は「使われ方」 役割を mTLS だけに絞っても、「ALB mTLS か Nginx か」という選択は残りました。これを決めたのは性能でもコストでもなく、「新規ユーザーのクライアント証明書発行時は、証明書なしでアクセスできる必要がある」という仕様でした。そしてこの仕様は、コードや設計ドキュメントではなく、QA チームの実機検証ノウハウのなかにありました。 ALB mTLS は単体で見れば優れた機能ですが、CLINICS の仕様と組み合わせると採用できません。技術選定の良し悪しは、選定対象の優劣ではなく、選定対象とサービス仕様の組み合わせで決まります。 アーキテクチャ刷新における技術選定は、技術的な正しさだけでなく、アプリケーションの仕様やユーザーがどのようにサービスを使っているかを理解した上で行う必要がある。 移行検証の工程も含めて、今回の刷新で最も時間を要したのはこの理解でした。 まとめ CLINICS のクライアント認証サーバを OpenResty から Nginx へ移行した事例を、背景にあるアーキテクチャ見直しの過程とあわせて紹介しました。 旧構成: 単一の Web サーバが全経路を捌くため、アプリ層の電子署名で経路識別 → NAT Gateway 依存による経路構成や障害波及範囲の広さに課題を抱えていた 方針: カルテ利用ユーザーの経路を分離し、VPC 内に閉じる → 分離の帰結として電子署名が不要になり、認証サーバの役割は mTLS のみに縮小 技術選定: ALB mTLS は CLINICS の仕様 (証明書なしで通る導線が必要) と組み合わせると採用できず、Nginx 単体を採用 教訓: ツール比較の前に役割の分解があり、それでも最後の決め手はサービスの使われ方の理解にあった 今回はカルテ利用ユーザーの経路から着手しましたが、社内オペレーター・melmo ユーザーの経路についても同じ考え方で整理を進めていく予定です。 「動いているもの」を変えるのは怖いものですが、設計時の前提が変わったまま放置すると、いつの間にか「動いているだけのもの」になってしまいます。その差分を埋める作業を、これからも続けていきたいと考えています。 We’re hiring メドレーでは、SRE をはじめ「医療ヘルスケアの未来」を共に創っていくエンジニアを募集しています。ご興味をお持ちいただけましたら、ぜひご応募ください。 ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。 メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp MEDLEY Summer Tech Blog Relay 7日目の記事は斎藤さんです！お楽しみに！！

こんにちは！DevRelの重田（ @Shige0096 ）です。 メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 7/13(月)〜8/21(金)まで毎日異なるメンバーが技術やエンジニアリング、個人開発など幅広いテーマでテックブログを公開していきます！ 本記事にて毎日ブログを追記更新していくので、ぜひお楽しみください✨ ※土日祝を除く 👇よろしければ昨年の記事もぜひチェックしてみてください！ MEDLEY Summer Tech Blog Relay | MEDLEY Developer Portal こんにちは！メドレーでDevRelをしている重田です。 今年も暑い日が続いていますがいかがお過ごしですか？ メドレーでは夏企画として『MEDLEY Summer Tech Blog Relay』と題して、ブログリレーを開催します！ 8/2... developer.medley.jp 🌻 ブログリレーカレンダー 🗓️第1週(7/13~7/17) Day1：（仮）🍄（玉井） Day2：Fivetranについて（本多） Day3：TBD（森川） Day4：BigQueryのコスト削減周り（林田） Day5：TBD（宋） 🗓️第2週(7/21~7/24) Day6：FY25 CLINICS大規模障害対応で認証基盤の刷新をした時に得た学びについて（山田） Day7：ローカルLLMの個人での活用について（斎藤） Day8：自作ハーネスとローカルLLMをゴリゴリ（福島） Day9：TBD（稲村） 🗓️第3週(7/27~7/31) Day10：Rubyで組み込み・ゲーム・AIのどれか！（藤原） Day11：TBD（平林） Day12：TBD（高橋） Day13：(仮) AI API 叩くとき考えること（山下） Day14：Jetson Orin Nano Super によるローカルMLLM活用について（山本） 🗓️第4週(8/3~8/7) Day15：Maestro E2E（菅原） Day16：TBD（奥澤） Day17：TBD（佐藤） Day18：TBD（牧） Day19：TBD（久保） 🗓️第5週(8/10~8/14) Day20：TBD（柏木） Day21：TBD（山本） Day22：TBD（村上） Day23：TBD（竹本） 🗓️第6週(8/17~8/21) Day24：TBD（山河） Day25：TBD（亀澤） Day26：TBD（清水） Day27：メドレーにおける0→1開発のリアルな話（エージェント業務システム）（德永） Day28：TBD（倉林） 🍉 We’re hiring! メドレーでは、「医療ヘルスケアの未来をつくる」仲間を大募集しています！ 少しでも興味をお持ちいただけましたら、ぜひ、カジュアル面談にお越しください🙌 ご応募お待ちしております！！ メドレーで働く｜株式会社メドレー メドレーでの働き方や人事制度、求人情報など、採用に関する情報をご紹介します。 www.medley.jp

こんにちは。医療プラットフォーム本部 歯科診療所事業部 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

はじめに こんにちは。医療プラットフォーム本部 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