はじめに この記事は 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さんの靴下は来場したときから一目惚れだったので当たって嬉しかったです！（猫ちゃんモチーフで全てがかわいかった） 最後に 初めてのブース参加でしたが、とても楽しかったです。次回はもっとセッションや交流を楽しみたいと思います。 （開場後まだ元気な私。すぐに軟弱な足腰が悲鳴をあげ、マツキヨで湿布を買いました） メドレーはこれからも、医療ヘルスケアの未来を作るために、様々なプロダクト・サービスを開発し提供していきます。 現在、メドレーでは一緒に働く仲間を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。 株式会社メドレー 求人一覧

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

はじめに こんにちは、人材プラットフォーム本部 プロダクト開発部グループマネージャの松田です。ジョブメドレーアカデミーという オンライン動画研修 ・ 勤怠シフト管理 の開発を行っています。 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の運営の皆様、登壇されたスピーカーの皆様、参加者の皆様、お疲れ様でした、そしてありがとうございました！ 現在、メドレーでは 一緒に働く仲間 を募集しています。この記事やイベントを通じて興味を持っていただいた方は、ぜひお気軽にご連絡ください。 カジュアル面談も実施しています！ 株式会社メドレー 求人一覧

こんにちは。株式会社メドレー 医療プラットフォーム本部 デザイン室長の前田です。 こちらの記事は「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 ※カジュアル面談をご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

はじめに この記事は メドレー夏のブログリレー 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 日目は、医療プラットフォーム本部の前田さんの記事です！

はじめに この記事は メドレー夏のブログリレー 2025 21 日目の記事です。 医療プラットフォーム本部 プラットフォーム開発室 SRE グループの山田です。 医療機関向け SaaS である CLINICS の安定稼働とシステム信頼性の向上に取り組んでいます。 SREグループは開発組織全体の中でも比較的少人数のチームです。 そのため、腰を据えて事業やプロダクトに中長期的な価値を生む時間を作るためにも、トイルの削減に力を入れています。 繰り返し作業や自動化が可能なタスクを効率化する上で、AWS Step Functionsは非常に強力なサービスです。 本記事では、AWS Step Functions を活用し、1000を超えるデータベースのマイグレーション作業を自動化した事例を題材に、Step Functionsの 実践的な活用方法（tips） についてご紹介します。 メンテナンス作業のおおまかなワークフロー DBのバックアップ（スナップショットを作成） DBマイグレーションを実施 マイグレ後のDBスキーマチェック ECS Task（アプリケーション）のデプロイ 完了/失敗通知を飛ばす 更新手順としてはごく一般的なワークフローかと思います。 しかし、手順2で大量のデータベースをどのようにして夜間で更新しきるのかが課題となりました。 プロダクトの成長とともにデータベースの数が増えていくという特性上、なるべく変更管理の手間がかからない仕組みを導入しなくてはなりません。 Step Functions を用いたアプローチ SREチームでは上述した課題に対して Step Functions によるメンテナンスを自動化することにしました。 AWS Step Functions とは？ ここでは、詳細な説明は割愛しますが、AWS Step Functions は複数のAWSリソースやサービスを統合してワークフローを構築するためのサービスです。 lambda で実装するには処理が複雑だったり処理時間が15分以上かかる場合、Step Functionsが選択肢となります。 （AWS Step Functions は最大1年実行が可能） 1. Map ステートを活用する Map ステートは同一ワークフローに異なる入力を与えてタスクを並列実行する（動的並列処理）機能です。 Map ステートに与える入力を増やす/減らすことでワークフローを変更することなく並列実行するタスクをスケールさせることができます。 これにより、大量のDBマイグレーションを同時に実行しメンテナンス時間の短縮をしただけでなく、変更に強いワークフローを構築することができました。 ワークフローの処理内容 各ブランチのマイグレーションタスクがどのDBのマイグレーションを実施するのかリストを作成（画像では3並列なので1 Taskあたり約333DBのマイグレーションを実行するように振り分け） 複数のECS Taskを立ち上げてマイグレーションを実施 DBスキーマをチェックして問題ないか確認 ※各ステートごとにlambdaを用意すると管理しづらくマイグレーション処理も15分以上かかるため、メンテナンス作業用のコンテナイメージを別途、用意しています。 2. .sync を用いてDBマイグレーション完了まで待機させる Step Functions では通常サービスを呼び出すと次のステートへ遷移しますが、 .sync を用いることでジョブが完了するまで状態遷移を待機させることができます。 "更新対象のDBリストを作成": { "Type": "Task", "Next": "DBマイグレーションを実行", "Resource": "arn:aws:states:::ecs:runTask.sync", "Arguments": { /* 省略 */ }, "Catch": [ { "ErrorEquals": [ "States.ALL" ], "Next": "更新処理の失敗を通知" } ] }, 上記のように記述することで、更新対象のデータベースリストを作成するECS Taskが終了しないと、次のステート「DBマイグレーションを実行」へ遷移しないようになります。 ジョブ完了状態のポーリングは DescribeTasks , ChoiceState , WaitState の組み合わせでも可能ですが、Step Functions は状態遷移回数によってサービス利用料が計算されるため、コスト的に優しくありません。 ただし、すべてのAWSサービスで .sync が利用できるわけではないので注意が必要です。 参考： 最適化されたサービスと Step Functions の統合 実装時に意識したこと 1. ビジュアルエディタを活用する AWS Step Functions のワークフローはJSON形式で定義する宣言型の Amazon States Language (ASL) で記述します。 シンプルなワークフローであればASLで書かれたワークフローを読むのもそこまで苦ではありませんが、分岐が複数あったり複雑なワークフローだと辛くなってきます。 そこで、役立つのがビジュアルエディタです。 Step Functions のビジュアルエディタにはデザインモードとコードモードが存在します。 デザインモードを活用することで、ワークフローの構造をビジュアルで確認することができます。 デザインモード ドラッグ＆ドロップでアクションやフローを配置してワークフローの構築ができます。 コードを書く必要がなく直感的に操作することができます。 コードモード ASLでワークフローを編集することができます。 他のStep Functionsワークフローをコピペして組み込んだりする時には便利です。 ASLの構文エラーはエディタから確認することができるので、間違いに気がつくことはできます。 2. TestState API を使い倒す ワークフローを構成する各ステートは TestState API で単体テストが可能です。 特に参照系APIの戻り値をテストしたりJSONataのような書き慣れないクエリ構文のチェックに利用します。 ただし、処理完了するまで待機する .sync やコールバックが返却されるまでStep Functionsが待機する .waitForTaskToken といったステートはTestState APIをサポートしていないため、その場合は .sync や .waitForTaskToken を外して検証します。 まとめ 本記事では、Step Functions を活用した運用トイル削減の取り組みとそこで得たTipsについて紹介しました。 少人数のSREチームにおいて、手作業による運用コストの削減は重要な課題です。 Step Functions を使用することで、以下の成果を得ることができました： 定量的効果 : 月6時間、年間72時間の工数削減 定性的効果 : ヒューマンエラーの排除と心理的負荷の軽減 組織的効果 : より価値の高い業務への時間投入が可能 特に、視覚的なワークフロー管理機能により、チーム全体での理解と保守性が向上したことは、持続可能な運用自動化において重要な要素でした。 今後も、運用業務の中で反復的に実施している作業を見つけ出し、Step Functions をはじめとしたAWSサービスを活用した自動化に取り組んでいきます。 これにより、SREとしてのCLINICSの安定性と信頼性をさらに向上させていきたいと考えています。 次回は、医療プラットフォーム本部 桶谷さん・小島さんの、「生成AI時代に向けて、開発効率10xを支えるリリース戦略の見直し」です。お楽しみに。 メドレーではエンジニアを積極採用中です！ メドレーでは、SREをはじめ「医療ヘルスケアの未来」を共に創っていくエンジニアを大募集中です！少しでもご興味をお持ちいただけましたらぜひ、ご応募お待ちしております！ 株式会社メドレー エンジニア の求人一覧 株式会社メドレー エンジニア の求人一覧です。| HRMOS hrmos.co ※カジュアル面談も大歓迎です！ご希望の際は、「その他の項目（希望記入欄）」にてその旨をご記載ください。

