はじめまして！コーポレート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! 現在、メドレーでは一緒に働く仲間を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。 カジュアル面談も実施しています！ 株式会社メドレー 求人一覧

はじめに こんにちは、人材プラットフォーム本部 プロダクト開発部グループマネージャの松田です。ジョブメドレーアカデミーという オンライン動画研修 ・ 勤怠シフト管理 の開発を行っています。 2025年10月18日(土)、 Hono Conference 2025 に参加してきました。Honoは、Cloudflare Workersなどのエッジ環境で注目を集める超高速・軽量Webフレームワークであり、私たちメドレーでも新規プロダクトの技術スタックとして採用しています。 今回、メドレーはSilver Sponsorとして本カンファレンスに協賛しました。私たちはHonoコミュニティの発展を支援するとともに、自社のエンジニアの城間（ @shiromie ）も登壇し、HonoとAIを組み合わせた開発ワークフローについて発表しました。 本記事では、カンファレンスの熱気ある会場の様子と、 Hono はもちろん、 AI や Bun など、私たちが普段の業務で使用しているテーマを中心に、印象に残ったセッションを技術的な考察と共にご紹介します。 会場の様子 Hono Conference 2025は、docomo R&D OPEN LAB ODAIBAで開催されました。 カンファレンスは、Honoの作者 @yusukebe さんによるオープニングセッションから始まりました。 スライドには「 週200万 / 月800万 」というnpmダウンロード数が映し出され、このフレームワークがいかに注目されているかが分かります。この後のブース巡りや各セッションで、Honoを支えるエコシステムや活用事例を見ていきたいと思います。 今回のイベントでは、多くのノベルティがありました。Cloudflareのオレンジ色の靴下は特に印象的でした。また、Vercelのロゴが入ったステッカーと、クッキーをいただきました。ステッカーも充実しており、Denoのかわいい恐竜のステッカーや、JSP（JavaServer Pages）のロゴがありました。 特に、チームとして普段利用しているBunのステッカー（まんじゅう）も頂けて大満足でした。 セッションのハイライト 私がリアルタイムで聴講したセッションの中で、印象に残ったいくつかのセッションとその感想を紹介します。 Blazing Fast Full Stack Apps with Hono and JSX TwitchやYouTubeで人気のCJ氏( @CodingGarden )による発表です。ハイライトは、 HonoがAPIフレームワークから、柔軟なフルスタックフレームワークへと進化した 点です。 これまではAPI構築がメインでしたが、今回の発表では、Honoが標準でサポートするJSX、CSS in JSのように使えるHono CSS、ReactのSuspenseのように非同期データを扱えるストリーミング機能、そしてuseStateやuseEffectまで備えた軽量なクライアントコンポーネント（JSX DOM）機能がデモされました。 現在HonoをAPIサーバとして利用しているため、今回紹介されたHonoxは、今後の選択肢の一つとして非常に魅力的だと感じました。 CJ氏は人気のテックポッドキャスト『Syntax.fm』のホストとしても知られており、その語り口はさすがで、発表自体もとても丁寧で分かりやすかったです。 Interesting memory leak with Hono on Bun Bun社に所属するSosuke Suzuki氏（ @sosukesuzuki ）のセッションです。私たちのチームでもHono on Bunの組み合わせを採用しているため、メモリリークというテーマはとても楽しみにしていました。 ハイライトは、 Honoのストリーミングヘルパーと、BunのGC（ガベージコレクション）の特性が組み合わさった点 でした。 まず、Honoの処理において、レスポンスとストリームが互いを参照し合う「循環参照」が発生します。Bunが採用するJavaScriptCore（JSC）のGCは、本来これを検知して解放できるはずでした。 しかし、レスポンスからストリームへの参照が『ストロングリファレンス』という特殊な参照として実装されていました。これはGCのルートのように扱われるため、GCは「両方とも到達可能である」と判断してしまいます。その結果、どちらも解放されずにメモリリークを引き起こしていた、という内容でした。 Bunを普段から利用するので、こうしたウィークポイントを具体的に知れたのはとても参考になりました。このセッションを受け、Bun自体のバージョンアップを積極的に追随し、修正を確実に取り込んでいく重要性を再認識しました。 @scalar/hono-api-referenceとMastraでシステム仕様書を自動更新するAIワークフロー構築してみた 続いて、弊社メドレーのエンジニアの城間（ @shiromie ）による登壇セッションです。このセッションでは、私たちが普段の開発で直面している ドキュメントの陳腐化 という課題に対し、HonoとAIを組み合わせてどう解決したかを発表しました。 業務の合間を縫って構築したこのワークフローは、RAG（Bedrock + OpenSearch）とClaudeを活用したものです。特に、AIがハルシネーションを起こさず、事実に基づいた仕様書を書くようチューニングする点が、今回の取り組みにおける技術的なハイライトでした。 この取り組みは、まさに「AIが自動で成果物を作成し、人間がレビューするだけ」という理想を体現しています。具体的には、GitHub ActionsがAPI仕様書（llms.txt）の差分を検知すると、RAGが既存ドキュメントの関連箇所を特定し、Claudeが更新内容を判断してプルリクエストを自動作成します。開発者はそのPRをレビューするだけでドキュメントの鮮度が保たれます。 この取り組みは、AIを使った開発をより一層加速させる発表でした。 Closing - Hono CLI 登場 Hono ConfのClosingで終わったかと思いきや、そこで Hono CLI が世界最速で発表され、まさかの発表に会場は熱狂に包まれました。 コンセプトは「 CLI for Human and AI 」で、Hono自身もAIフレンドリーを意識した進化を遂げていることがわかりますし、ここにいるエンジニア全員が求めていたものでは？と感じました。 AIと開発者のための主要機能 1. AIエージェントの自律性向上 (AI Friendly) AIエージェントがHonoをより深く理解し、扱えるようになります。 hono search AIがドキュメントを自律的に検索し、Markdown形式の仕様を正確に把握します。 hono request サーバーを一切起動せず（ app.request() を直接実行）、型安全なリクエストをテスト実行できます。 2. 革命的な開発体験 (Developer Experience) 開発者のワークフローを根本から変える機能が導入されました。 hono serve --use <middleware> 個人的に衝撃的だった機能の一つです。 コードを一行も変更せず、コマンドラインから直接ミドルウェアを注入（例： --use logger ）できます。 3. 劇的な本番性能の最適化 (Performance) hono optimize アプリのルート情報を事前コンパイルする PreparedRegExpRouter を生成。 これにより、ルーターの 初期化速度が16倍以上高速化 し、バンドルサイズも大幅に削減されます。 Hono CLIを利用することで、開発速度が劇的に加速し、より速くプロダクトの価値を提供できるようになるだろうと感じました。 GitHub - honojs/cli: CLI for Humans and AI with Hono CLI for Humans and AI with Hono. Contribute to honojs/cli development by creating an account on GitHub. github.com 終わりに 2025年10月18日に開催された「Hono Conference 2025」に参加してきました。Honoに関わる企業・人々が一堂に集まるとても学びの多かったカンファレンスでした。 技術的な側面では、Honoが単なる「高速なAPIフレームワーク」から、JSXによるフルスタック開発、そしてHono CLIによる「AIエージェント開発基盤」へと、そのエコシステムを急速に拡大させていることを実感しました。 特に、私たちが実践している「Hono × AI」の取り組みと、コミュニティのAIに対する大きな流れが一致していたことは、大きな自信となりましたし、これからのHonoの進化が楽しみです。 素晴らしい場を創り上げた主催者・スタッフ・登壇者・協賛企業の皆様に深く感謝いたします。 メドレーでは、カンファレンスへのスポンサーの他にも、イベントの開催などを通じて技術とコミュニティへの貢献を続けています。 メドレーではエンジニアを積極採用中です！ メドレーではテクノロジーを活用して、医療ヘルスケアの未来をつくるプロダクトを開発しています。Honoが好きな方はもちろん、バックエンド、フロントエンド、インフラ、モバイルなど、ご自身の専門性を活かして医療ヘルスケア領域の課題解決に取り組みたいという、幅広いエンジニアの方を募集しています。ぜひカジュアル面談にお越しください！ エンジニア／人材プラットフォーム本部 | 株式会社メドレー エンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co テックリード・シニアエンジニア／人材プラットフォーム本部 | 株式会社メドレー テックリード・シニアエンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co 新規事業プロダクトエンジニア／人材プラットフォーム本部 | 株式会社メドレー 新規事業プロダクトエンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co

はじめに こんにちは、人材プラットフォーム本部 プロダクト開発部グループマネージャの松田です。ジョブメドレーアカデミーという オンライン動画研修 ・ 勤怠シフト管理 の開発を行っています。 2025年10月18日(土)、 Hono Conference 2025 に参加してきました。Honoは、Cloudflare Workersなどのエッジ環境で注目を集める超高速・軽量Webフレームワークであり、私たちメドレーでも新規プロダクトの技術スタックとして採用しています。 今回、メドレーはSilver Sponsorとして本カンファレンスに協賛しました。私たちはHonoコミュニティの発展を支援するとともに、自社のエンジニアの城間（ @shiromie ）も登壇し、HonoとAIを組み合わせた開発ワークフローについて発表しました。 本記事では、カンファレンスの熱気ある会場の様子と、 Hono はもちろん、 AI や Bun など、私たちが普段の業務で使用しているテーマを中心に、印象に残ったセッションを技術的な考察と共にご紹介します。 会場の様子 Hono Conference 2025は、docomo R&D OPEN LAB ODAIBAで開催されました。 カンファレンスは、Honoの作者 @yusukebe さんによるオープニングセッションから始まりました。 スライドには「 週200万 / 月800万 」というnpmダウンロード数が映し出され、このフレームワークがいかに注目されているかが分かります。この後のブース巡りや各セッションで、Honoを支えるエコシステムや活用事例を見ていきたいと思います。 今回のイベントでは、多くのノベルティがありました。Cloudflareのオレンジ色の靴下は特に印象的でした。また、Vercelのロゴが入ったステッカーと、クッキーをいただきました。ステッカーも充実しており、Denoのかわいい恐竜のステッカーや、JSP（JavaServer Pages）のロゴがありました。 特に、チームとして普段利用しているBunのステッカー（まんじゅう）も頂けて大満足でした。 セッションのハイライト 私がリアルタイムで聴講したセッションの中で、印象に残ったいくつかのセッションとその感想を紹介します。 Blazing Fast Full Stack Apps with Hono and JSX TwitchやYouTubeで人気のCJ氏( @CodingGarden )による発表です。ハイライトは、 HonoがAPIフレームワークから、柔軟なフルスタックフレームワークへと進化した 点です。 これまではAPI構築がメインでしたが、今回の発表では、Honoが標準でサポートするJSX、CSS in JSのように使えるHono CSS、ReactのSuspenseのように非同期データを扱えるストリーミング機能、そしてuseStateやuseEffectまで備えた軽量なクライアントコンポーネント（JSX DOM）機能がデモされました。 現在HonoをAPIサーバとして利用しているため、今回紹介されたHonoxは、今後の選択肢の一つとして非常に魅力的だと感じました。 CJ氏は人気のテックポッドキャスト『Syntax.fm』のホストとしても知られており、その語り口はさすがで、発表自体もとても丁寧で分かりやすかったです。 Interesting memory leak with Hono on Bun Bun社に所属するSosuke Suzuki氏（ @sosukesuzuki ）のセッションです。私たちのチームでもHono on Bunの組み合わせを採用しているため、メモリリークというテーマはとても楽しみにしていました。 ハイライトは、 Honoのストリーミングヘルパーと、BunのGC（ガベージコレクション）の特性が組み合わさった点 でした。 まず、Honoの処理において、レスポンスとストリームが互いを参照し合う「循環参照」が発生します。Bunが採用するJavaScriptCore（JSC）のGCは、本来これを検知して解放できるはずでした。 しかし、レスポンスからストリームへの参照が『ストロングリファレンス』という特殊な参照として実装されていました。これはGCのルートのように扱われるため、GCは「両方とも到達可能である」と判断してしまいます。その結果、どちらも解放されずにメモリリークを引き起こしていた、という内容でした。 Bunを普段から利用するので、こうしたウィークポイントを具体的に知れたのはとても参考になりました。このセッションを受け、Bun自体のバージョンアップを積極的に追随し、修正を確実に取り込んでいく重要性を再認識しました。 @scalar/hono-api-referenceとMastraでシステム仕様書を自動更新するAIワークフロー構築してみた 続いて、弊社メドレーのエンジニアの城間（ @shiromie ）による登壇セッションです。このセッションでは、私たちが普段の開発で直面している ドキュメントの陳腐化 という課題に対し、HonoとAIを組み合わせてどう解決したかを発表しました。 業務の合間を縫って構築したこのワークフローは、RAG（Bedrock + OpenSearch）とClaudeを活用したものです。特に、AIがハルシネーションを起こさず、事実に基づいた仕様書を書くようチューニングする点が、今回の取り組みにおける技術的なハイライトでした。 この取り組みは、まさに「AIが自動で成果物を作成し、人間がレビューするだけ」という理想を体現しています。具体的には、GitHub ActionsがAPI仕様書（llms.txt）の差分を検知すると、RAGが既存ドキュメントの関連箇所を特定し、Claudeが更新内容を判断してプルリクエストを自動作成します。開発者はそのPRをレビューするだけでドキュメントの鮮度が保たれます。 この取り組みは、AIを使った開発をより一層加速させる発表でした。 Closing - Hono CLI 登場 Hono ConfのClosingで終わったかと思いきや、そこで Hono CLI が世界最速で発表され、まさかの発表に会場は熱狂に包まれました。 コンセプトは「 CLI for Human and AI 」で、Hono自身もAIフレンドリーを意識した進化を遂げていることがわかりますし、ここにいるエンジニア全員が求めていたものでは？と感じました。 AIと開発者のための主要機能 1. AIエージェントの自律性向上 (AI Friendly) AIエージェントがHonoをより深く理解し、扱えるようになります。 hono search AIがドキュメントを自律的に検索し、Markdown形式の仕様を正確に把握します。 hono request サーバーを一切起動せず（ app.request() を直接実行）、型安全なリクエストをテスト実行できます。 2. 革命的な開発体験 (Developer Experience) 開発者のワークフローを根本から変える機能が導入されました。 hono serve --use <middleware> 個人的に衝撃的だった機能の一つです。 コードを一行も変更せず、コマンドラインから直接ミドルウェアを注入（例： --use logger ）できます。 3. 劇的な本番性能の最適化 (Performance) hono optimize アプリのルート情報を事前コンパイルする PreparedRegExpRouter を生成。 これにより、ルーターの 初期化速度が16倍以上高速化 し、バンドルサイズも大幅に削減されます。 Hono CLIを利用することで、開発速度が劇的に加速し、より速くプロダクトの価値を提供できるようになるだろうと感じました。 GitHub - honojs/cli: CLI for Humans and AI with Hono CLI for Humans and AI with Hono. Contribute to honojs/cli development by creating an account on GitHub. github.com 終わりに 2025年10月18日に開催された「Hono Conference 2025」に参加してきました。Honoに関わる企業・人々が一堂に集まるとても学びの多かったカンファレンスでした。 技術的な側面では、Honoが単なる「高速なAPIフレームワーク」から、JSXによるフルスタック開発、そしてHono CLIによる「AIエージェント開発基盤」へと、そのエコシステムを急速に拡大させていることを実感しました。 特に、私たちが実践している「Hono × AI」の取り組みと、コミュニティのAIに対する大きな流れが一致していたことは、大きな自信となりましたし、これからのHonoの進化が楽しみです。 素晴らしい場を創り上げた主催者・スタッフ・登壇者・協賛企業の皆様に深く感謝いたします。 メドレーでは、カンファレンスへのスポンサーの他にも、イベントの開催などを通じて技術とコミュニティへの貢献を続けています。 メドレーではエンジニアを積極採用中です！ メドレーではテクノロジーを活用して、医療ヘルスケアの未来をつくるプロダクトを開発しています。Honoが好きな方はもちろん、バックエンド、フロントエンド、インフラ、モバイルなど、ご自身の専門性を活かして医療ヘルスケア領域の課題解決に取り組みたいという、幅広いエンジニアの方を募集しています。ぜひカジュアル面談にお越しください！ エンジニア／人材プラットフォーム本部 | 株式会社メドレー エンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co テックリード・シニアエンジニア／人材プラットフォーム本部 | 株式会社メドレー テックリード・シニアエンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co 新規事業プロダクトエンジニア／人材プラットフォーム本部 | 株式会社メドレー 新規事業プロダクトエンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co