こんにちは、人材プラットフォーム本部CTO室の奥澤です。2025年9月、株式会社メドレーに入社して人材プラットフォーム本部へ配属されました。メドレーの人材プラットフォーム本部では既に複数のモバイルアプリを開発していますが、モバイルアプリ開発をさらに加速させていくためにジョインしました。 さて、9月に入って8月ほどの暑さはなくなり、夏の終わりを感じています。そして例年、自分にとって暑い夏の終わりと秋の始まりを告げるイベントである、DroidKaigiに今年も参加してきました！DroidKaigiは、日本国内で最大級のAndroidに関するカンファレンスです。 株式会社メドレーは、2025年9月10日から12日にかけて開催された、DroidKaigi 2025にSupporters Sponsorとして協賛しました。メドレーでは2021年からDroidKaigiに協賛しており、今年で5回目の協賛となっています。メドレーでは、DroidKaigiなどの技術カンファレンスへ継続的に協賛し、技術コミュニティを支援しています。 本記事では、DroidKaigi 2025の会場の様子と共に、印象に残ったセッションを紹介します。 会場の様子 DroidKaigi 2025は、ベルサール渋谷ガーデンで開催されました。DroidKaigi 2023から同じ会場で開催されています。今年も元気に会場にやってきました。 地下1階に設けられたコミュニケーションエリアには、協賛している各企業のブースが出展されていました。ブースを周り、各企業の話を聞いて歩くのはカンファレンスの大きな楽しみですね。それぞれの会社 / アプリの取り組みについて学び、さらに中の人に詳しい話を聞くことができるのは良いですね。 今年も気合いを入れてスタンプラリーをコンプリートしました。大量にノベルティもいただいたので、家族へのお土産になりました。全部のノベルティが嬉しいものですが、特に印象に残ったノベルティは、株式会社TVer様のタンブラー（かっこいい）、KINTOテクノロジーズ株式会社様のコースター（かわいい）、株式会社メルカリ様のキーキャップ（さっそく使ってます）でした。 セッションの様子 私がリアルタイムで聴講したセッションの中で、印象に残ったいくつかのセッションとその感想を紹介します。 共有と分離 ─ Compose Multiplatform “本番導入” の設計指針 Kotlin Multiplatform（KMP）は、ここ数年で盛り上がっているクロスプラットフォーム技術で、ロジックをプラットフォーム間で共通化することができるものです。さらに、Compose Multiplatform（CMP）を用いることで、UIも共通化することができます。KMP / CMP、あるいはクロスプラットフォーム技術において、OSの境界をどう引くか？をいかに設計すれば少人数で生産性高くアプリを開発できるのか、という点に興味を持ちました。 本セッションでは、KMP / CMPとそのエコシステムの現状・限界を見極めながら、その本番導入を進めていった過程とその結果を発表されていました。最終的に約90%のソースコードをOS間で共有することができたそうですが、ネイティブで提供できる高品質な触り心地と、ソースコードの共有によって実装効率の向上を両立できた点は素晴らしいですね。 共有と分離 ─ Compose Multiplatform “本番導入” の設計指針 Kotlin Multiplatform (KMP) は、ネットワーク通信やドメインロジックを Android / iOS で共通化し、Compose Multiplatform (CMP) はそのうえ UI までを共通化します。両者を組み合わせれば、アプリの大部分を単一のコードベースで開発できることが大きな魅力です。 ところが実プロダクトへの導入に踏み出すと ・使いたいライブラリや SDK が KMP に非対応 ・OS 固有の API を直接呼びたい ・一部の画面をネイティブ UI でリッチに作り込みたい といった理由で、 ”共有できない領域” が必ず現れます。 本セッションでは、Android と iOS のエンジニアが共同登壇し、 ・プラットフォーム間でコードのどこを共有し、どこを分離するのか ・開発速度 × ユーザ体験 を両立させる設計・実装パターン を具体例とともに紹介します。実際に CMP を採用して半年弱で Android / iOS 両アプリをリリースしたプロダクトを題材に解説します。 予定しているトピック： ・共有の最前線 　CMP + KMP 対応ライブラリの活用でどこまで共通化できるか ・分離のテクニック 　・Kotlin × Swift の DI 設計 　・KMP に非対応の SDK の安全な統合 　・CMP + ネイティブ UI のハイブリッド実装 ・両プラットフォーム視点で見る落とし穴と回避策 CMP 導入で必ずぶつかる ”共有できない領域” を見極め、必要に応じてコードを切り離すための指針をお伝えします。 2025.droidkaigi.jp スマホ新法って何？１２月施行？アプリビジネスに影響あるの？ 2025年12月18日に施行される、「スマートフォンにおいて利用される特定ソフトウェアに係る競争の促進に関する法律」、いわゆるスマホ新法またはスマホ法について、公正取引委員会の方のセッションがありました。スマホ法の趣旨、スマホ法の施行によって何が変わるのか、スマホ法の施行によるアプリデベロッパーへの影響など、わかりやすく説明いただきました。 規制対象となる指定事業者に属していないエンジニアにおいても、スマホ法の施行によって今後どのようなことが起こっていくのか？しっかり理解しておいた方が良さそうだと感じました。セッションに参加したことで興味・理解が深まりました。 スマホ新法って何？１２月施行？アプリビジネスに影響あるの？ 今年１２月に施行が予定されている新しい法律、スマホソフトウェア競争促進法（スマホ新法）。 この法律がアプリビジネスにどのような影響を与えるのか、エンジニアのみなさまにどんな関係があるのか、公正取引委員会の担当者が解説します。 例えば、 ・OS機能（通信機能等）の利用可能性の向上 ・新たなアプリストアの登場など決済手段の多様化 ・ウェブサイト等のアプリ外での商品提供の拡大 ・ソフトウェアの切替え時におけるデータ移転の円滑化 ・ユーザーによるブラウザや検索サービスの選択の促進 などなど、これから見込まれる「変化」について説明します。 2025.droidkaigi.jp Surviving Network Failures: Building Resilient Offline-First Flutter Apps モバイル端末はネットワークが不安定な場所で使われることも多々あります。ネットワークが不安定な状況においてもアプリを使い続けられることは、ユーザーの体験として非常に重要であると考えます。そのためには、「オフラインファースト」でアプリの体験を設計することが必要になり、同時にオフラインファーストな体験を実現するための技術的な戦略も描く必要があります。 このセッションでは、オフラインファーストなアプリの体験を実現するためのUX / 技術的な戦略を提案しています。サンプルコードはFlutter / Dartですが、おおまかな内容はフレームワークによらず参考にできるものでした。セッションの内容については触れませんが、オフラインファーストでアプリの体験 / アーキテクチャを設計するためのガイドラインとなるセッションだったと感じています。 Surviving Network Failures: Building Resilient Offline-First Flutter Apps What happens when your app loses internet, does it gracefully adapt, or does it leave users frustrated? In a world where connectivity is unpredictable, building offline-first apps isn’t just a feature; it’s a necessity. In this talk, we’ll explore battle-tested strategies to keep your Flutter app running smoothly, even in airplane mode. You’ll learn: Caching Like a Pro – Choosing between SQLite, Hive, Isar, or ObjectBox for local data storage. Syncing Without Breaking Things – Ensuring data consistency with background sync techniques. Handling Conflicts Gracefully – Avoiding data loss when multiple devices update the same record. Background Tasks & Work Managers – Keeping data fresh even when the app isn’t open. By the end of this session, you'll walk away with practical solutions to handle network failures, data synchronization, and seamless user experiences, whether your app is used in the subway, remote villages, or just a bad Wi-Fi zone. 2025.droidkaigi.jp 最後に 2025年9月10日から12日にかけて開催されたDroidKaigi 2025に参加してきました。Androidに関わる企業・人々が一堂に会するお祭りとして、楽しく、そして学びの多いイベントでした。主催者・スタッフ・登壇者・協賛企業など、関係者に感謝しつつ、弊社メドレーでもイベントや技術コミュニティを盛り上げていきたいと改めて思いました。 メドレーでは、カンファレンスへのスポンサーの他にも、イベントの開催などを通じて技術とコミュニティに貢献しています。 メドレーではエンジニアを積極採用中です！ メドレーではテクノロジーを活用して、医療ヘルスケアの未来をつくるプロダクトを開発しています。モバイルアプリ開発の専門性を活かした医療ヘルスケア領域の課題解決に興味がある方は、ぜひカジュアル面談にお越しください！ Flutterエンジニア／人材プラットフォーム本部 | 株式会社メドレー Flutterエンジニア／人材プラットフォーム本部（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co iOSアプリケーションエンジニア／CLINICS（総合医療アプリ） | 株式会社メドレー iOSアプリケーションエンジニア／CLINICS（総合医療アプリ）（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co Androidアプリケーションエンジニア／CLINICS（総合医療アプリ） | 株式会社メドレー Androidアプリケーションエンジニア／CLINICS（総合医療アプリ）（株式会社メドレー）の求人情報です。 | HRMOS hrmos.co