はじめに こんにちは、医療プラットフォーム本部データ戦略グループの安東です。 以前、私たちは「 データ戦略グループにおけるcontext engineeringの取り組み 」という記事で、LLMに適切なコンテキストを提供することで分析精度を向上させるContext Engineeringの実践について紹介しました。 本記事は、その取り組みをさらに一歩進め、 ビジネスユーザーが日常的に使える分析AIエージェントとして社内リリースした事例 を紹介します。 組織拡大に伴うデータ分析ニーズ増加とアナリスト不足という課題に対し、私たちはContext Engineeringの知見を活かし、 Devin を分析AIエージェントとして活用した分析基盤 を構築しました。 本記事では、 Slackをインターフェースとした分析AIエージェントのアーキテクチャ と、データ戦略グループの具体的な取り組みについて解説します。 分析AIエージェントの全体フロー 分析AIエージェント全体の流れを以下の図で示します。 分析は、次の5つのステップで実行されます。 ① Slackで自然言語で質問 ビジネスユーザー（PdM、Marketing、Sales、CSなど）が、Slackで自然言語により分析を依頼します。 分析依頼の専用フォームを用いることで、分析の目的、対象プロダクト、希望スピードなどを構造化して入力できます。 ② AIエージェントが質問を解釈し、分析設計とツール使用 Devinが中心となり、以下のツールを活用しながら分析を設計・実行します。 MCP Toolbox for Databases: データベースへのアクセス Confluence: 社内ドキュメントの参照 pandas: データ分析とグラフ作成 Playbook/Knowledge: 分析設計とドメイン知識の参照 ③ 分析に必要なKnowledge参照 GitHubに格納されたKnowledgeリポジトリから、必要な情報を取得します。 ビジネスメタデータ: プロダクト固有のビジネスロジックやKPI定義 テクニカルメタデータ: データモデルの構造や分析手法 ④ データの取得 データウェアハウスから分析に必要なデータを取得します。 データはdbtで変換されたmartモデルを中心に、分析パスに応じて最適なレイヤーにアクセスします。 ⑤ Slackで分析結果回答 Slackのスレッドに、以下の形式で分析結果を返却します。 分析の結果・要約 Markdown形式のレポート CSV形式のデータ グラフ（PNG、HTML） 実行したSQLクエリ この一連の流れにより、ビジネスユーザーはSlack内で数分で分析結果を得られます。 データ戦略グループの取り組み データ戦略グループとして、この分析フローを実現するためにどのような工夫を行っているのか、具体的に解説します。 ① Slackインターフェース：ユーザー体験の最適化 なぜSlackなのか ビジネスユーザーにとって、データ分析の障壁は、「そもそも分析を依頼すること自体が難しい」という点にあります。 SQLエディタを開く、分析の設計をする、アナリストに分析依頼することは、多くのビジネスユーザーにとって日常的な行動ではありません。 一方、Slackは多くの組織で既に日常的に使われているツールです。メッセージを送る感覚で分析を依頼できれば、 認知負荷を最小化 できます。 私たちはこの点に着目し、Slackを分析AIエージェントのインターフェースとして選択しました。 フォーム設計による「プロンプトの最適化」 しかし、 Slackで自由フォーマットで依頼を受けると、AIエージェントが意図を正しく汲み取れず分析品質がブレてしまいます。 そこで、 構造化フォームを用いることで、分析に必要な情報を確実に収集し、AIエージェントへの入力を最適化する設計 としました。 従来アプローチ: 自由記述 → AIエージェントが意図を推測 → 品質がブレる 改善アプローチ: 構造化フォーム → 必要情報を確実に収集 → 品質が安定 分析フォームは試行錯誤中ですが、分析設計において重要な情報を必須にしています この設計により、ユーザーは「どんな分析をしてほしいか」を構造的に伝えられるようになり、AIエージェントは迷わず適切な分析パスを選択できます。 Devin Macroの活用 フォーム送信時には、Macroを用いてPlaybookパスを自動選択し、 依頼内容を構造化した形でDevinに渡します 。 これにより、以下のようなワークフローが実現されます。 ユーザーがSlackフォームで依頼を送信 MacroがPlaybookの該当セクションを特定 構造化された依頼 + Playbookパスの情報がDevinに送信 DevinがKnowledge Repositoryを参照しながら分析を実行 工夫のポイントは、自由度と制約のバランス です。 フォームによる構造化は「制約」ですが、その制約がユーザーに適切な依頼方法を示す効果も持ちます。 ② AIエージェント実行：Devinの活用 Devinは、AIエージェントとして分析タスクを自律的に実行します。 Slackから受け取った構造化された依頼に基づき、以下のプロセスで分析を進めます。 自律的な分析タスクの実行 Devinは、単に質問に答えるだけでなく、以下のような複雑なタスクを自律的に遂行します。 タスクの理解とプランニング: 依頼内容を解釈し、必要な分析ステップを計画 ツールの選択と使用: MCPや分析パッケージなど、適切なツールを選択 データアクセス: MCP Serverを通じてデータウェアハウスに接続 分析の実行: SQLクエリの作成、データ加工、グラフ作成 Knowledge Repositoryとの連携 Devinは、分析実行時にGitHubのKnowledge Repositoryを常に参照し、以下の情報に基づいて適切な判断を行います。 Playbook: 分析の作法、コスト最適化、品質ゲート Product Knowledge: プロダクト固有のビジネスロジックとKPI定義 この連携により、Devinは 単なる汎用的なAIエージェントではなく、組織固有の分析ノウハウを持つ専門的なデータアナリストとして機能 します。 ③ Context Engineeringの実践 Prompt Engineeringが「どう尋ねるか」に焦点を当てるのに対し、Context Engineeringは「どんな知識を与えるか」に焦点を当てます。 Knowledge Repositoryの利点は、再現性、保守性、チーム管理のしやすさです。 プロンプトに知識を埋め込むのではなく、外部化された知識リポジトリとして管理することで、チーム全体で知識を共有し、継続的に改善できます。 私たちのContext Engineeringへの取り組みの詳細は、以前の記事「 データ戦略グループにおけるcontext engineeringの取り組み 」でも紹介しています。 GitHubをSSOTとした知識管理 私たちは、GitHubリポジトリをSingle Source of Truth（SSOT）として、分析AIエージェントが参照する全ての知識を一元管理しています。 knowledge-repository/ ├── agent/ │ ├── playbook/ │ │ ├── playbook-main.md # メインフロー │ │ ├── playbook-paths.md # 分析依頼に応じた分析パス │ │ ├── playbook-cost.md # BigQueryコストの最適化 │ │ └── playbook-quality.md # 分析における品質と禁止事項 │ └── configurations/ └── product_knowledge/ ├── product_a_knowledge.md # Product Aのドメイン知識 ├── product_b_knowledge.md # Product Bのドメイン知識 ├── product_c_knowledge.md # Product Cのドメイン知識 ...etc この構造化により、AIエージェントは必要な知識を的確に参照でき、チームメンバーは知識の追加と更新を容易に行えます。 Playbookの設計思想 Playbookは、データアナリストの思考プロセスを再現することを目的に設計されています。 責務の分割 単一のPlaybookファイルではなく、目的別に分割することで保守性を高めています。 playbook-main.md : 分析の基本フロー 分析の目的を明確化 データ品質をチェック BigQueryコストを見積もり アウトプットから逆算して分析パスを選択 playbook-paths.md : 3つの分析パスの定義 Fast : 既存のmartモデルのみを使用、低コスト Standard : 中間テーブルを参照、バランス型 Deep : 複数のレイヤーのデータを参照、高精度・高コスト playbook-cost.md : コスト最適化戦略 クエリ実行前のドライラン パーティションとクラスタリングの活用 全量スキャンの回避 playbook-quality.md : 品質ゲートと禁止事項 集計前のデータ件数確認 NULL値の扱いの明示 結果の妥当性チェック この分割により、各Playbookは独立して更新でき、特定の目的（例: コスト削減）に特化した改善が容易になります。 Product Knowledgeの役割 各プロダクトには、固有のビジネスロジックやドメイン知識があります。これらを product_knowledge/ 配下にMarkdownファイルとして整理しています。 例えば、 product_a_knowledge.md には以下のような情報が含まれます。 プロダクトの概要とビジネスモデル 重要なKPI定義 よくある分析パターン（リテンション分析、コホート分析など） データの特性や注意点 AIエージェントは、依頼フォームで指定されたプロダクトに応じて、該当するProduct Knowledgeを参照し、適切な分析を行います。 ④ データ基盤：AIに最適化されたデータ設計 分析AIエージェントが効率的に動作するためには、AIが理解しやすいデータ構造が不可欠です。私たちは、dbtを用いてデータウェアハウスのモデリングを行い、階層的なデータ構造を構築しています。 3層のデータ構造 データウェアハウスは、以下の3層で構成されています。 staging（加工処理データ） : 各種データソースを加工処理したデータ intermediate（中間層） : データクレンジングや結合を行った中間テーブル mart（分析用データマート） : ビジネスロジックを適用し、分析に最適化されたテーブル この階層化により、スピードとコストのトレードオフを明示的に管理できます。 実際の動作と効果 Slackで分析を依頼すると、以下のような流れで結果が返ってきます。 ユーザーがフォームで依頼を送信（所要時間: 1分） DevinがKnowledge Repositoryを参照しながら分析を実行（Fast: 5分、Standard: 30分） 分析結果がSlackスレッドで返却（グラフや数値サマリ付き） 社内リリースからまだ日が浅く、現在も試行錯誤を続けています。 ビジネスユーザーからのフィードバックをもとに、Playbookの改善やProduct Knowledgeの拡充を継続的に行いながら、より多くの分析ニーズに対応できるよう取り組んでいます。 AIエージェントと人間アナリストの役割分担 分析AIエージェントは、全ての分析業務を代替するものではありません。分析の複雑性と工数に応じて、適切な役割分担が重要です。 分析業務は、その複雑性に応じて3つの領域に分類できます。 BIツール : 定型レポートやダッシュボードでの即座な確認 AIエージェント : 本記事で紹介した領域。アドホックな集計や探索的分析を自律的に実行 データアナリスト + AI : 曖昧な要件の明確化やシミュレーション、戦略的な意思決定支援 現在、AIエージェントは②の領域を中心に活用されており、定型的で構造化された分析を効率化することで、 人間アナリストが戦略的な分析に集中できる環境を作っています。 今後の展望 現在の分析AIエージェントは、一部プロダクトに対応していますが、今後は以下のような拡張を計画しています。 データソースの拡充: セールスやマーケティングデータへの対応 横断的な分析: プロダクトデータとセールスデータの統合分析 より高度な分析手法: 機械学習モデルの適用や予測分析 本記事では、Slack、Devin、Context Engineeringを組み合わせた分析AIエージェントのアーキテクチャと設計思想を紹介しました。 データ分析AIエージェントの開発に取り組む方々の参考になれば幸いです。 We’re hiring! メドレーの医療プラットフォーム本部のデータ戦略グループでは、AI 時代の新しいデータ分析にチャレンジしたいデータエンジニアを募集しています。医療ヘルスケア領域でのAI×データ活用にご興味をお持ちの方は、ぜひお気軽にお声がけください！ データエンジニア／医療プラットフォーム本部の募集詳細はこちら