こちらの記事は「 MEDLEY Summer Tech Blog Relay 」の18日目の記事です🎉 今週はFY25新卒エンジニアの4人が連続して記事をお届けします！ はじめに 株式会社メドレーに 2025 年 4 月に新卒入社した、平林です。 医療プラットフォームの歯科診療所事業部でソフトウェアエンジニアをしており、クラウド歯科業務支援システム「Dentis」を開発しています。 皆さんは病院や歯科医院で診察を受けた後、窓口で料金を支払っていると思います。ご存じの方も多いかもしれませんが、ここで払う料金は医療機関の収入の一部に過ぎません。 残りの診療報酬は患者が加入している保険組合（保険者）から支払われることになっており、医療機関は毎月患者に行った診療をまとめた書類（診療報酬請求書、通称レセプト）を作成して支払基金（国保の場合は国民健康保険団体連合会）に請求します。 以下は、社会保険に加入している患者の診療報酬請求の流れです。 支払基金ってどんなところ？｜社会保険診療報酬支払基金 www.ssk.or.jp このレセプトをコンピューターを使って自動で作成してくれるのが、レセプトコンピューター（レセコン）です。 今回は、このレセプトについて学習するために、レセプトビューアを作ってみました。 ソースコードは以下で公開しています。 GitHub - avaice/dental-uke-reader Contribute to avaice/dental-uke-reader development by creating an account on GitHub. github.com 電子レセプトについて レセプトには、紙レセプトと電子レセプトの2種類があります。元々は紙レセプトのみでしたが、現在はそれをデータ化した電子レセプトが主流となっています。 電子レセプトはCSVライクなカンマ区切りのフォーマットとなっており、UKEという拡張子で保存されます。 以下は、一般的な電子レセプトの例です。※データは架空の情報です UK,2,13,3,1234567,,メドレークリニック,202201,0117,00 IR,2,13,3,1234567,,202201,03-1234-5678,0117 RE,4,3318,202112,歯科　太郎,1,19400808,,,20210609,1,,,29,,123456/8,,,,,,,,,,シカタロウ, HO,39141320,,２３５７２４４９,2,1279,,,,,,,, JD,1,,,,,,,,1,,,,,,,,,,,,,,1,,,,,,,,, MF,00,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, HS,,,101700101500101400101300101200101100102100102200102300102400102500102600102700104800104500104400104300104200104100103100103200103300103400103500103700,5234009,,,,,,,, SS,12,1,301001610,,,CA062,,CA045,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,57,2,,,,,,,,1,,,,,,,,,,,,,,1,,,,,,,,, (...以下省略) GO,116,155332,99 一見よくわからないデータですが、社会保険診療報酬支払基金のWebページには「オンライン又は光ディスク等による 請求に係る記録条件仕様（歯科用）」（以下、仕様書）が公開されているので、それを見ながら読み進めていきます。 電子レセプトの作成｜社会保険診療報酬支払基金 www.ssk.or.jp 1列目には「UK」と書いてあります。これはレコード識別情報です。 レコード識別情報の一覧は、以下のとおりです。 値 レコードの種類 データの一例 UK 受付情報レコード 審査支払機関・医療機関コード・都道府県など IR 医療機関情報レコード 医療機関コード・連絡先・請求年月など RE レセプト共通レコード 患者（被保険者）の名前・性別など HO 保険者レコード 保険者番号・合計点数など KO 公費レコード 負担者番号公費負担者番号など SN 資格確認レコード 負担者種別や受給者番号など JD 受診日等レコード 日別の受診等区分など MF 窓口負担額レコード 高額療養費の扱いなど HS 傷病名部位レコード 傷病名コード・部位の 歯式コード など SS 歯科診療行為レコード 診療識別・歯科診療行為コードなど SI 診療行為レコード 医科診療行為コードなど IY 医薬品レコード 診療で使用した医薬品・院内で処方した医薬品など TO 特定器材レコード 特定器材コードなど CO コメントレコード 診療識別・コメントコードなど SJ 症状詳記レコード 症状詳記（診療内容が明確でない場合などに記録する）など GO 診療報酬請求書レコード 総件数など この値によってこの行がどんな情報を含んでいるのか判別することができます。 今回はUK（受付情報レコード）だけ見てみましょう。仕様書と照らし合わせると、以下の内容であることが分かります。 値 説明 備考 1 審査支払機関 1: 社会保険診療報酬支払基金、2: 国民健康保険団体連合会 13 都道府県コード 総務省が定める都道府県コード( URL ) 16: 富山県 3 点数表種別 点数表種別 3: 歯科 他にも、1: 医科, 4: 調剤など 1234567 医療機関コード 医療機関コード (空欄) 予備エリア メドレークリニック 地方厚生（支）局長に届け出た名称 20文字を超える場合は、決まっている省略名称になる 202201 請求年月 レセプトが請求される年月。例: 2022年1月 0117 施設基準届出コード 2文字区切りで解釈される。01:補管（クラウン・ブリッジ維持管理料）17:歯科初診料 00 マルチボリューム識別情報 フロッピーディスクなど容量の少ない媒体を使用する際、レセプト情報が複数のファイルに分割されている場合に、そのファイルの順番を示す このような形で各行を読んでいくと、電子レセプトが示している内容が分かります。 レセプトの読み方がなんとなく分かったので、次は実際にこれを読み込むプログラムを作ります。 CSVを読み込んでパースする 電子レセプトはShift-JISで記録されているので、文字コードを指定して読み込みます。 const loadFile = ( file ) => new Promise (( resolve , reject ) => { const reader = new FileReader (); reader . onload = ( e ) => { const text = e . target ?. result ; if ( typeof text !== "string" ) { reject ( new Error ( "Failed to load the file" )); return ; } resolve ( text ); }; reader . onerror = () => { reject ( new Error ( "Failed to read the file" )); }; reader . readAsText ( file , "shift-jis" ); }); 読み込んだあとは、UKEデータをパースします。 CSVのパースは考慮することが多くエンジニア泣かせで有名ですが、UKEの仕様は非常にシンプルなので簡単にパースできます。 （以下は、一部抜粋です） 符号名称 図形記号 用途 コンマ , 項目の区切りを表現する 引用符 " 使用しない 改行コード \n レコードの区切りを表現する const csv = await loadFile ( file ); const receipts = csv . trim () . split ( " \n " ) . map (( line ) => line . split ( "," )); 項目の説明を表示する 行ごとのレコードと列番号を渡すと説明が返ってくるロジックを作ります。 説明情報は、社会保険診療報酬支払基金のWebページに公開されている「電子レセプトの作成手引き」を参考にします。 「電子レセプトの作成手引き」はPDFで公開されているデータですが、 markitdown を使ってマークダウンに変換し作業スペースに置くことで、CursorやClaude Codeといった開発支援ツールを活用して効率的に実装を進めることができました。 GitHub - microsoft/markitdown: Python tool for converting files and office documents to Markdown. Python tool for converting files and office documents to Markdown. - microsoft/markitdown github.com export type RecordType = { index : number ; data : string []; }; export const explain = ( record : RecordType ) => { switch ( record . identification ) { case "UK" : return explainUK ( record ); case "IR" : return explainIR ( record ); // ...省略 default : return null ; } }; 値によって説明が変わる内容もあるので、動的に説明文を作れるようにしました。 const explainUK : ((( record : RecordType ) => string ) | string )[] = [ "この行が受付情報レコードであることを示します" , ( record ) => `審査支払機関を示します。値「 ${ record . data [ record . index ] } 」は「 ${ getShiharaiKikan ( record . data [ record . index ]) } 」です` , // ...省略 ]; マスターファイルから情報を取得する UKEの中にはそのまま解釈できる内容だけでなく、診療行為コードや医薬品コードのような別のデータ（マスターファイル）を参照しないと内容がわからないものがあります。 マスターファイルや仕様は、厚生労働省がWebで公開してくれています。 診療報酬情報提供サービス shinryohoshu.mhlw.go.jp マスターファイルは電子レセプトと仕様の違うCSVで、以下のような仕様になっています。 項目間の区切り文字は「,」（カンマ）とする。 各項目の値は、モード（「数字」、「英数」及び「漢字」）に関わらず、引用符「”」（ダブルクォーテーション）を前後に付す。 最大バイトは引用符「“」を除いたバイト数であり、小数部がある値は、小数点及び小数以降の数字を含む。 ０バイトの文字列（Null）の場合は、引用符「“」を続けて記録する。 値をダブルクォーテーションで囲むとのことなので、値の中のカンマを許容する仕様である可能性があります。愚直に1文字ずつ処理します。 // const csv = 生のCSVデータ; const lines = csv . split ( " \n " ); const records : Record < string , string >[] = []; const shobyomeiMasterHeaders = [ "変更区分" , "マスター種別" , "傷病名コード" , /** 以下省略... */ ]; for ( const line of lines ) { const record : Record < string , string > = {}; let charIndex = 0 ; let columnIndex = 0 ; let inQuotes = false ; let buffer = "" ; while ( charIndex < line . length ) { const char = line [ charIndex ]; if ( char === '"' ) { inQuotes = ! inQuotes ; } else if ( char === ',' && ! inQuotes ) { // カンマ区切り、かつ引用符の外 record [ shobyomeiMasterHeaders [ columnIndex ]] = buffer ; columnIndex ++; buffer = "" ; } else { // それ以外はバッファに追加 buffer += char ; } charIndex ++; } if ( buffer . length > 0 ) { record [ shobyomeiMasterHeaders [ columnIndex ]] = buffer ; } // データベースへの保存 await saveToDatabase ( "shobyomei" , record . 傷病名コード , [ record ]); } マスターファイルは全部で20MB程度あり、毎回処理していたら時間がかかってしまうので、indexedDBに展開しました。 これで、診療行為コードや医薬品コードを基にマスターの内容を参照できるようになりました。 ここで一つ気をつけなければいけないのは、医薬品コードの情報には有効期限があるということです。 該当するレコードの診療日が、変更年月日〜廃止年月日の間であることを確認する必要があります。例えば2015年のレセプトから情報を得たいのであれば、2015年時点のマスターファイルを参照する必要があります。 そのため、時系列に合った複数バージョンのマスターを保持できる設計にするために、キーに対してデータは配列で持つようにしました。 表としてレンダリングする UKEのパーサーと情報の取得処理が書けたので、表としてレンダリングします。 type CellPosition = { x : number ; y : number }; const UKERenderer = ({ uke }: { uke : string [][] }) => { const [ activeCell , setActiveCell ] = useState < CellPosition | null >( null ); const handleClickCell = ( x : number , y : number ) => setActiveCell ({ x , y }); const isActiveCell = ( x : number , y : number ) => activeCell && activeCell . x === x && activeCell . y === y ; return uke . map (( row , y ) => ( < Row key = { `row- ${ y } ` } > { row . map (( value , x ) => ( < Cell key = { `cell- ${ x } ` } onClick = { () => handleClickCell ( x , y ) } active = { isActiveCell ( x , y ) } description = { explain ({ index: x , data: row }) } > { value } </ Cell > )) } </ Row > )); }; 実際に開発したもの 実際に開発したものは、今まで解説したコードをベースに機能や処理を付け加えています。 開発してみて 以前は、テキストエディターを使って目視でマスターファイルの内容を照らし合わせており確認作業が大変でしたが、今回作った電子レセプトビューアによって、正しくレセプトが出力されているかの確認が行いやすくなりました。 また、自分自身も電子レセプトの仕様を学んだことで、業務で行っていることが少しずつ分かるようになってきました！ おわりに 今回は、歯科の電子レセプトを理解するために、電子レセプトビューアを開発しました。 私たちソフトウェアエンジニアは、普段医療に関するシステムの話をあまり目にすることは少ないですが、意外と仕様やデータが一般にも公開されており、手軽に触れてみることができます。 この記事を読んで、医療ITに興味を持ってくださる方がいれば幸いです！ 次は、新卒エンジニア4人目の池田さんです！お楽しみに！！

この記事は 「 MEDLEY Summer Tech Blog Relay 」 15 日目の記事です。 はじめに こんにちは！人材プラットフォーム本部プロダクト開発部の小泉( @kzmkt )です。 医療介護従事者向けの求人メディア「 ジョブメドレー 」開発チームの一員として、主にフロントエンドのエンジニアをしています。 今回、2025年10月の利用規約改定に備えて、 利用規約ページを刷新 しました。 → 改定版周知のための利用規約ページはこちら ジョブメドレーは「 誰でも使える 」サービスを目指してデザインリニューアルのプロジェクトに取り組んでいます。 → 「誰でも使える」ように、アクセシビリティ向上に向けて取り組んだこと この記事では取り組みの背景、具体的な開発プロセスとソフトウェアエンジニアリングについて、プロジェクトメンバーの話も交えて紹介させていただきます。 今回のプロジェクトでは利用規約を読みやすくするために、総合的な観点が必要だったので、法務担当・外部弁護士・デザイン部・開発チームの共同プロジェクトとして進めました。 利用規約を刷新する理由 利用規約刷新の具体的な背景と課題について、事業企画室の小松さんとデザイン部の佐竹さんにお話を伺いました。 事業企画室 小松さんのコメント ジョブメドレーの利用規約は、あらゆるケースを想定した抽象的で抜け漏れのない規定が必要となります。 そうした文章はともすると、冗長で専門的な用語が多用されるため、誰にとっても読みやすいものとはいえません。 また、サービス規模にあわせて最適な状態に改定してきたものの、運営が15年にもなると複雑でわかりやすいとはいえない規約となっていました。 今回の取り組みでは、わかりづらさを解消し、誰にとってもわかりやすい利用規約を目指すため、以下のような対応を実施しました。 冗長な文章を箇条書きや表形式に変更する 条文が適用されたときの具体例を記載する 「〜を承諾するものとします」や「〜に帰属するものとします」など、法律的な言い回しを可能な限り平易なものに変更する 章立ても含めた規約の構成をすべて見直す デザイン部 佐竹さんのコメント 旧デザインの課題 デザインの視点から見た旧デザインの課題は大きく3つあります。 情報構造が不明瞭で、ページ全体の流れをつかみにくい 文字サイズや太さに強弱がなく、重要な情報を見つけづらい 装飾的な補助要素がなく、内容を直感的に理解しにくい 新デザインでの解決策 新デザインでは、 読む負担を減らし、内容を把握しやすい表現 を意識しました。 適切な余白を設け、テキストをブロック単位で整理 目次を追加し、見出しサイズを最適化することで、章や節の構造を一目で把握しやすく改善 キーワードをフォントウェイトで強調し、重要情報を直感的に理解可能に イラストを追加し、複雑な内容をサポート。長文の合間に配置することで、読解のストレスを軽減 背景色付きの注釈で補足説明や注意事項を目立たせ、必要な情報をすぐに把握できるように ジョブメドレーは2009年11月にサービスを開始しました。 サービスが成長していく中で法改正以外でも利用規約を更新し続けており、その時々では最善を尽くしてきたものの、たび重なる改定により、結果として複雑で読みにくい利用規約になってきてしまっていました。 そのため、今回の改定で全面的に見直しを行い、よりわかりやすい構成と内容に改定することにしました。 使用技術と開発プロセス ここからは分かりやすい利用規約の実現及び「 誰でも使える 」ジョブメドレーの実現に向けた、 アクセシビリティに配慮した開発 について紹介します。 ジョブメドレーにはさまざまな開発チームがあり、各チームが並行して機能開発や改善を進めています。多様なチーム構成の中では、チーム間の違いに加えて、企画者・デザイナー・エンジニアなどポジション毎でも、アクセシビリティに関する知見のレベルは様々です。 また、現在は協力会社のサポートを受けながらアクセシビリティに配慮した開発を進めており、今後のアクセシビティ対応の内製化に向けて、 ジョブメドレーのエンジニア全員が「誰でも使える」を「誰でも作れる」ようにする 必要があります。 今回は以下のプロセスで開発を行いました。 企画・仕様策定 デザイン作成 開発 デザインコンポーネント開発 画面全体の作り込み ロジックの実装 アクセシビリティレビュー QA リリース 監視 運用 今回は「 デザインコンポーネント開発 」および「 アクセシビリティレビュー 」における取り組みの一部をご紹介します。 どの画面でも変わらないアクセシビリティ品質を提供する開発プロセス 今回の利用規約ページでは、デザインコンポーネントとロジック実装を完全に分けて開発しており、デザインコンポーネント開発段階でアクセシビリティに配慮した実装を行っています。 Storybook を用いてアクセシビリティの品質が担保されたコンポーネントを開発し、それらを組み合わせることで各ページを作成しています。 アクセシビリティ勉強会でStorybookの利用方法を共有 ジョブメドレー開発チームではアクセシビリティ勉強会を実施しており、FigmaのデザインからStorybookを用いたデザインコンポーネント開発を行う際の注意点を紹介しています。 コンポーネント毎にジョブメドレーで目指すアクセシビリティが担保された状態を目標に開発しています。 利用規約ページにおける各項目要素のコンポーネントを作成 今回の利用規約ページでは、各要素に対応したコンポーネントを作成しました。 それぞれのコンポーネントを組み合わせることで、各章や注釈の構造を明確にしています。 ツールやAIによる形式レビューと人による総合的なレビュー アクセシビリティへの配慮は最終的には人の手と目で確認しなければ、本当に必要な対応ができているかを判断することができません。しかし、開発現場では全てを人の手と目で確認することは必ずしも現実的ではありません。 そこで、段階的なレビュープロセスを実施しています。 初期確認 AIによる各コンポーネントの実装およびアクセシビリティのレビュー 既存の実装と類似している箇所の事前自動チェック ページ作成時 ブラウザのアクセシビリティチェックツールによる確認 最終確認 VoiceOverやPC Talkerを用いた実機での確認 ジョブメドレー独自のルール、実際の使用感も含めた人によるレビュー この仕組みによりレビューコストを減らしつつ、 より本質的なアクセシビリティの課題に取り組める ようにしています。 AIによるレビュー ジョブメドレーではAIによるプルリクエストのレビューを行っています。 アクセシビリティ観点だけでなく、開発初期段階におけるレビューとして、既存実装との整合性や単純な実装ミスのチェックはAIに任せています。 この結果、一定の精度をクリアしたものを人間のレビューに回すことになり、負荷を減らしています。 ブラウザのアクセシビリティツールによるチェック ブラウザ拡張ツールの axe DevTools® を用いて、ページのアクセシビリティチェックを実施しています。 これにより基本的なアクセシビリティ課題は自動的に検出することができ、一定の品質を担保できるようにしています。 利用規約ページに合わせた人によるレビュー AIやツールによる自動チェックでは対応しきれない部分について、人によるレビューを行っています。 アクセシビリティに可能な限り配慮しつつ、ジョブメドレー固有のユーザビリティ要件や使用感も担保できる状態を目指してレビューします。 自動化できる部分は事前にAIやツールでチェックしているため、人によるレビューではより本質的で高度な判断が必要な部分に集中することができます。 VoiceOver・PC Talkerを用いた実機確認 実機での読み上げ、タップ操作、キーボード操作の確認を行います。 開発者用の検証ツールと実機では、読み上げや操作に差異が起きる場合があります。 利用者を想定して、実際のPCやスマホ上でも問題のない表現になっているかを改めて確認しています。 サービス体験をより良いものにするために、ウェブサービスは人間だけでなく機械が読みやすい文章にする必要があります。これを マシンリーダビリティ と呼び、読み上げツールがより適切なアウトプットを行うことができ、ユーザ体験が向上します。 アクセシビリティに配慮した開発を行う中で読み上げツールに対応した表現になるようにしています。マシンリーダビリティも担保できる形になっています。 アクセシビリティに配慮したウェブサービスを提供することで、人間だけでなく読み上げツールやAIなどの機械にも扱いやすいサービスを作ることができます。 今回の学び 利用規約の刷新を行う中で様々な気づきがありました。 アクセシビリティに配慮できているウェブサービスであるかどうかは、実際に画面がどのようにHTMLとしてマークアップされるかによって決まります。 そのため、コンポーネント作成段階からアクセシビリティに配慮した開発を進めていくことで、実際の画面を作り込むときのチェックが行いやすくなり、実装者とレビュワーのそれぞれが注力すべき箇所がより明確になります。 コンテンツページのアクセシビリティ 静的コンテンツページでの表示はシンプルですが、ただ純粋に文章を羅列するだけではなく、適切なマークアップが必要になります。 適したHTML表現を行うことで、アクセシビリティに配慮したセマンティックなWebページを作ることができます。 今回、一般的なページの開発ではあまり見かけないHTMLタグも使用しています。 HTMLタグ 説明 <small> : 附随コメント要素 HTML4.1では小さい文字を表現するものでしたが、HTML5ではスタイルの表現とは独立して、著作権表示や法的表記のような、注釈や小さく表示される文を表す仕様に変わっています。 <address> : 連絡先要素 個人、団体、組織の連絡先情報を提供していることを示しています。 利用規約の各要素に明確に意味を持たせることを意図して使用しています。 WCAG2.1 AAAへの配慮 ジョブメドレーではWCAG2.1の適合レベルAおよびAAに配慮した、Webサービス作りを行っています。 今回の利用規約の刷新において、結果的にWCAG 2.1 AAA（ 日本語版: WCAG 2.1 ）にも一部配慮したページになりました。 基準名 達成基準 対応内容 達成基準 2.4.10 : セクション見出し セクション見出しを用いて、コンテンツが整理されている。 各セクションで <h1>~<h6> タグを使用して、内容や項目を明確に示す見出しを作成 達成基準 3.1.5 : 読解レベル （ ※達成途中 ） 固有名詞や題名を取り除いた状態で、テキストが前期中等教育レベルを超えた読解力を必要とする場合は、補足コンテンツ又は前期中等教育レベルを超えた読解力を必要としない版が利用できる。 文章全体として、簡潔な文章となっており、前期中等教育レベルでおおよそ読解できる状態 ※ 今回の利用規約刷新では、達成基準 3.1.5 読解レベルを目指していますが、まだ完全に平易なものにはなっておらず改善の余地があります。 この達成基準を目指して改善を重ねていければと思います。 まとめ 今回の利用規約刷新では、「 多くの人にとって読みやすい 」利用規約ページとなるように、これまで以上に、丁寧なアクセシビリティに配慮したページを作成しました。 また、開発チームにもさまざまな知見が溜まりました。 アクセシビリティに配慮した開発に終わりはなく、今後も続いていきます。 ジョブメドレーでは全てのチームがアクセシビリティに配慮したプロダクト作りを行い、これまで以上に「 誰でも使える 」ジョブメドレーを目指して行きます。 We Are Hiring! 最後まで読んでいただきありがとうございます！ メドレーでは一緒にプロダクト開発をしていただけるエンジニア・デザイナー・ディレクターを募集中です。 少しでも興味を持っていただけましたら、ぜひカジュアル面談でお待ちしています！ 🤝 募集一覧 🗣️ カジュアル面談 「 Medley Summer Tech Blog Relay 」 16 日目は、医療プラットフォーム本部の山田さんの記事です！