はじめに こんにちは、人材プラットフォーム本部 プロダクト開発部グループマネージャの松田です。ジョブメドレーアカデミーという オンライン動画研修 ・ 勤怠シフト管理 の開発を行っています。 2025年10月18日(土)、 Hono Conference 2025 に参加してきました。Honoは、Cloudflare Workersなどのエッジ環境で注目を集める超高速・軽量Webフレームワークであり、私たちメドレーでも新規プロダクトの技術スタックとして採用しています。 今回、メドレーはSilver Sponsorとして本カンファレンスに協賛しました。私たちはHonoコミュニティの発展を支援するとともに、自社のエンジニアの城間（ @shiromie ）も登壇し、HonoとAIを組み合わせた開発ワークフローについて発表しました。 本記事では、カンファレンスの熱気ある会場の様子と、 Hono はもちろん、 AI や Bun など、私たちが普段の業務で使用しているテーマを中心に、印象に残ったセッションを技術的な考察と共にご紹介します。 会場の様子 Hono Conference 2025は、docomo R&D OPEN LAB ODAIBAで開催されました。 カンファレンスは、Honoの作者 @yusukebe さんによるオープニングセッションから始まりました。 スライドには「 週200万 / 月800万 」というnpmダウンロード数が映し出され、このフレームワークがいかに注目されているかが分かります。この後のブース巡りや各セッションで、Honoを支えるエコシステムや活用事例を見ていきたいと思います。 今回のイベントでは、多くのノベルティがありました。Cloudflareのオレンジ色の靴下は特に印象的でした。また、Vercelのロゴが入ったステッカーと、クッキーをいただきました。ステッカーも充実しており、Denoのかわいい恐竜のステッカーや、JSP（JavaServer Pages）のロゴがありました。 特に、チームとして普段利用しているBunのステッカー（まんじゅう）も頂けて大満足でした。 セッションのハイライト 私がリアルタイムで聴講したセッションの中で、印象に残ったいくつかのセッションとその感想を紹介します。 Blazing Fast Full Stack Apps with Hono and JSX TwitchやYouTubeで人気のCJ氏( @CodingGarden )による発表です。ハイライトは、 HonoがAPIフレームワークから、柔軟なフルスタックフレームワークへと進化した 点です。 これまではAPI構築がメインでしたが、今回の発表では、Honoが標準でサポートするJSX、CSS in JSのように使えるHono CSS、ReactのSuspenseのように非同期データを扱えるストリーミング機能、そしてuseStateやuseEffectまで備えた軽量なクライアントコンポーネント（JSX DOM）機能がデモされました。 現在HonoをAPIサーバとして利用しているため、今回紹介されたHonoxは、今後の選択肢の一つとして非常に魅力的だと感じました。 CJ氏は人気のテックポッドキャスト『Syntax.fm』のホストとしても知られており、その語り口はさすがで、発表自体もとても丁寧で分かりやすかったです。 Interesting memory leak with Hono on Bun Bun社に所属するSosuke Suzuki氏（ @sosukesuzuki ）のセッションです。私たちのチームでもHono on Bunの組み合わせを採用しているため、メモリリークというテーマはとても楽しみにしていました。 ハイライトは、 Honoのストリーミングヘルパーと、BunのGC（ガベージコレクション）の特性が組み合わさった点 でした。 まず、Honoの処理において、レスポンスとストリームが互いを参照し合う「循環参照」が発生します。Bunが採用するJavaScriptCore（JSC）のGCは、本来これを検知して解放できるはずでした。 しかし、レスポンスからストリームへの参照が『ストロングリファレンス』という特殊な参照として実装されていました。これはGCのルートのように扱われるため、GCは「両方とも到達可能である」と判断してしまいます。その結果、どちらも解放されずにメモリリークを引き起こしていた、という内容でした。 Bunを普段から利用するので、こうしたウィークポイントを具体的に知れたのはとても参考になりました。このセッションを受け、Bun自体のバージョンアップを積極的に追随し、修正を確実に取り込んでいく重要性を再認識しました。 @scalar/hono-api-referenceとMastraでシステム仕様書を自動更新するAIワークフロー構築してみた 続いて、弊社メドレーのエンジニアの城間（ @shiromie ）による登壇セッションです。このセッションでは、私たちが普段の開発で直面している ドキュメントの陳腐化 という課題に対し、HonoとAIを組み合わせてどう解決したかを発表しました。 業務の合間を縫って構築したこのワークフローは、RAG（Bedrock + OpenSearch）とClaudeを活用したものです。特に、AIがハルシネーションを起こさず、事実に基づいた仕様書を書くようチューニングする点が、今回の取り組みにおける技術的なハイライトでした。 この取り組みは、まさに「AIが自動で成果物を作成し、人間がレビューするだけ」という理想を体現しています。具体的には、GitHub ActionsがAPI仕様書（llms.txt）の差分を検知すると、RAGが既存ドキュメントの関連箇所を特定し、Claudeが更新内容を判断してプルリクエストを自動作成します。開発者はそのPRをレビューするだけでドキュメントの鮮度が保たれます。 この取り組みは、AIを使った開発をより一層加速させる発表でした。 Closing - Hono CLI 登場 Hono ConfのClosingで終わったかと思いきや、そこで Hono CLI が世界最速で発表され、まさかの発表に会場は熱狂に包まれました。 コンセプトは「 CLI for Human and AI 」で、Hono自身もAIフレンドリーを意識した進化を遂げていることがわかりますし、ここにいるエンジニア全員が求めていたものでは？と感じました。 AIと開発者のための主要機能 1. AIエージェントの自律性向上 (AI Friendly) AIエージェントがHonoをより深く理解し、扱えるようになります。 hono search AIがドキュメントを自律的に検索し、Markdown形式の仕様を正確に把握します。 hono request サーバーを一切起動せず（ app.request() を直接実行）、型安全なリクエストをテスト実行できます。 2. 革命的な開発体験 (Developer Experience) 開発者のワークフローを根本から変える機能が導入されました。 hono serve --use <middleware> 個人的に衝撃的だった機能の一つです。 コードを一行も変更せず、コマンドラインから直接ミドルウェアを注入（例： --use logger ）できます。 3. 劇的な本番性能の最適化 (Performance) hono optimize アプリのルート情報を事前コンパイルする PreparedRegExpRouter を生成。 これにより、ルーターの 初期化速度が16倍以上高速化 し、バンドルサイズも大幅に削減されます。 Hono CLIを利用することで、開発速度が劇的に加速し、より速くプロダクトの価値を提供できるようになるだろうと感じました。 GitHub - honojs/cli: CLI for Humans and AI with Hono CLI for Humans and AI with Hono. Contribute to honojs/cli development by creating an account on GitHub. github.com 終わりに 2025年10月18日に開催された「Hono Conference 2025」に参加してきました。Honoに関わる企業・人々が一堂に集まるとても学びの多かったカンファレンスでした。 技術的な側面では、Honoが単なる「高速なAPIフレームワーク」から、JSXによるフルスタック開発、そしてHono CLIによる「AIエージェント開発基盤」へと、そのエコシステムを急速に拡大させていることを実感しました。 特に、私たちが実践している「Hono × AI」の取り組みと、コミュニティのAIに対する大きな流れが一致していたことは、大きな自信となりましたし、これからのHonoの進化が楽しみです。 素晴らしい場を創り上げた主催者・スタッフ・登壇者・協賛企業の皆様に深く感謝いたします。 メドレーでは、カンファレンスへのスポンサーの他にも、イベントの開催などを通じて技術とコミュニティへの貢献を続けています。 メドレーではエンジニアを積極採用中です！ メドレーではテクノロジーを活用して、医療ヘルスケアの未来をつくるプロダクトを開発しています。Honoが好きな方はもちろん、バックエンド、フロントエンド、インフラ、モバイルなど、ご自身の専門性を活かして医療ヘルスケア領域の課題解決に取り組みたいという、幅広いエンジニアの方を募集しています。ぜひカジュアル面談にお越しください！ エンジニア／人材プラットフォーム本部 | 株式会社メドレー エンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co テックリード・シニアエンジニア／人材プラットフォーム本部 | 株式会社メドレー テックリード・シニアエンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co 新規事業プロダクトエンジニア／人材プラットフォーム本部 | 株式会社メドレー 新規事業プロダクトエンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co

こんにちは。人材プラットフォーム本部でデザイナーをしている米田です。 メドレーは 2025年10月11日〜12日に開催された 「Designship 2025」 に、ゴールドスポンサーとして協賛しました🎉 会場の様子 「Designship」はオフラインとオンラインのハイブリッド形式で開催され、メインステージとオープンステージの2会場構成。 2日間にわたり、約80本ものデザインセッションが絶え間なく行われました。圧巻のボリュームと豪華な登壇者陣でした！ 当日の雰囲気をショート動画風にまとめてみました。 弊社ブースの様子 弊社ブースは会場入口付近に設置され、多くの方にお立ち寄りいただきました。 アンケートで、皆さんが日頃感じる医療課題についてお伺いしたところ、「待ち時間が長い」 という声が圧倒的でした。 この課題を解決する一つの取り組みとして、私たちはオンライン診療・服薬指導を通じて「通院の待ち時間」をなくすことを目指した 「総合医療アプリ CLINICS」 を提供しています。 👉 CLINICS公式サイトは こちら また、弊社のイベント情報やテックブログをお届けするメーリングリストに登録いただいた方には、その場でノベルティをお渡ししました。 他社ブースの様子 フラー株式会社様 の「夢を書いていく」ブースでは、他の来場者の夢を拝見できる素敵な展示がありました。「犬・猫を飼いたい」という方がパッと見ただけでも3人いらっしゃいました。素敵ですね。🐶🐱 自分でも書いてみました。 ファインディ株式会社様ではなんとゲームができました！ ゲームの出来が良すぎて任天堂のイベントにきてしまったような気持ち。 クリアポーチもステッカーもとても可愛いです。 弊社のセッションの様子 オープンステージでは、弊社から2名が登壇しました。 医療プラットフォーム本部の 前田（写真左） がプロダクト群統合とブランドリニューアルの取り組みを、 人材プラットフォーム本部の 小山（写真右） がアクセシビリティ向上への取り組みを紹介しました。 他社のセッションの様子 株式会社スタメン様「組織はみんなでつくる。デザイナーが仕掛ける急拡大する組織のカルチャーづくり」 組織はみんなでつくる。デザイナーが仕掛ける急拡大する組織のカルチャーづくり Designship2025でお話ししたセッション資料です。 https://design-ship.jp/2025/ speakerdeck.com 組織カルチャーという難しいテーマに対し、 デザインの力で課題解決を試みる お話が印象的でした。 人数増加によるカルチャーの希薄化を課題と捉え、LT会でのアイデア共有や、うちわ・ペンライトなどを使った施策まで展開。 「課題を見つけ、ユーザーを理解し、解決策を実行していく」、これはまさにデザイナーの仕事そのものですね。 自分の組織もデザインしていく意識を持たねば…と気が引き締まりました。 note株式会社様「作品を盛れない僕が掲げたポートフォリオ不要宣言」 作品を盛れない僕が掲げたポートフォリオ不要宣言｜宇野雄 / note inc. CDO これはDesignship 2025の発表資料です。当日はゆったりと見てもらうために、メモや撮影などしなくていいよう、記録として残しています。 -------👇ここから発表内容👇------- まず最初に問いから入ります──「ポートフォリオって、そもそも何でしょう？」 会場の皆さんの多くは、この言葉をご存じで、実際に作ったことがあると思います。 出典：デジタル大辞泉 語源を辿ると、もともとは書類や紙を入れる折りたたみのケースのこと。そこから意味が広がっていきました。 投資の世界での「ポートフォリオ」は資産の一覧や配分を指しますよね。 今日ここで使う意味は、最後の「作品集／ note.com ポートフォリオといえば、ついつい見栄えをどれだけよくするかなどを考えてしまいますが、こちらは「ポートフォリオをなくしてしまおう」という発想。 ポートフォリオの提出を任意にし、その代わり、実際の業務に取り組んでもらい、評価をしていく形に変えたそう。 私も面接時に人のポートフォリオを拝見する機会がありました。知りたいのは「どういう考えを持って課題解決をしていく方か、どこにこだわりや美意識があるのか、無理せずお互いが合う性格・価値観か」などだったなあと、なぜポートフォリオを見るのかを、今一度考えさせられました。 おわりに メドレーはこれからも、医療ヘルスケアの未来を作るために、アプリを始めとした様々なプロダクト・サービスを開発し提供していきます。 最後に改めて、Designshipの運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、お疲れ様でした、そしてありがとうございました！ 現在、メドレーでは 一緒に働く仲間 を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。 カジュアル面談も実施しています！ 株式会社メドレー 求人一覧