この記事は「 MEDLEY Summer Tech Blog Relay 」11 日目の記事です。 はじめに こんにちは、メドレーでAI推進している人材プラットフォーム本部 VPoE の倉林( @terukura )です。 前回の記事「 AI for All - 全社でAI活用を推進する取り組み 」でお伝えした通り、メドレーでは「AI for All」を合言葉に、全社的なAI活用を推進しています。あれから約4ヶ月が経過し、プロダクト開発チームにおけるAI活用は大きく前進しました。 本記事では、メドレーのプロダクト開発におけるAI活用の現在地を、具体的な数値とともに振り返ってみます。 AI活用に関する発表では、制度としての一人n万円の支援制度、全社Cursor/Claude Max Plan導入、全社でn億円の投資などマクロな数字が注目されがちですが、本記事ではなるべく実際にどのツールをどれくらい使っているのか、具体的な利用状況を公開している例は意外と少ないため、皆様の参考になれば幸いです。 1〜2週間ごとに新しい技術やツールが登場する昨今、最適解はないと感じています。各社の状況や文化に合わせ変化に強い組織を作ることが重要だと考えています。あくまで一つの事例として、メドレーの取り組みをご紹介します。 メドレーのプロダクト開発におけるAI活用の方針 メドレーでは、以下の3つの方針を軸にAI活用を進めています。 1. ツールに縛られない柔軟な選定 特定のAIツールやサービスに固執せず、AI技術やモデルの進化に合わせて最適なツールを選定しています。例えば、コーディング支援ツールだけでも複数のオプションを並行して検証し、用途や開発者の好みに応じて使い分けています。 2. 継続的なモニタリングと改善 導入して終わりではなく、日々の利用状況や生産性向上の効果を定量的にモニタリングし、PDCAサイクルを回しています。月次でROIを評価し、効果が薄いツールは見直しを行います。 3. 開発プロセスへの深い統合 GitHub ActionsでのAIレビュー自動化、監視/アラートへのAI組み込みなど、開発プロセスの各段階にAIを統合しています。これにより、エンジニアが意識せずともAIの恩恵を受けられる環境を構築しています。 現在メドレーで利用・検証中の主なAIツール・サービス 2025年9月時点 で、メドレーでは以下のAIツール・サービスを主に活用しています。 コーディング支援ツール Claude Code、Cursor、Devin、Codex、GitHub Copilot、Gemini CLI AIモデルプロバイダー Google Vertex AI、Azure OpenAI、AWS Bedrock、Anthropic API、OpenAI API、BytePlus ModelArk ワークフロー・自動化 Dify、n8n コードレビュー支援 Claude Code Action、CodeRabbit、GitHub Copilot Review、Devin Review チャット・汎用AI ChatGPT Team、Claude Team 、Gemini その他のツール Langfuse、NotebookLM、Dia、Perplexity、Snyk、Mastra 数値でみる主な利用状況 Claude CodeについてはパワーユーザーはMax Plan、その他の利用者向けにはVertex AI経由で提供 GPT-5の登場により徐々にCodex CLIの利用も増加傾向（TeamPlan/ProPlan） 利用ModelとしてはClaude Sonnetの割合が高い、次点でOpus・GPT（Claude Max Plan ユーザー除く） Difyについては徐々に全従業員が触れ合うツールになりつつある、Model+Prompot+フローの検証利用としても拡大中 トータルで350-400万円/月　くらいがコスト観点での現在地 生産性への影響、FourKeysの変化などはまた次の機会に詳細を共有させていただければと思っています。 今後の展望 AI駆動開発（AI-Driven Development）への移行 AIが開発の中心となる新しいパラダイムへの移行を目指します。 自然言語での要件定義から実装までの自動化 AIエージェントの本格導入・開発 AIによるUI/UX設計・プロトタイピング AIによるアーキテクチャ設計の提案・レビュー CI/CDパイプラインとの深い統合 QA自動化 パフォーマンス最適化の自動実行 インシデント対応・管理の自動化 今回は主にプロダクト開発におけるAI活用の現在地点を利用状況を元に振り返ってみました。 「同じような利用状況の方」、「もっと活用している方」、「まだまだ未活用で活用方法を聞きたい方」 など ぜひ詳細など情報交換させていただければと思います。 直近はMEDLEY AI CLOUDの発表や、今回のMEDLEY Summer Tech Blog RelayでのAI関連の記事など AI関連の発信もどしどし行っていますので、ぜひ興味をもっていただければと思います。 MEDLEY AI CLOUD MEDLEY Summer Tech Blog Relay：組織で育てるAI活用テスト設計の仕組み MEDLEY Summer Tech Blog Relay：Claude Codeで「Context left until auto-compact: 15%」が出たときの対処法 MEDLEY Summer Tech Blog Relay：データ戦略グループにおけるcontext engineeringの取り組み 明日の「MEDLEY Summer Tech Blog Relay」の記事は、デザイナーの近藤さんです！ We’re hiring! メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！ カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーのエンジニア組織・AI活用についてお話します！ 「メドレーのエンジニア組織・AI活用についてお話します！」- 倉林 昭和さん pitta.me