こんにちは。人材プラットフォーム本部でデザイナーをしている米田です。 メドレーは 2025年10月11日〜12日に開催された 「Designship 2025」 に、ゴールドスポンサーとして協賛しました🎉 会場の様子 「Designship」はオフラインとオンラインのハイブリッド形式で開催され、メインステージとオープンステージの2会場構成。 2日間にわたり、約80本ものデザインセッションが絶え間なく行われました。圧巻のボリュームと豪華な登壇者陣でした！ 当日の雰囲気をショート動画風にまとめてみました。 弊社ブースの様子 弊社ブースは会場入口付近に設置され、多くの方にお立ち寄りいただきました。 アンケートで、皆さんが日頃感じる医療課題についてお伺いしたところ、「待ち時間が長い」 という声が圧倒的でした。 この課題を解決する一つの取り組みとして、私たちはオンライン診療・服薬指導を通じて「通院の待ち時間」をなくすことを目指した 「総合医療アプリ CLINICS」 を提供しています。 👉 CLINICS公式サイトは こちら また、弊社のイベント情報やテックブログをお届けするメーリングリストに登録いただいた方には、その場でノベルティをお渡ししました。 他社ブースの様子 フラー株式会社様 の「夢を書いていく」ブースでは、他の来場者の夢を拝見できる素敵な展示がありました。「犬・猫を飼いたい」という方がパッと見ただけでも3人いらっしゃいました。素敵ですね。🐶🐱 自分でも書いてみました。 ファインディ株式会社様ではなんとゲームができました！ ゲームの出来が良すぎて任天堂のイベントにきてしまったような気持ち。 クリアポーチもステッカーもとても可愛いです。 弊社のセッションの様子 オープンステージでは、弊社から2名が登壇しました。 医療プラットフォーム本部の 前田（写真左） がプロダクト群統合とブランドリニューアルの取り組みを、 人材プラットフォーム本部の 小山（写真右） がアクセシビリティ向上への取り組みを紹介しました。 他社のセッションの様子 株式会社スタメン様「組織はみんなでつくる。デザイナーが仕掛ける急拡大する組織のカルチャーづくり」 組織はみんなでつくる。デザイナーが仕掛ける急拡大する組織のカルチャーづくり Designship2025でお話ししたセッション資料です。 https://design-ship.jp/2025/ speakerdeck.com 組織カルチャーという難しいテーマに対し、 デザインの力で課題解決を試みる お話が印象的でした。 人数増加によるカルチャーの希薄化を課題と捉え、LT会でのアイデア共有や、うちわ・ペンライトなどを使った施策まで展開。 「課題を見つけ、ユーザーを理解し、解決策を実行していく」、これはまさにデザイナーの仕事そのものですね。 自分の組織もデザインしていく意識を持たねば…と気が引き締まりました。 note株式会社様「作品を盛れない僕が掲げたポートフォリオ不要宣言」 作品を盛れない僕が掲げたポートフォリオ不要宣言｜宇野雄 / note inc. CDO これはDesignship 2025の発表資料です。当日はゆったりと見てもらうために、メモや撮影などしなくていいよう、記録として残しています。 -------👇ここから発表内容👇------- まず最初に問いから入ります──「ポートフォリオって、そもそも何でしょう？」 会場の皆さんの多くは、この言葉をご存じで、実際に作ったことがあると思います。 出典：デジタル大辞泉 語源を辿ると、もともとは書類や紙を入れる折りたたみのケースのこと。そこから意味が広がっていきました。 投資の世界での「ポートフォリオ」は資産の一覧や配分を指しますよね。 今日ここで使う意味は、最後の「作品集／ note.com ポートフォリオといえば、ついつい見栄えをどれだけよくするかなどを考えてしまいますが、こちらは「ポートフォリオをなくしてしまおう」という発想。 ポートフォリオの提出を任意にし、その代わり、実際の業務に取り組んでもらい、評価をしていく形に変えたそう。 私も面接時に人のポートフォリオを拝見する機会がありました。知りたいのは「どういう考えを持って課題解決をしていく方か、どこにこだわりや美意識があるのか、無理せずお互いが合う性格・価値観か」などだったなあと、なぜポートフォリオを見るのかを、今一度考えさせられました。 おわりに メドレーはこれからも、医療ヘルスケアの未来を作るために、アプリを始めとした様々なプロダクト・サービスを開発し提供していきます。 最後に改めて、Designshipの運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、お疲れ様でした、そしてありがとうございました！ 現在、メドレーでは 一緒に働く仲間 を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。 カジュアル面談も実施しています！ 株式会社メドレー 求人一覧

こんにちは。株式会社メドレー 医療プラットフォーム本部 デザイン室長の前田です。 こちらの記事は「MEDLEY Summer Tech Blog Relay」の 23 日目の記事です。 はじめに 9 月 1 日、メドレーは新ブランド「MEDLEY AI CLOUD」を ニュースリリース で発表しました。 これまで個別に展開してきた医療機関向けの業務支援システムを「MEDLEY AI CLOUD」として統合的にブランディングし、各プロダクトロゴも刷新しました。 この記事では 「なぜこのプロジェクトを立ち上げたのか」 、 「どんな課題があったのか」 、 「どんな未来を描いているのか」 についてお話しします。 なぜリブランディングをすることにしたのか メドレーの医療プラットフォームは 10 年前、医療事典 MEDLEY からスタートしました。その後、CLINICS、Pharms（現在、MEDIXS に統合）、DENTIS などのプロダクトを開発・提供し、MALL、MINET、Lalune、@link、MEDIXS などメドレーにジョインするプロダクトも増えてきました。プロダクトによっては 20 年以上提供し続けてきた歴史があります。 私たちの強みは、病院・診療所・薬局向けの基幹システムから患者アプリまでを一気通貫で提供していること。 しかし、プロダクトが増えるにつれ 「統一感のなさ」や「ブランドのつながりが見えないこと」 が課題として浮かび上がってきました。 医療プラットフォームのプロダクト群 組織づくりから始まった 2024 年初め、メドレーの医療プラットフォームに在籍するデザイナーはわずか 5 名。プロダクト開発業務だけで手一杯で、ブランド構築を考える余裕は微塵もありませんでした。 デザイン人材不足の課題を解消するために、 デザイン組織の立ち上げと採用の強化 から取り組みはじめました。 「デザイナー」という幅広い募集要項で採用をかけていたため、私たちが求めるスキルや役割が十分に伝わらず、なかなか採用決定に至らない状況が続いていました。 そこで、役割を「プロダクトデザイナー」と「コミュニケーションデザイナー」に分けて募集したところ、採用が一気に進展。結果として、2024 年末には 11 名体制となり、デザイナー同士で協力しあえる組織基盤を整えることができました。（2025 年 9 月時点では 14 名） デザイン組織の変遷 ブランド構築プロジェクト始動 組織体制が整ってきた 2025 年初め、いよいよブランド構築プロジェクトを開始します。最初のステップは医療プラットフォームの各プロダクトとして核となる「ブランド DNA」の設計から着手しました。 ブランドの軸を定めるため、指針を立てて、わかりやすく言語化することで、関係者の意識統一を図るのが目的です。 正直、私自身この規模のリブランディングを一気に対応していくことが初めての試みだったこともあり、どのように設計していくべきか悩みました。いろんなブランドの本を読み漁ったのですが、その中でも「 ニューヨークのアートディレクターがいま、日本のビジネスリーダーに伝えたいこと 」が今回のプロジェクトを進めていくうえで参考になりました。 ブランド DNA を設計し、経営層やプロダクト責任者と議論を重ね、ブラッシュアップしていきました。 それと平行して、各プロダクトの LP に活用するデザインシステムの検討も進めました。見た目の統一感だけでなく「顧客に安心と信頼を届けるブランド体験」を実現するフロントエンド設計も同時に目指しました。 ブランド DNA 検討中の資料 ロゴ刷新は予定外だった 当初、ロゴの刷新は計画していませんでした。 ちょうど同時期に CLINICS アプリのリブランディングが進んでおり、デザイナーのリソースを集中させる判断をしていたからです。 しかし、ブランド DNA を定義し、各プロダクトのサービスサイトをリニューアルしていく中で、それだけではブランドの一体感や方向性を十分に示せないのではないかという課題が浮かび上がってきました。 加えて、各プロダクトで AI 機能の搭載が検討され始めたことを背景に、今後の医療プラットフォームの魅力を「医療 SaaS + AI」という形で明確に示すため、統合ブランド「MEDLEY AI CLOUD」を立ち上げる決断を下します。 こうして最終的に、「統合されたブランド体験を象徴するためにはロゴ刷新が欠かせない」と判断しました。そこで全プロダクトのロゴ刷新を含む、大規模なリブランディングへと舵を切ったのです。 AI 活用の業務イメージをどう伝えるか ロゴ刷新の方針が固まり、各プロダクトで共通して使えるデザインシステムの検討も整いました。あとは「実装あるのみ！」と意気込んでいた、その矢先です。 新たな課題が立ちはだかりました。 ーー「医療 SaaS + AI」という魅力を、どう伝えるのか？ 当時、AI 機能を搭載したプロダクトはまだ開発途中。 実際の医療現場でどう役立つのか、どのようにして効率化につながるのか。 その具体的なイメージを示す手段が不足しているのでは…。 そんな不安が広がっていったのです。 自ら AI 活用で業務効率化を体感してみる そんな不安を打ち消すきっかけになったのが、「AI 活用のイメージを動画で見せてしまおう」というアイデアでした。 ちょうどその頃、社内では生成 AI 利用のガイドラインが整備され、各部門でもそれに沿った AI 活用が推進されていました。その流れも相まって、私自身も AI を取り入れた動画制作に挑戦することにしたのです。 ナレーションや BGM に AI を駆使し、構成や演出については自ら試行錯誤を重ねました。その結果、短期間でムービーを完成させることができました。 「AI による効率化を語るなら、まず自分が体験してみよう」 その思いから取り組んだ動画は、ブランドやプロダクトの未来像を端的に伝える欠かせない要素となりました。 BRAND PROMISE MOVIE - MEDLEY AI CLOUD MEDLEY AI CLOUDは、AIを活用して医療機関の業務効率化を実現し、患者・生活者により良い体験を届ける、株式会社メドレーが提供する次世代医療プラットフォームです。 medley-cloud.com 運用されつづけるデザインシステムをどう構築するか Developer ブログらしく、同時並行して進めてるデザインシステム構築についても少し触れておきます。デザインシステムは「作ったら終わり」ではなく、継続的に運用される仕組みがなければ意味がありません。 マルチ CMS 環境という課題 各プロダクトの LP は、WordPress や外部の CMS、Headless CMS など、バラバラな環境で運用されています。そこで、同じ環境でデザインシステムを構築し、どのサイトからでも共通で利用できる状態を目指すことにしました。 この課題を解消するために社内のエンジニアともすり合わせをして、以下を実施することにしました。 ・CMS の一本化：Headless CMS へ統一 ・モノレポ化：共通デザインシステムを集中管理 ・コンポーネント呼び出し：各プロダクトから共通の UI コンポーネントを利用可能に この仕組みにより、UI やブランドトーンを一貫させつつ、各 LP への高速な展開ができると思っています。 現段階では、 MEDLEY AI CLOUD のみで実装されていますが、今後は各プロダクト LP へも順次展開していく予定です。この取り組みの詳細は、また別の機会に説明できればと思っております。 これから ロゴは無事に完成し、各プロダクト LP への反映も進んでいます（ロゴ制作についても別の機会に説明できればと思います）。 けれども、ブランド構築プロジェクトはまだ始まったばかり。ロゴ刷新はあくまで出発点であり、これからはブランド体験の一貫性をさらに高め、医療現場や患者とのさまざまな接点にブランドを浸透させていくフェーズが本格化します。 私たちが提供する MEDLEY AI CLOUD の各プロダクトの使命は、「医療現場の業務効率化と、より良い患者体験を支援する」ことにあります。プロジェクトを進める中で、私自身も AI ツールの活用が推進力になることを強く実感しました。 全プロダクトで共通する 5 つのブランド・プロミス より良い患者体験 AI 活用 安心・安全 オープン連携 リーズナブル これらを軸に、病院・診療所・薬局・歯科といった領域をつなぎ、患者・生活者と直結する「ひとつながりの医療プラットフォーム」を実現していきます。中長期的には、社会インフラの一翼を担うプラットフォームとなることを目指しています。 さいごに MEDLEY AI CLOUD ブランドの浸透や各プロダクトの開発を進めるうえで、これからもデザイナーの力は欠かせません。 このブランド構築プロジェクトは、私たち自身の想いや未来への取り組みを社内外に届けるため、外部に頼らず、社内メンバーだけでつくり上げてきました。 今後はブランド認知のさらなる拡大と事業成長を見据え、デザイナーをはじめ、多様な専門性を持つ仲間を必要としています。 少しでも興味を持っていただけたら、ぜひ MEDLEY AI CLOUD サイト内の採用一覧 をご覧ください。 私たちと共に、未来の医療体験を一緒につくっていきましょう。 MEDLEY AI CLOUD MEDLEY AI CLOUDは、AIを活用して医療機関の業務効率化を実現し、患者・生活者により良い体験を届ける、株式会社メドレーが提供する次世代医療プラットフォームです。 medley-cloud.com

こんにちは！株式会社メドレーでDevRelを担当している重田です。 株式会社メドレーは、2025年9月19日(金)〜21日(日)に開催された iOSDC Japan 2025 に、ゴールドスポンサーとして協賛しました。昨年同様、今年はセッション登壇とブース出展の両方を実施しました。記念すべきiOSDC Japan 10周年を、コミュニティの一員として迎えられたことを大変嬉しく思います！ メドレーでは複数のモバイルアプリを開発しており、コミュニティとのつながりを通じて開発力とプロダクト価値の向上を目指しています。その活動の一環として、弊社は2017年からiOSDC Japanに協賛しており、今年で9回目となりました。 本記事では、3日間にわたるイベントの様子と共に、メドレーの取り組み、そして印象に残ったセッションやブースについてレポートします。 2024年の参加レポートもぜひご覧ください → https://developer.medley.jp/entry/2024/09/10/205504/ 会場の様子 iOSDC Japan 2025は、有明セントラルタワー&カンファレンスにて開催されました。今年は3日間にわたり、のべ1,500名ものiOSエンジニアが有明に集結し、技術への熱気に満ち溢れた空間となりました。スポンサーブースエリアも連日多くの参加者で賑わい、カジュアルな雰囲気で技術交流を楽しむ姿がそこかしこで見受けられました。 常に、軽食とフリードリンクが用意されており、ブース運営にとって大変ありがたいサービスでした！ フリードリンク（お水）には開催年度のデザインが施され、手に取るのが楽しかったです。 15時以降になると、アルコール類も提供があり驚きました。 セッションの様子 メドレーからは、医療PF所属の吉田が登壇しました。 ご聴講いただいた皆さま、ありがとうございました！ 止められない医療アプリ、そっと Swift 6 へ 2025年9月21日（日）に開催のiOSDC Japan 2025の登壇資料です。 イベントURL：https://iosdc.jp/2025/ 発表者情報：医療プラットフォーム本部　エンジニア　吉田将吾 speakerdeck.com エンジニアに聞いた面白かったセッション 弊社エンジニアが気になった・聴講して面白かったセッションをご紹介します！ アセンブリで学ぶCPUアーキテクチャ by akkey Learn CPU architecture with Assembly iOSDC Japan 2025 https://fortee.jp/iosdc-japan-2025/proposal/4316d7ee-b3a0-4623-997a-df8843a9a709 speakerdeck.com 私たちが日々用いている Swift などのプログラミング言語は、LLVM を経由してアセンブリに変換され、最終的に機械語として実行されます。アセンブリは普段あまり意識しない領域ですが、開発の基盤を支える重要な要素です。 本セッションはそのアセンブリに焦点を当て、アセンブリとは何か、具体的な読み方、スタックトレースを用いた実例まで、とっつきにくい内容を非常にわかりやすく解説していました。 日常の開発で直接触れる機会は多くないかもしれませんが、技術的な好奇心を強く刺激する発表でした。 Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム by giginet Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム https://fortee.jp/iosdc-japan-2025/proposal/c740120d-d52f-4100-986b-a24e8f0d3b87 speakerdeck.com iOS アプリ開発では、普段あまり意識せずにビルドを行っていますが、今年の初めに Apple がビルドエンジンである「Swift Build」のオープンソース化を発表しました。 本セッションでは、既存のビルドシステムの説明から、Swift Build で何が変わるかを丁寧に説明していました。 CLINICS アプリでも Swift Package Manager を使ったマルチモジュール構成を採用しています。Xcode Project と Package.swift 双方がどのようにビルドされ、最終的にアプリとしてパッケージ化されるのか理解が深まり、非常に有意義な発表でした。 プログラマのための作曲入門 by CHEEBOW プログラマのための作曲入門 プログラマのための作曲入門 iOSDC Japan 2025 2025/09/21 13:55〜 Track A 音楽とプログラミングはまったく違うもの。芸術と情報工学の間に、共通点などない。 ……と思われている方も多いようです。 しかしながら、それは大きな誤解なのです。 なぜ… speakerdeck.com iOSDC というと、iOS に関するセッションだけだと思われがちですが、iOS から離れた技術領域のセッションも採択されることがあります。 本セッションは、実際にアーティストへ楽曲提供している iOS エンジニアの CHEEBOW さんによる、作曲に関するお話でした。 コード進行の実例を交え、作曲をわかりやすく解説しており、作曲未経験の人にも理解しやすい内容でした。作曲とソフトウェア開発は一見まったく異なる領域に思えますが、コード進行にも定番がいくつもあり、ソフトウェア開発でいう「デザインパターン」に相当するものだ、という表現が印象的でした。 「Chatwork」アプリにおけるSVVS実装戦略 「Chatwork」アプリにおけるSVVS実装戦略 | ドクセル iOSDC2025の登壇資料です。 ビジネスチャット「Chatwork」を提供する株式会社kubell（旧Chatwork株式会社... www.docswell.com SVVSというアーキテクチャでプロダクトを実装していく上で直面した課題とその課題を解決する方法が話されていました。セッションの前半で、ログインのライフサイクルを管理するためにLoginContextを導入した話は興味深く聞きました。ライフサイクル管理のための考え方として、他にも応用が効く考え方であると感じました。 ブース出展の様子 約50社のブースが出展されており、連日とても賑わっていました。 本記事では、私たちのブースと特に印象に残ったブースをいくつかご紹介します！ 弊社ブースの様子 私たちは医療×iOSに関する3択3問クイズにチャレンジいただき、正解数に応じてノベルティを配布していました！ 日替わりで問題を変更し、全日楽しんでいただけるよう工夫しました。 👇実際に出題した問題を一部ご紹介。最後には解説付きで正誤を確認！ 全問正解の方には、今回初めて登場したノベルティ「ポータブル防災7点セット」をプレゼント！ いざという時に役立つグッズをご用意しました🏃‍♀️ お越しいただいた皆様、ありがとうございました🙌✨ その他のブースの様子 KINTOテクノロジーズ株式会社 AI広報るぴあちゃんとじゃんけんで勝つとトミカがもらえる楽しいブースでした🚙 トミカ欲しさに何度かチャレンジしたものの、るぴあちゃんが強くてゲットならず・・・（写真に写っている弊社エンジニアは勝ってトミカをゲットしていました👏） 本田技研工業株式会社 最新の車載システムとiOSの連携について、デモを交えながら詳しく説明されていました。普段触れることのない分野の技術に触れられ、とても興味深かったです。 （なんといってもバイクがカッコよかったです!!!） 株式会社Luup 新しいモビリティサービスをiOSエンジニアの視点から解説されており、地図や位置情報と密接に関わる開発の面白さを感じることができました。 タップ数をクリアしたらロックが外れトートバッグをゲットできる仕掛けになっていました。 まとめ DevRelとしてメドレーの事業やプロダクトをコミュニティに発信することを目的として参加した今回のiOSDC。スポンサーセッションやブース出展を通して、多くのiOSエンジニアの皆さんと直接お話しする機会をいただき、非常に有意義な3日間となりました。 ブースに立ち寄ってくださった皆様、ありがとうございました！ 今後もメドレーは技術コミュニティへの貢献、そして弊社をより多くの方々に知っていただくためにイベントへの協賛を継続していきます。 またカンファレンスでお会いしましょう！ We’re hiring! メドレーではiOSエンジニアをはじめ、 「医療ヘルスケアの未来をつくる」というミッションに共感し、ともに切磋琢磨する仲間を大募集中です。 少しでもご興味のある方はまずはカジュアル面談でお話しましょう！ 株式会社メドレー 株式会社メドレー です。| HRMOS hrmos.co ※カジュアル面談をご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