この記事は メドレー夏のブログリレー 2025 6 日目の記事です。 はじめに こんにちは、医療プラットフォーム本部データ戦略グループの安東です。 データ戦略グループでは、データ基盤の構築から可視化、分析、ダッシュボード作成まで担い、データ活用を促進することで事業成長と医療ヘルスケアの未来に貢献することをミッションにしています。 そのため、日々データを扱う業務をしているのですが、最近チームでこんな議論がありました。 「AI を用いてデータ分析する際にテーブルのメタデータだけでなく、ビジネスロジックや過去の分析知見、議論の文脈まで理解させることが大切だよね。」 皆さんのデータアナリスト組織でも、AI を活用したデータ分析で同じような課題を感じることはないでしょうか。 当社もデータ分析の生産性を高めるため、Cursor や ClaudeCode といった AI ツールを積極的に活用しています。 その過程で、データアナリストに新たな価値提供の機会が広がっていると感じており、その鍵となるのが「 context engineering 」と考えています。 context engineering とは、 AI がタスクを達成できるように、適切な知識・ツール・求める出力形式を提供することです。（参考： The rise of “context engineering” ） 今回は、「Analytics Knowledge as Code」という形で、分析における context engineering の取り組みについてお話しします。 なお、Analytics Knowledge as Code の考えは、AWS Summit で紹介されていた「 AI Agent 時代のソフトウェア開発の型 〜 Everything as Code で叡智を伝える 〜 」の内容を参考にしています。 AI によって変わる分析の風景 生成 AI の登場で、SQL の記述、前処理、集計、可視化といったデータ分析作業の多くが効率化できるようになりました。 では、すべての分析業務が AI に置き換えられるでしょうか？ 少なくとも現時点では、分析業務にはグラデーションがあり、AI に置き換え可能な領域とそうでない領域に分かれると思います。 下図のように、分析要求の複雑性によって、データ分析における AI と人間の役割が分かれてきています。 単純なデータ抽出やレポート作成は、BI ツールによるセルフサービスで十分です。やや複雑な要件も、AI Agent で対応できつつあります。 しかし、複雑性の高い分析では ステークホルダーと議論しながら曖昧な要件を明確にし、分析の定義、解決する問いのディスカッションを通じて、意思決定を支援 することが求められます。 事業部と認識を揃えつつ、丁寧な合意形成も欠かせません。 この領域のデータアナリストには、 課題を主体的に定義し、その内容に即した最適な分析アプローチを設計する力が、核心的な価値として求められるようになってきています。 データ分析は過去・現在のコンテキストが重要 ここで重要なのは、企業での分析は一度きりの独立したタスクではないということです。過去の分析結果や現在の議論状況に依存する性質を持っています。 例えば、解約率の分析を行う際には、単に数値の変化を見るだけでは不十分です。 過去の解約要因、顧客セグメントの特性、競合サービスの動向、外部環境の変化 といったコンテキストがあってこそ、意味のある洞察が得られます。 一例ですが、メドレーのような医療ヘルスケア領域では、以下のような特殊な文脈が重要になるケースもあります： 診療報酬改定: 制度変更が事業指標に与える影響 季節性: 疾病の流行期や健康診断シーズンなど医療特有のパターン 規制環境: 関連省庁のガイドラインの変更等 業界慣習: 医療における事業者の意思決定プロセスの変化 こうした 蓄積された文脈（コンテキスト）があってこそ、質の高い分析が可能になります 。 しかし、モデルは自動的に賢くなっていく一方で、このコンテキストの整備は人間に委ねられています。 リソースは有限なので、求められる品質やビジネス要件を満たして期日までに意思決定を行うためには、AI が効率的に活用できるよう適切なコンテキストを整備することが不可欠です。 Analytics Knowledge as Code：なぜ今、この考え方が重要なのか そのため、分析ナレッジを「コード化」する Analytics Knowledge as Code の取り組みを始めています。その背景には 3 つの課題があります。 1. 分析による意思決定過程のナレッジ共有の課題 多くの分析組織では、事業部に専属のデータアナリストが配置される体制を取っているケースが多いと思います。 この体制では、各事業の データ構造の知識や成り立ち、過去の分析インサイト が、一人のデータアナリストに集中しがちです。 当社でもデータ分析チーム全体として、共通知見を蓄積することに課題があります。 2. AI には人間向けドキュメントだけでは不十分 社内 Wiki や分析ドキュメントは人間が読むことを前提としていますが、 AI が効率的に参照・活用するには構造化された情報が必要 です。 特に重要なのは、コンテキストエンジニアリングにおいて、AI に広範囲を探索させるよりも、 探索させる空間を狭くして、その空間内の情報の質を高めるアプローチの方がより期待に沿った応答を返してくれる という点です。 そのため、データ分析における AI が参照するナレッジは共通化して、品質の高い状態を管理する価値が高いと考えています。 3. 再利用性と保守性の担保 ナレッジは日々更新されていくため、継続的に更新し、信頼できる状態を担保する必要があります。 ソフトウェア開発のように、 バージョン管理、レビュープロセス、継続的な改善 を分析ナレッジにも適用することで、組織全体の分析品質を向上させることが必要になります。 コンテキストを「コード」として管理する手法 Analytics Knowledge as Code は、データ分析における知識やノウハウを、ソフトウェア開発のコードと同様に管理・共有する考えです。 管理する方法として、 GitHub リポジトリを活用したナレッジ管理 により、以下の要素を実現します。 データカタログやプロンプトエンジニアリングでは難しい領域をカバーします。 項目 内容 分析ナレッジの保守 分析結果のテンプレート化による標準化、バージョン管理による変更履歴の追跡 ビジネスロジックの反映 対象の分析がどのようなビジネスモデル、ロジックなのか理解させる お手本 SQL や分析手法の例示 AI にゼロから判断させずに、参考になる SQL や分析パターンを参照させる 過去分析の知識 過去の分析議論過程や意思決定の内容を参照させる Analytics Knowledge as Code のイメージ：GitHub リポジトリに分析ナレッジ蓄積 私たちは分析プロジェクトごとに、上図のような構成で、ナレッジを GitHub リポジトリで管理する取り組みを始めています。 これにより次回の分析では、過去のナレッジをベースに、条件の検討や定義のズレによるコミュニケーションエラーを減らすことができています。 今後、メンバーに変更があった際にも、過去の分析上の判断根拠を理解した上で分析に取り組めるようになることを目指しています。 MCP を活用したコンテキスト補完 ナレッジリポジトリと MCP を組み合わせることで、AI が分析時に過去の知見を参照できるようにしています。 この取り組みにおいて重要なのは、「人間が決めて、AI が分析を実行する」という以下のような役割分担です 項目 内容 問題定義 データアナリストがステークホルダーと協力して課題を明確化 分析実行 AI が SQL 生成、前処理、基本統計の処理、可視化といった分析ワークフローの実施 結果解釈 データアナリストが主導し、AI が集計結果から解釈を支援 意思決定 最終的な判断は必ず人間が行う このような役割分担を実現するために、AI が効率的に動作するための 意思決定過程の言語化と構造化された文脈の共有 が不可欠になります。 そのため、私たちは以下の要素も体系的に管理することを目指しています： 項目 内容 ドメイン知識 医療業界特有の制約や業界慣習 ステークホルダー情報 各事業部のビジネス戦略、ロードマップ、意思決定軸 過去のプロジェクトの意思決定履歴 会議の議事録や議論の文脈 データ定義と品質ルール テーブル構造やデータの具体的な使い方 これにより、データアナリストが持つドメイン知識を組織の資産として活用し、より質の高い分析を効率的に行えるようになることを想定しています。 AI とデータアナリストの役割分担 AI はデータ集計やクロス集計といった処理を得意とし、膨大な情報を効率的に整理することができます。 一方で、「何を解くべきか」という問いを立てたり、仮説検証の結果をどう意思決定につなげるかといった部分は、人間だからこそ担える役割 です。 単純な集計や事象確認は AI に任せることでスピードと効率を得られますが、複雑なテーマでは過去の分析や議論、外部環境を踏まえて設計し、ステークホルダーと議論しながら最適な進め方を探る必要があります。 ときには分析にかけるコストと成果を比較し、データ分析以外の手段を選ぶ判断も求められます。 つまり、AI は「効率的に分析を実行する力」、データアナリストは「問いを設定し意思決定へ橋渡しする力」を発揮することで、それぞれが補い合いながら最大の価値を生み出していく と考えます。 AI × 人間のベストな協働を目指して Analytics Knowledge as Code は、こうした新時代のデータアナリストに求められる能力を組織レベルで実現するための取り組みです。 LLM のモデルは今後も性能が向上していきますが、コンテキストの整備は組織が担う必要があります。 AI エディタや GitHub Copilot などのツールにより、従来はエンジニアの専門領域だったコードやリポジトリの管理の障壁は大幅に下がっていると感じています。 「なぜそれが必要なのか」「どう組織の価値に繋がるのか」 を理解し、積極的に取り組む姿勢があれば、どのようなデータ分析組織でも始められると思います。 AI が正しく・早くデータ分析を遂行するための context engineering の整備が、これからのデータ組織に求められる役割の一つと言えるでしょう。 メドレーでは今後も、医療・ヘルスケア領域における課題解決に向けて、こうした AI × データ分析の発展に取り組んでいきます。 同じような取り組みを検討されている組織の方々と、ぜひ知見を共有できればと思います。 We’re hiring! メドレーの医療プラットフォーム本部のデータ戦略グループでは、AI 時代の新しいデータ分析にチャレンジしたいデータアナリスト・データエンジニアを募集しています。Analytics Knowledge as Code の実践や、医療ヘルスケア領域でのデータ活用にご興味をお持ちの方は、ぜひお気軽にお声がけください！ 参考 The rise of "context engineering" Header image from Dex Horthy on Twitter. Context engineering is building dynamic systems to provide the right information and tools in the right format such that the LLM can plausibly accomplish the task. Most of the time when an agent is not performing reliably the underlying cause is that the blog.langchain.com pages.awscloud.com pages.awscloud.com Medley Summer Tech Blog Relay 7 日目は、人材プラットフォーム本部の山邉さんの記事です！