こんにちは！株式会社メドレーでDevRelを担当している重田です。 株式会社メドレーは、2025年9月19日(金)〜21日(日)に開催された iOSDC Japan 2025 に、ゴールドスポンサーとして協賛しました。昨年同様、今年はセッション登壇とブース出展の両方を実施しました。記念すべきiOSDC Japan 10周年を、コミュニティの一員として迎えられたことを大変嬉しく思います！ メドレーでは複数のモバイルアプリを開発しており、コミュニティとのつながりを通じて開発力とプロダクト価値の向上を目指しています。その活動の一環として、弊社は2017年からiOSDC Japanに協賛しており、今年で9回目となりました。 本記事では、3日間にわたるイベントの様子と共に、メドレーの取り組み、そして印象に残ったセッションやブースについてレポートします。 2024年の参加レポートもぜひご覧ください → https://developer.medley.jp/entry/2024/09/10/205504/ 会場の様子 iOSDC Japan 2025は、有明セントラルタワー&カンファレンスにて開催されました。今年は3日間にわたり、のべ1,500名ものiOSエンジニアが有明に集結し、技術への熱気に満ち溢れた空間となりました。スポンサーブースエリアも連日多くの参加者で賑わい、カジュアルな雰囲気で技術交流を楽しむ姿がそこかしこで見受けられました。 常に、軽食とフリードリンクが用意されており、ブース運営にとって大変ありがたいサービスでした！ フリードリンク（お水）には開催年度のデザインが施され、手に取るのが楽しかったです。 15時以降になると、アルコール類も提供があり驚きました。 セッションの様子 メドレーからは、医療PF所属の吉田が登壇しました。 ご聴講いただいた皆さま、ありがとうございました！ 止められない医療アプリ、そっと Swift 6 へ 2025年9月21日（日）に開催のiOSDC Japan 2025の登壇資料です。 イベントURL：https://iosdc.jp/2025/ 発表者情報：医療プラットフォーム本部　エンジニア　吉田将吾 speakerdeck.com エンジニアに聞いた面白かったセッション 弊社エンジニアが気になった・聴講して面白かったセッションをご紹介します！ アセンブリで学ぶCPUアーキテクチャ by akkey Learn CPU architecture with Assembly iOSDC Japan 2025 https://fortee.jp/iosdc-japan-2025/proposal/4316d7ee-b3a0-4623-997a-df8843a9a709 speakerdeck.com 私たちが日々用いている Swift などのプログラミング言語は、LLVM を経由してアセンブリに変換され、最終的に機械語として実行されます。アセンブリは普段あまり意識しない領域ですが、開発の基盤を支える重要な要素です。 本セッションはそのアセンブリに焦点を当て、アセンブリとは何か、具体的な読み方、スタックトレースを用いた実例まで、とっつきにくい内容を非常にわかりやすく解説していました。 日常の開発で直接触れる機会は多くないかもしれませんが、技術的な好奇心を強く刺激する発表でした。 Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム by giginet Swiftビルド弾丸ツアー - Swift Buildが作る新しいエコシステム https://fortee.jp/iosdc-japan-2025/proposal/c740120d-d52f-4100-986b-a24e8f0d3b87 speakerdeck.com iOS アプリ開発では、普段あまり意識せずにビルドを行っていますが、今年の初めに Apple がビルドエンジンである「Swift Build」のオープンソース化を発表しました。 本セッションでは、既存のビルドシステムの説明から、Swift Build で何が変わるかを丁寧に説明していました。 CLINICS アプリでも Swift Package Manager を使ったマルチモジュール構成を採用しています。Xcode Project と Package.swift 双方がどのようにビルドされ、最終的にアプリとしてパッケージ化されるのか理解が深まり、非常に有意義な発表でした。 プログラマのための作曲入門 by CHEEBOW プログラマのための作曲入門 プログラマのための作曲入門 iOSDC Japan 2025 2025/09/21 13:55〜 Track A 音楽とプログラミングはまったく違うもの。芸術と情報工学の間に、共通点などない。 ……と思われている方も多いようです。 しかしながら、それは大きな誤解なのです。 なぜ… speakerdeck.com iOSDC というと、iOS に関するセッションだけだと思われがちですが、iOS から離れた技術領域のセッションも採択されることがあります。 本セッションは、実際にアーティストへ楽曲提供している iOS エンジニアの CHEEBOW さんによる、作曲に関するお話でした。 コード進行の実例を交え、作曲をわかりやすく解説しており、作曲未経験の人にも理解しやすい内容でした。作曲とソフトウェア開発は一見まったく異なる領域に思えますが、コード進行にも定番がいくつもあり、ソフトウェア開発でいう「デザインパターン」に相当するものだ、という表現が印象的でした。 「Chatwork」アプリにおけるSVVS実装戦略 「Chatwork」アプリにおけるSVVS実装戦略 | ドクセル iOSDC2025の登壇資料です。 ビジネスチャット「Chatwork」を提供する株式会社kubell（旧Chatwork株式会社... www.docswell.com SVVSというアーキテクチャでプロダクトを実装していく上で直面した課題とその課題を解決する方法が話されていました。セッションの前半で、ログインのライフサイクルを管理するためにLoginContextを導入した話は興味深く聞きました。ライフサイクル管理のための考え方として、他にも応用が効く考え方であると感じました。 ブース出展の様子 約50社のブースが出展されており、連日とても賑わっていました。 本記事では、私たちのブースと特に印象に残ったブースをいくつかご紹介します！ 弊社ブースの様子 私たちは医療×iOSに関する3択3問クイズにチャレンジいただき、正解数に応じてノベルティを配布していました！ 日替わりで問題を変更し、全日楽しんでいただけるよう工夫しました。 👇実際に出題した問題を一部ご紹介。最後には解説付きで正誤を確認！ 全問正解の方には、今回初めて登場したノベルティ「ポータブル防災7点セット」をプレゼント！ いざという時に役立つグッズをご用意しました🏃‍♀️ お越しいただいた皆様、ありがとうございました🙌✨ その他のブースの様子 KINTOテクノロジーズ株式会社 AI広報るぴあちゃんとじゃんけんで勝つとトミカがもらえる楽しいブースでした🚙 トミカ欲しさに何度かチャレンジしたものの、るぴあちゃんが強くてゲットならず・・・（写真に写っている弊社エンジニアは勝ってトミカをゲットしていました👏） 本田技研工業株式会社 最新の車載システムとiOSの連携について、デモを交えながら詳しく説明されていました。普段触れることのない分野の技術に触れられ、とても興味深かったです。 （なんといってもバイクがカッコよかったです!!!） 株式会社Luup 新しいモビリティサービスをiOSエンジニアの視点から解説されており、地図や位置情報と密接に関わる開発の面白さを感じることができました。 タップ数をクリアしたらロックが外れトートバッグをゲットできる仕掛けになっていました。 まとめ DevRelとしてメドレーの事業やプロダクトをコミュニティに発信することを目的として参加した今回のiOSDC。スポンサーセッションやブース出展を通して、多くのiOSエンジニアの皆さんと直接お話しする機会をいただき、非常に有意義な3日間となりました。 ブースに立ち寄ってくださった皆様、ありがとうございました！ 今後もメドレーは技術コミュニティへの貢献、そして弊社をより多くの方々に知っていただくためにイベントへの協賛を継続していきます。 またカンファレンスでお会いしましょう！ We’re hiring! メドレーではiOSエンジニアをはじめ、 「医療ヘルスケアの未来をつくる」というミッションに共感し、ともに切磋琢磨する仲間を大募集中です。 少しでもご興味のある方はまずはカジュアル面談でお話しましょう！ 株式会社メドレー 株式会社メドレー です。| HRMOS hrmos.co ※カジュアル面談をご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

はじめに この記事は メドレー夏のブログリレー 2025 22 日目の記事です。 メドレー医科診療所プロダクト開発室 AI推進グループの桶谷です。 AI推進グループでは、「AIで “医師” と “エンジニア” の生産性を最大化する」というミッションを掲げ、医師の皆様に向けたAIソリューション（「ゼロ距離医療」の実現）と、社内エンジニアの生産性向上（「CLINICS 10x」）の両輪で様々な施策に取り組んでいます。取り組みの全体像は こちらの記事 で詳しく紹介しています。興味のある方はぜひお読みください。 その中でも「CLINICS 10x」では、従来の10倍の速度で機能リリースを実現するための様々な取り組みを進めています。 10倍のリリーススピードを実現するには、単に開発を速めるだけでなく、リリースの品質担保、特にQAの効率化とバグの早期検知が極めて重要になります。 CLINICSは多くの医療機関で利用される基幹システムであり、不具合発生時の影響をいかに局所化し、迅速に修正できる体制を築くかが大きな課題でした。 そこで、10xリリースの土台作りとして、まず「ライブラリ更新」のリリース戦略見直しに着手しました。 今回はその取り組みの中から、CLINICSを開発しているチームで導入した、ライブラリ更新を分離する新しいブランチ戦略についてご紹介します。 ※ ライブラリ更新：本記事ではMinor、Patchレベルの更新を指します 想定読者 リリースプロセスに課題を感じている人 開発チームと連携して品質保証の仕組みを改善したい人 なぜリリース戦略を見直したのか CLINICS は多くの医療機関で利用されている診療所向けクラウド型電子カルテシステムです。 医療機関向け SaaS として提供される一方で、電子カルテ、予約管理、会計、オンライン診療など診療所の基幹業務を一手に担う「基幹システム」として機能しています。日々の診療に直結する業務を支えるため非常に高い安定性と信頼性が求められます。サービスの性質上、ひとつの変更が「受付 → 診療 → 会計」といった一連の業務フロー全体に波及する可能性があるため、品質保証の重要性は非常に高いです。 その品質保証の範囲も単なる UI 動作の確認にとどまらず、業務フローの整合性、データ整合性、権限や監査、請求（算定）ロジック、可用性といった多岐にわたる領域に広がります。しかし、いくらテストを厚くしても、あらゆる組み合わせを事前に網羅するのは現実的に困難であり、検証漏れのリスクを完全に排除することはできません。そのため、リリース設計においては差分を小さく保ち、影響範囲を限定し、原因を切り分けやすくする工夫が不可欠となります。 さらに技術的な背景として、CLINICS は Rails モノリスに複数の SPA を内包し、バックエンド、フロントエンド、一部インフラを単一リポジトリ（モノレポ）で集約的に管理・運用しています。1つのリポジトリに Rails、React、Next.js、Node.js といった技術スタックが同居しており、依存関係は論理的に分離されているものの、ライブラリ更新の頻度は高く、変更の影響範囲も広大になりがちでした。 こうした背景と課題から、まずは機能とライブラリのリリースを分けることで、変更差分と影響を最小化しようと取り組みました。 従来のリリースプロセス CLINICSでは、 master（本番環境相当）/ develop（開発統合）/ release-candidate（次回リリース候補のコードフリーズ） の3ブランチ構成を基本に運用しています。従来は「機能追加」と「ライブラリ更新」を毎週火曜日の定常リリースにまとめて実施していました。具体的には、各 feature ブランチや deps（ライブラリ更新）ブランチを develop に順次マージし、木曜日に develop から release-candidate を作成してコードフリーズ。このrelease-candidate 上で QA を実施し、翌週火曜日に master へまとめてリリースするというフローです。 図を見て分かる通り、Git Flow をベースに開発、リリースを実施しており、全ての変更が毎週火曜日の定常リリースに集約されていました。 この方法ではプロダクトの成長とともに、以下の課題が浮き彫りになりました。 不具合発生時の原因切り分けが難しい ：不具合が生じても、それが新機能によるものかライブラリ更新によるものか特定に時間がかかる 品質担保コストの増大 ：ライブラリ更新は予期せぬ副作用を生むことがあり、機能追加と同時に行うことで QA の範囲が広がり、テストや検証に必要なコストが増大していた リリース時の差分が大きいと、一見些細なライブラリ更新であっても、医療現場の業務フローに予期せぬ不具合を引き起こし、診療や会計といった基幹業務に影響を及ぼすリスクがあります。実際にも、ライブラリ更新と多様なデータ状況など複数の要因が重なれば、一部の医療機関で「会計処理が停止する」といった業務に直結する問題が発生する恐れがありました。こうした事象は、医師やスタッフの負担を増やすだけでなく、患者体験にも直結してしまいます。 さらに昨今では、生成AIを活用した開発の加速によって、リリースごとに扱う差分はますます膨らみ、従来のリリースプロセスのままでは品質とスピードの両立が難しくなってきました。そこで、「CLINICS 10x」の思想に立ち返り、品質を確保しながらもスピードを失わないために、リリース戦略そのものを見直す必要があると判断しました。 新しいリリース戦略で実現したいこと 今回の取り組みで目指したのは、単なるリリース手法の変更ではなく、チーム全体が安心して開発・検証・リリースに取り組める体制を作ることです。そのために、次の3つを軸としました。 ライブラリ更新の安定化 不具合発生時に「ライブラリ起因」と即座に判断して対応できるため、機能変更と明確に切り分けてリスク管理が可能となる 不具合発生時にライブラリ更新だけを即時に戻せるため、初動対応を安全に行える 機能リリースの明確化 QAは機能検証に集中でき、テストの粒度と品質が向上する リリースノートも「メンテナンス」と「アップデート」に分け、ユーザーに分かりやすく伝えられる 品質とスピードを兼ね備えた体制 小さな差分で安全かつ素早くリリースできる体制を確立 領域ごとの責任分担と確認項目を明確化し、安心して高速リリースを実行できる運用体制を整備 この取り組みには技術面だけでなく、事業部やQAチームとの合意形成も不可欠です。 特に、カスタマーサクセス（CS）/サポートデスクは変更点の把握が不可欠である一方で、ライブラリ更新といった技術的変更が十分に共有されないままリリース差分が大きくなることに不安を抱えていました。 そこで、週2回のリリース頻度増は「差分を小さく保ち、リスクを分離・局所化すること」を狙いとしていると説明し、リリースノートを「メンテナンス（ライブラリ）／アップデート（機能）」に分けて整理しました。 結果として、関係部署からも「そのほうが安全で把握しやすい」と理解が得られ、スムーズに合意形成へとつなげることができました。 一方で QA チームも、従来はライブラリ更新と機能追加を同時に検証していたため、不具合が発生すると原因切り分けに苦労していました。こうした課題感もあり、「更新と機能を分けた方が効率的に品質を担保できる」という点で意見が一致しました。加えて、開発と QA が一体となって品質を高める文化がすでに定着していたことも後押しし、新しいリリース戦略をスムーズに取り入れることができました。 ライブラリリリースと機能リリースを分ける際のブランチ戦略 今回、新たに「ライブラリ更新専用のブランチ」を追加することで、ライブラリ更新を単体でリリースできるようになり、機能リリースと役割を分担した週2回の安定したリリース体制を実現しました。 曜日 リリース成果物 ブランチ 月曜日 ライブラリ更新 release-candidate-lib 火曜日 機能追加 release-candidate この仕組みにより、ライブラリ更新と新機能追加という性質の異なる変更が互いに干渉せず、それぞれに適したテストと品質保証を行える体制を確立することができました。 AS-IS / TO-BE の比較 AS-IS（従来のリリースフロー） TO-BE（新しいリリースフロー） AS-IS では、機能追加（feature）と依存更新（deps）が develop に同居し、木曜日作成の release-candidate 上でまとめて QA を実施し、翌週火曜日に単一リリースしていました。TO-BE ではフローを2本に分離しました。ライブラリ更新は release-candidate-lib-next に集約し、同時に develop へ Reverse Merge することで、日常開発の中で早期に動作検証を行います。安定化した内容は月曜日に release-candidate-lib にて、ライブラリのみのリリースを実施します。機能追加については従来通り release-candidate を経由し、火曜日に本番リリースを行う形にしました。 新しいブランチ戦略におけるキーポイントとメリット・デメリット 今回の戦略で最大のポイントは、release-candidate-lib-next ブランチの新設です。 Renovate/Dependabot が作成するライブラリ更新 PR を release-candidate-lib-next に集約することで、翌々週にリリースされるライブラリ更新の成果物を対象に、長期回帰テストを継続的に実施できるようになりました。コードフリーズブランチを「ライブラリ用」と「機能用」に分離したこともポイントです。ライブラリ更新は回帰確認中心、機能追加は業務フローやユーザー体験検証中心といった形で、QA のスコープを用途ごとに最適化できるようになりました。加えて、ライブラリ更新を単独でリリースできるため、不具合発生時には原因の切り分けが容易になり、ライブラリのみを安全に Revert する対応も可能です。 こうした仕組みによって、品質保証の効率化と精度向上を実現しつつ、不具合対応の即応性も高めることができました。一方で、運用を進める中でいくつかの課題やトレードオフも明らかになってきました。 Reverse Merge の増加 ：release-candidate-lib-next → develop への取り込み頻度が上がり、特にコンフリクト発生時の解消コストが高い ブランチ運用の複雑化 ：release-candidate-lib-next / release-candidate-lib の追加によって、運用コストや学習コストが増大 CI/テスト負荷の増加 ：候補ブランチごとに E2E が走るため、ジョブ数が増えて実行環境への負荷が高い(省力化や高速化に向けた改善は別途実施中) これらの課題は認識しつつも、チーム合意のもと「医療に直結するプロダクトとして品質を優先する」という判断を取りました。 その結果、リスクの局所化と原因特定の迅速化を両立し、週2回の安全なリリースを継続できる体制を確立できています。 QA チームによる品質担保の仕組み ここからは、QA エンジニアの小島 ( @Daishu ) が、今回の改善における E2E テストを用いた品質担保の設計について紹介します。 E2E テストの実施体制 CLINICS では、QA チームが MagicPod を使って E2E テストを管理しています。 出典: 徹底解剖！ 医療業務システムのReactコンポーネント設計 を基に作成 各ブランチでは、以下の頻度と目的で E2E テストを実行しています： 1. 開発統合 (develop) ブランチ デイリーで E2E テストを実行し、デグレを検出します。テスト失敗時は原因を分析し、仕様変更による失敗の場合は MagicPod のテストシナリオを更新して対応しています。 2. リリース候補 (release-candidate) ブランチ ウィークリーで E2E テストと手動テストの両方をフルスイートで実行してリリース可否を判定します。 新しいリリースプロセスへの対応 新体制への移行にあたり、QA チームの懸念や要望を開発チームに共有し、一緒に品質担保の仕組みを設計しました。 ① deps マージタイミングの最適化 deps をマージするタイミングを変更したことで、問題の切り分けが改善されました。 deps マージタイミング 特徴 旧 release-candidate ブランチカット前 • ライブラリ更新が翌週リリースとなる • 不具合検出の猶予がなく、問題切り分けに時間がかかる 新 release-candidate ブランチカット後 • ライブラリ更新のリリースが翌々週となる • 開発環境での検証期間を確保でき、問題の切り分けが容易になる この変更により、 deps 起因の問題を効率的に検出・対応できるようになりました。 ② release-candidate-lib ブランチでの E2E テスト追加 前述の release-candidate-lib ブランチに対する E2E テストを追加しました。これにより、ライブラリ更新の品質を単独で検証できるようになりました。 ③ MagicPod ブランチ機能による UI バージョン管理 release-candidate-lib は前回リリース済みのコードをベースにしているのに対し、E2E テストは日々更新される最新の develop に合わせてメンテナンスされているため、そのままでは UI の差分でテストが失敗します。この問題は、 MagicPod ブランチ機能 で解消しています。 # 運用フロー 1. 木曜日：E2E テスト完了時点で MagicPod branch を作成 └─ ブランチ名: release-candidate-lib/YYYY-MM-DD 2. 翌週木曜日：前週に作成した branch を指定して、E2E テスト実行 3. テスト完了後：branch を削除して、次のサイクルに備える MagicPod の定期実行機能では branch を指定できない仕様のため、GitHub Actions から API 経由で branch を指定して週次で自動実行しています。 以上、QA チームの視点から、新しいリリース戦略を支える品質担保の仕組みについて紹介しました。開発チームと共に設計したこの体制により、週 2 回のリリースでも効率的な検証と高い品質維持を実現しています。 まとめ 今回リリース戦略の見直しにより、CLINICS 開発チームでは「品質」と「スピード」の両立に向けて土台を築くことができました。 不具合発生時の原因切り分けは迅速になり、QA プロセスも効率化されています。 今後はさらに、フロントエンドとバックエンドを個別にリリースできる体制や、日中に安心してリリースできる仕組みの整備にも取り組んでいく予定です。 これらの改善を通じて、より柔軟に、そして迅速に、ユーザーにとって価値ある改善を届けられる開発体制を目指していきます。 We Are Hiring! 最後まで読んでいただきありがとうございます！ メドレーでは、開発プロセスの改善や自動化に情熱を注げるエンジニアを募集しています。 もし私たちの取り組みに少しでも興味を持っていただけましたら、ぜひカジュアルにお話ししましょう！ テックリード バックエンド／CLINICS | 株式会社メドレー テックリード バックエンド／CLINICS（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co 「 Medley Summer Tech Blog Relay 」 23 日目は、医療プラットフォーム本部の前田さんの記事です！