はじめに こんにちは。医療プラットフォーム本部 プラットフォーム開発室の島谷です。メドレーでは 2019 年から新卒エンジニアの採用を続けており、毎年新卒向けエンジニア研修を実施しています。 本記事では、2025 年に実施した新卒研修の設計思想とプログラムの全体像をご紹介します。メドレーで働くことに関心のある学生の方はもちろん、私たちの開発文化に興味のあるエンジニアの方にも、メドレーという会社の雰囲気が伝わる内容になれば幸いです。 新卒研修の目的 私たちが大切にしているのは、単なるスキルの習得にとどまらず、「課題にどう向き合うか」「どのように学び、成長していくか」といった姿勢やマインドセットを身につけてもらうことです。 新卒研修のミッションは、エンジニアとして必要な基礎技術と、問題解決に欠かせない考え方を習得し、配属後に高い成果を発揮するための土台を築くことにあります。研修では「技術的な基礎力」と「問題解決力」を重点的に養い、配属後すぐに開発を進められる状態を目指します。 もっとも、研修期間だけで一人前のエンジニアになることは難しく、だからこそ長いキャリアを通じて自ら成長し続ける姿勢が欠かせません。そうした背景があるからこそ、私たちはスキル以上に「成長し続けるための姿勢やマインドセット」を大切にしています。 研修の全体像 今年の新卒研修は、大きく 4 つのステップで構成されています。 まず社会人として必要なビジネススキルとマインドを身に付け、技術的な基礎を作り、そのうえで実務としての開発を体験し、最後に成果発表会で振り返りを行い今後の成長へつなげる。学びを段階的に深めていく一連の流れを設計しています。 期間と研修全体の流れ HC 研修、外部研修 人事部が実施する内製の HC（Human Capital） 研修と、外部研修を実施しました。HC 研修では、社会人に必要な基本動作（報連相や PDCA）やマインド（ニーズを理解しニーズに応える）の基本を習得してもらい、外部研修では、より体験的な演習を通じて社会人としての自覚を持つきっかけとしました。 基礎研修 エンジニアに求められる 横断的な基礎知識の習得、深く学び続ける姿勢の醸成、チームで成果を出すためのコミュニケーション能力の向上 を目的としています。 フロントエンド（TypeScript/React）、バックエンド（Ruby on Rails）、インフラやミドルウェア（データベース、AWS）など幅広い領域を実践形式で扱いました。 加えて、CTO・VPoE による事業説明や、メドレーでエンジニアとして働くうえでの心構えを学ぶセッションも実施。QA チームやデザインチームからは、それぞれの取り組みを共有してもらい、組織全体での開発の在り方についても学んでもらいました。今年は新たな取り組みとして、AI 活用に関する講義も行っています。 VPoE 山﨑さんによる講義の様子 事業部 OJT、開発 OJT 事業部 OJT では、複数の事業部でビジネスの理解を深め、現場業務を体験します。現場社員とのコミュニケーションを通じて、エンジニアへの期待やその期待の裏側にある状況の一端を理解し、顧客志向を育みます。 開発 OJT では基礎研修で身につけた知識やスキルを実際の開発現場で活かすフェーズです。既存プロダクトの開発チームに加わり、実務としての開発を体験します。 成果発表会 研修の集大成として、これまでの学びや開発 OJT での取り組みを整理し発表してもらいました。 メンター制度 研修を支える仕組みとして、今年も一人ひとりにメンターをつける「メンター制度」を実施しました。研修本体での学びを補い、成長をより加速させることを目的としています。 研修期間中は毎日、日報を書いてもらっています。その日取り組んだことや学んだことを弊社の行動原則（ Our Essentials ）に基づき整理し、読み手を意識した文章にまとめることがルールです。日報はメンターが必ず目を通し、毎日フィードバックを行いました。やりとりの内容は、技術的な疑問点への対応だけでなく、課題への向き合い方や物事の捉え方といった長期的な成長につながる視点を与えることを意識してもらっています。短期的な知識の提供ではなく、将来にわたって役立つ考え方を養うことを重視しました。 さらに、週次では 1on1 を実施し、振り返りの場を設けました。目標や課題を言語化し、メドレーの行動規範の観点から自らの振る舞いを点検。翌週に試す具体的な一手へと落とし込むことで、実践的な成長サイクルを回しました。もちろん、真面目な内容だけでなく、砕けた相談も自由にできる場とし、安心して取り組める環境づくりも大切にしています。 日報に対するフィードバックの様子 研修の詳細 HC 研修、外部研修 HC 研修では、社会人に求められるビジネスマナーやキャリアマインド、ロジカルシンキング、コミュニケーション能力などのポータブルスキルを学びました。座学だけでなく、ワークショップを行うことでメドレーグループの他職種の新卒とも交流も行いました。最終日はチーム対抗の寸劇を行うことで、一人ひとりの発言力を高め、一体感を生み出すことができました。 外部研修では、講師が顧客役を演じたり、チームを企業に見立てた競争環境で取り組んだりと、実際の現場に近いハイプレッシャーな状況を体験しました。その中で、適切なコミュニケーションやチームワークの大切さを実感し、成果につなげるプロセスを学ぶことを目指しました。 基礎研修 基礎研修は、実際にプロダクト開発に携わっているメドレーのエンジニアが、教材づくりから講師までを担当します。単なる知識の習得にとどまらず、判断の背景や根拠を言語化し、他者に伝わる形で残すことまで含めて学ぶことを大切にしています。 全体を通して繰り返し伝えられていたことは、「課題を終わらせること自体を目的にしない」ということです。わからない点をそのままにせず、ドキュメント・実装・計測結果を往復しながら自分の言葉で理解し直す。この姿勢を身につけることが、研修を通じて最も大事にしている部分です。 ここでは主要な研修内容を紹介します。 TypeScript/ React この研修では、フロントエンド開発の基礎として TypeScript と React を扱いました。TypeScript の型システムなどの言語仕様を理解したうえで、React のコンポーネント設計、状態管理、フック　などの基礎を学びます。 演習課題は Pull Request 形式で提出し、背景や選択肢、判断理由を文章にまとめたうえでコードレビューを受ける流れとしました。これにより、単に技術を学ぶだけでなく、技術を深く掘り下げる姿勢や、GitHub を使った開発フロー、レビューを通じたテキストコミュニケーションを実践的に身につけることを狙いとしています。 データベース（DB） 次に、データベースの基礎を幅広く学びました。テーブル設計や ER 図、リレーションの理解に加え、実際にクエリを書く演習として「クエリ 100 本ノック」に挑戦。WHERE や JOIN といった開発や分析で頻出する構文を身につけました。さらに、クエリ実行計画の読み方やインデックス設計など、パフォーマンスチューニングにも取り組みました。長期的な保守性や変更容易性、パフォーマンスを意識しながらデータベースを扱うための基礎を、実践的に学ぶ内容です。 アプリケーション開発実践 フロントエンドとバックエンドをつなげた実践的な開発演習として、Rails on Rails で API を実装し、React で SPA（Single Page Application）を構築する研修を行いました。フードデリバリーサービス（Uber Eats のようなアプリ）を題材に、決められた要件定義から設計、開発、テストまでを一気通貫で経験します。 ここでは、TypeScript/React 研修で身につけた基礎を応用しながら、実際にプロダクトとして動くアプリケーションを作り上げることに挑戦しました。仕様の整理からテスト設計までを通じて、フロントエンドとバックエンドを横断的に理解し、開発に必要な実践力を養うことが目的です。 Docker / AWS 最後に、インフラ領域の基礎として Docker と AWS を扱いました。メドレーでは AWS を中心に利用しているため、実際にアプリケーションを AWS 上にデプロイし、動作させるところまでを体験します。可用性やスケーラビリティを考慮したシステム構築に加え、ログ、監視、アラート設定といった運用面も含めて一通り設定。さらに簡易的に負荷をかけ、スケールアウトやアラートが正しく機能するかを検証しました。単に作るだけでなく、安定的に運用できる状態にすることの重要性を学ぶハンズオンとなっています。 事業部 OJT、開発 OJT 基礎研修を終えたあとは、現場社員から研修を受ける事業部 OJT に取り組みました。事業部によって取り組む内容は異なりますが、市場環境やミッション、今後の方向性を理解することから始まり、Sales や Customer support の業務の一部を体感します。 その後は、既存プロダクトの開発現場に加わり、実際の開発を体験する OJT に取り組みました。ここでは、抽象度の高い課題に対して自ら問題を整理し、解決に向けた手順を考え、周囲と協調しながら前に進める力が求められます。 開発の過程では、リリースに至るまでの一連のプロセスを経験します。わからないことを適切に言語化して周囲に伝え、協力を得ながら課題を乗り越えることも重要なポイントです。 今年の OJT で取り組まれていたタスクをいくつかピックアップしてみます。 デザインシステムの MCP サーバー構築 顧客向け管理画面の UI/UX 改善 電子カルテにおける書類作成機能の改善 患者向け通知機能の UX 改善 タスクを進める中では、先輩エンジニアから様々な観点でフィードバックを受けます。これまで自分になかった視点や考え方に触れることで、新卒メンバーは大きな学びを得ていた様子でした。 成果発表会 研修の締めくくりとして行ったのが成果発表会です。ここでは、研修や OJT を通じて学んだこと、自身の成長・変化を自分の言葉で整理し、周囲に伝える力を養うことを目的としています。単に振り返るだけでなく、学びを言語化して共有することで、個人の経験をチーム全体の資産へと昇華させる場でもあります。 当日は、CTO や VPoE、メンター、配属先のマネージャーなど、研修に関わった多くのメンバーが参加しました。 新卒の皆さんは緊張した面持ちでしたが、先輩たちから温かいフィードバックや応援の言葉が寄せられ、会場は和やかな雰囲気に包まれていました。 各 VP の皆様を始め、関わった方々からコメントいただきました まとめ 研修という限られた期間の中で、一人前のエンジニアとしての力をすべて身につけることは容易ではありません。だからこそ、この期間を通じて「これから成長していくための土台」を築いてもらうことを大切にしてきました。本番はここから始まります。 新卒の皆さんには、これからは仲間として実際の開発現場で活躍しながら、さらに経験を積み重ねていくことを期待しています。私たちのミッションである 「医療ヘルスケアの未来をつくる」 を実現するために、それぞれが力を発揮し、共に歩んでいけることを心から楽しみにしています。 We’re hiring! サマーインターン参加者募集中！ メドレーでは、この夏に開催するエンジニア向けサマーインターンの参加者を募集しています。 実際のプロダクト開発を体験しながら、エンジニアとしての成長につながる機会を提供します。 「まずは話だけ聞いてみたい」「雰囲気を知りたい」という方に向けて、カジュアル面談も実施しています。少しでも興味をお持ちの方は、お気軽にご応募ください。 募集はこちら サマーインターン（エンジニア新卒） / 株式会社メドレー 株式会社メドレーはサマーインターン（エンジニア新卒）を採用しています。 open.talentio.com 中途採用も積極募集中！ また、エンジニアをはじめとした中途採用も積極的に行っています。 ヘルスケアの未来を一緒につくる仲間を幅広く募集していますので、ぜひこちらもご覧ください。 中途採用の募集一覧はこちら 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

この記事は メドレー夏のブログリレー2025 5日目の記事です。 はじめに こんにちは！メドレーでDevRelをしている重田です。 突然ですが、転職先を探す時に実際に働く環境や雰囲気って気になりますよね？ この記事では、メドレーのエンジニアが普段どんな環境で仕事をしているのかを写真メインでご紹介します！ 「メドレーのオフィスで働きたい！」「働くイメージが持てた！」と思っていただけたら嬉しいです🙌 では、早速オフィスツアースタートです📣 🏢 私たちが働くオフィス 私たちのオフィスは日比谷線 六本木駅直結の六本木ヒルズ森タワーの12階と13階にあります。 詳細は以下記事でご紹介しています🙋‍♀️ メドレーオフィス（13階）へのアクセスと入館方法のご案内 [六本木ヒルズ森タワー]メドレーのオフィスを初披露 🏙️外観 六本木ヒルズ森タワーは54F建て、高さ238メートルの超高層オフィスビルです。 上を見上げる高さで、たまに見ると「おお〜〜都会だ！」となり背筋が伸びます。笑 🏥13階 エンジニアの中でも医療プラットフォームのプロダクト開発エンジニアやコーポレートITのメンバーが13階で働いています。 エントランス（受付） 13階のエントランスは清潔感のある白の壁に温かみのある木目調の床です。 憩いスペース 約100席と、広々したスペースです。テーブル席の他、ソファもあるのでゆったりと過ごせます。 カウンターには賞状などが飾られています。 🏥12階 エンジニアの中でも人材プラットフォームのプロダクト開発エンジニアが12階で働いています。 憩いスペース こちらは今年の春に増設されたスペースです！ ランチだけではなく、1on1やチームミーティングでも大活躍のスペースです。 ボックス席にはディスプレイが付いており、チームミーティングの際に役立ちます。 ゆっくりしたいときはこの席がおすすめです🍵 東京タワーを眺めて仕事ができるのは六本木、そして12階に位置する特権です🗼 憩いスペース入口には弊社プロダクトを体験できるコーナーがあります。 また、自動販売機2台・コーヒー販売機2台・食品自動販売機1台・冷蔵庫が完備されています☕️ 小腹が減った時の救世主🙏コンビニに行くのが面倒な時に大活躍です！ 持参/購入したお弁当を温められるのも嬉しいポイント💡 🏥共通 会議室 会議室は50室以上あり、来客専用・社内専用の会議室が分かれています。 ✨メドレーのカルチャー「クリーンデスクポリシー」に込められた想い メドレーが大切にしているカルチャーのひとつに「クリーンデスクポリシー」があります。これはデスクの上には仕事道具以外置かない、帰宅時にはモニタ・キーボード・マウス以外は全て片付けるというルールのことです。 「クリーンデスクポリシー」は代表の瀧口が 「佐藤可士和の超整理術」 という本から影響を受け、創業時から大切にしているカルチャーです。なぜ「クリーンデスクポリシー」が大切なのか、瀧口が社内で共有している資料から引用してご紹介します。 整理整頓には、視点が必要です。複雑なものであれば、それぞれの因果関係を見抜き、何が大切なのかの優先順位をつけることが必要です。「頭で理解しているつもりのこと」と「身体に染み付いて実践できること」には大きな隔たりがあります。実践への近道は、たった一つの象徴的なことを徹底することではないでしょうか。 例えば、この記事 「日本電産が赤字会社を速攻で再生できたワケ」 の「組織体質を変える一番の早道は」を読んでみてください。整理・整頓・清潔・躾（自主的な）を徹底して、営業回数を増やせば成功すると書いています。 そもそも仕事机は、仕事をするためのものです。クリーンデスクというのは整理整頓ができる組織であることの象徴です。このような背景で、クリーンデスクポリシーは僕にとって、大切にしたい考え方なのです。 実際、社員の机は常に整理されています。 また、過去にも「クリーンデスクポリシー」に触れているのでぜひご覧いただけると嬉しいです！ [六本木ヒルズ森タワー]メドレーのオフィスを初披露 📚スキルアップ支援やライフステージに合わせた柔軟な働き方を実現 この記事では主にエンジニアの制度をご紹介します！ 支援制度 社内勉強会支援 社内で勉強会を開催する際の飲食補助が出ます！ 書籍購入の補助 会社の費用で購入可！ ※資産管理の観点から電子書籍は除く 資格取得支援 AWS認定試験・Ruby技術認定試験を会社の費用で受験可！ ※一定条件あり カンファレンス参加費用の補助 RubyKaigi などの外部カンファレンスへ会社の費用で参加可！ 制度を利用する際は、以下のようにSlackで申請をしています。 希望PC・モニター・アーロンチェアの貸与 エンジニアの方には希望PCとモニターが貸与されます。 基本的にはスペックも自由に選べます🙆‍♀️ 湾曲型モニター また、希望者にはアーロンチェアも用意しています。 アーロンチェア 働く環境 よくある質問をもとにご紹介します！ Q. 勤務時間は決まっていますか？ A. 開発職では裁量労働制を採用しており、多くの社員は事業部の稼働時間に合わせて10:00～19:00で勤務しています。 一方で、子育て中の社員については、勤務時間中に一時的に離席するなど、個々の状況に応じた柔軟な体制をとっています。 Q. 出社とリモートの頻度はどのぐらいですか？ A. エンジニア/デザイナーの場合は週2出社、週3リモートをベースにしています。 こちらも勤務時間と同様、体調やご家庭の事情など、柔軟に対応できる体制になっています。 Q. キャリアロールはどのようになっていますか？ A. 「スペシャリスト」と「マネジメント」の2つに大別されます。事業責任者のロールも存在しますが、役職ではなく、一つのロールとして位置づけています。 Q. 担当するプロダクトは決まっていますか？ A. エージェントからのご紹介時・スカウトをお送りする際などにプロダクトを限定している場合もありますが、基本的には選考を通じて皆様のご希望や志向、スキルスタックなども合わせてご提案・ご相談しながら決めています。 イベントでも大活躍のオフィス メドレーでは定期的にイベントを開催したり、オフィスを他社様や外部コミュニティのイベント会場として提供したりしています。 こちらは5月にリンケージ社とヘンリー社と開催したイベント、 HealthTech Meetup の様子です。 Roppongi.rb 、 Omotesando.rb の会場としても定期的にご利用いただいています🙌 🍀最後に 最後までご覧いただきありがとうございました！ メドレーで働くイメージはつきましたでしょうか!? 直近では、以下のイベントを開催予定です！ 少しでもご興味のある方は、ぜひイベントを機にオフィスにいらしてください！ご参加お待ちしております✨ 9/4(木)19:30 Omotesando.rb#113 9/5(金)19:00 【有料プランユーザー限定×オフライン】MagicPodユーザーミートアップ We’re hiring 最後まで読んでいただきありがとうございます！ メドレーでは、一緒に働く仲間を大募集中です👫 少しでも興味を持っていただけましたら、ぜひカジュアル面談でお待ちしています！ 🤝 募集一覧 🗣️ カジュアル面談 Medley Summer Tech Blog Relay 6 日目は、医療プラットフォーム本部の安東(Andō)さんの記事です！ それでは良い週末をお過ごしください！