はじめに こんにちは！ 人材プラットフォーム本部プロダクト統括部プロダクト開発部アカデミー開発グループ所属の城間（シロマ）です。 私は 2024 年 4 月に新卒エンジニアとして入社し、現在はオンライン動画研修サービス「 ジョブメドレーアカデミー 」の新規プロダクト開発に携わっています。 先日、5 月 23 日、24 日に東京都千代田区のベルサール神田にて開催された TSKaigi 2025 にメドレーは Silver Sponsor として協賛しました！ TypeScript をテーマにしたこの大規模なカンファレンスには、多様なバックグラウンドを持つ TypeScript エンジニアが全国から集結。 惜しくもブースの抽選には外れてしまいましたが、私も含め弊社からは数名のエンジニアが現地参加し、多くの素晴らしい出会いと学びがありました。 今回は、当日の会場の様子や印象に残ったセッション、そして今、私が感じていることを中心にご紹介します！ 会場の熱気と「型にとらわれない」エンジニアたちの交流 今年の TSKaigi 2025 は 2 日間とも天候に恵まれ、 61 もの企業スポンサーと「TypeScript を扱う型にとらわれないエンジニア」が集結し、会場は終日、熱気と活気に満ち溢れていました。 場内の様子 スポンサーボード 2 日間に渡り、合計 3 会場でセッションや LT が盛んに行われ、時には立ち見の人が出るほどに盛況していました。 参加者同士でテーマに対してトークする OST（Open Space Technology） や、夜の豪華な懇親会では、セッションでは聞けないような深掘りした技術の話や、各社の開発文化に関する交流が盛んに行われ、当日はおよそ 50 名以上のエンジニアの方々と色々なお話をさせていただきました。 OST のテーマ 懇親会の様子 TypeScript ケーキ また、今回参加者に配布された公式グッズは、TSKaigi のオリジナル T シャツやトートバッグに加え、各企業が工夫を凝らした遊び心あふれるグッズで盛りだくさんでした。 特に、今回ブース出展のあった 19 社全てを周るスタンプラリー では、全てのスタンプを集めることで豪華景品が当たる抽選に参加でき、会場の賑わいに一役買っていました。 公式ノベルティ（一部） スタンプラリー 印象に残ったセッション：AI エージェント全盛の時代と TypeScript の可能性 どのセッションも非常に興味深く、時には理解が追いつかないほど最先端の内容でしたが、特に今の私が行う開発と照らし合わせて印象に残ったセッションをいくつかご紹介します。 Day1: AI Coding Agent Enablement in TypeScript 引用元: AI Coding Agents Enablement in TypeScript - Speaker Deck 概要 このセッションでは、人間による介入を最小限に抑え、AI エージェントが大規模な作業をどのように「自走」して実行させるかについて深く掘り下げられました。 なぜ自走が難しいのか？その主な要因は AI エージェントが「任意の TypeScript」のようなあまりにも広い「解空間」で動くため、精度が低くなってしまうためです。 すなわち AI エージェントの精度を高めるためには 「可能な限り解空間を絞る」 ことが基本方針であり、会社やプロジェクト固有の規約、ドメイン知識、デザインなどに基づいて適切に制約を与える重要性が何度も強調されていました。 その解空間を絞る具体的なアプローチとして 「コンテキスト注入」 と 「機械的検査とフィードバック」 の 2 つが挙げられました。 コンテキスト注入 : ドキュメント、規約、ドメイン知識などを LLM にインプットし、「解空間の定義」を与えること。特に TypeScript コード自体をドキュメントとして育てることが、コンテキスト注入に役立つ。 機械的検査とフィードバック : LLM が生成したコードが定義された解空間から外れていないか、型チェック、Linter、自動テストといった古典的な手法で検査し、NG の場合はエージェントにフィードバックして解空間へと押し戻すように促す。Linter は次にやるべきアクションを提示しやすく、決定的である点が非常に有効である。 また、TypeScript 開発における型の役割についても興味深い見解がありました。現状、型によってコード生成の精度が上がるという定量的な根拠はまだないものの、「解空間に押し戻す」ためのエージェントへの入力（フィードバック）としては役立つ可能性は大いにあるとのこと。AI はまだ高度な型解決が苦手なので、人間がドメインモデルや関数のシグネチャ（型定義）をしっかり書き、その後の実装をエージェントに任せるアプローチが有効であるという話は、非常に現実的で納得感がありました。 最後に、 「エコシステムの未来 - Speed is King」 という言葉が印象的でした。これは、AI エージェントのコード生成が加速すると、開発プロセス全体の速度がボトルネックとなることを示唆しています。具体的には、人間がコードを 30 分かけて書く時代には 1 分程度の静的解析は許容範囲でしたが、AI が同じコードをわずか 30 秒で書くようになると同じ 1 分間の静的解析は AI の作業時間に対して相対的に非常に長く、無視できないボトルネックになるということです。さらにクラウド型エージェントではチャットごとにコンテナが作成される仕組みが主流であり、その際にパッケージマネージャの速度がボトルネックになります。また、AI エージェントによるコード生産量が爆発的に増加すれば、デプロイの機会も増えるためビルド（バンドラー）の速度もボトルネックとして顕在化し、加えて将来的に LLM がコードを生成するタイミング（デコーディング時）ごとに型制約を守ろうとする「制約付きデコーディング」のようなアプローチが進めば、型チェッカーがボトルネックになる可能性も指摘されていました。故に、ツールチェイン全体の高速化が今後より重要になるという示唆は、将来的な開発環境を考える上で非常に重要な視点だと感じました。 Day2: TS 特化 Cline プログラミング 引用元: tskaigi.mizchi.workers.dev 概要 このセッションでは、LLM を活用した「Cline Agentic Coding」の全般について、特に TypeScript に特化した実践的なプロンプトのコツが紹介されました。 まず冒頭に うまくいくうまくいくプロンプトのコツ として、以下が挙げられていました。 書きすぎない（再現性ある範囲で詠唱破棄） 執拗に出力例を例示する 両立条件の矛盾を避ける 規模感に合わせて厳しくする また特に強調されていたのは、 テスト駆動開発（Test Driven Development） の重要性です。コード生成時に対応するユニットテストを常に生成し、コード修正時にはテストがパスすることを確認することで、AI エージェントの自己修復能力を高め、放置しても完成する高品質なコードに繋がるとのことでした。 その他にも、次のような実践的なプロンプトの一例が紹介されていました。 コメントによる自己記述 : 各ファイルの冒頭にコメントで仕様を記述することで、再修正時のコード解釈の一貫性を保つ In Source Testing : 実装と同じファイルにユニットテストを書くことで、コメント・実装・テストを三位一体で管理する types.ts にドメイン型を集約 : 中規模以上のプロジェクトでは src/types.ts にドメインモデルを集約し、SSoT（Single Source of Truth）とすることで、ファイル間の整合性を保ち read_file の頻度を減らす TS + 関数型ドメインモデリング : 状態の発散を抑えるために class を使わず関数による実装を優先し、代数的データ型でドメインをモデリングする ファイル配置規則の明記 : モノレポなどのファイル配置規則を明記することで、タスクごとのエージェントの推測コストを減らす 詳細指示を docs/*.md に分割 : 大規模プロジェクトでは無関係な指示によるノイズを減らすために、詳細な指示をドキュメントファイルに分割し、必要に応じて参照させる カバレッジに基づくテストの自動生成 : vitest でカバレッジを計測し、最もカバレッジが上がるテストコードを AI に考察・追加させる 機械的なマイグレーション : lodash の削除や類似 API を持つライブラリへの置き換えなど、面倒なマイグレーション作業を AI に自動化させる URL を読む能力 : URL の内容を読み込ませ、要約・保存させることで、Deep Research 的な挙動を可能にする 一方で、 うまくいかないプロンプト のパターンもいくつか示唆されました。 型だけで設計しようとする : ほぼ確実に無視され、抽象的な設計能力は期待できない 非同期例外処理が下手 : 思考停止気味に try-catch で握り潰しがちで、大規模開発で破綻の原因となる 環境構築が下手 : ゼロショットでの環境構築は発散しやすく、手数が仇となり環境を破壊する可能性がある モジュールインターフェースが発散 : 実装次第で全て export してしまい、モジュール間の契約が肥大化・破綻する 「ある」のがよくない（チェーホフの銃の法則） : 無関係なリソースを読み込ませると、それを使うことに固執し、大規模コードではノイズになる デバッグログを食いすぎる : 自身が生成したプリントデバッグでコンテキストウィンドウを消費し、デバッグコードを放置しがちである 結論として、現状の LLM はコーディングが下手であり、低品質なコードで設計が破綻し自滅する傾向があるとの見解でした。特に、リファクタリングの指針がなく、不要コードの判定やモジュール視点での API 設計が苦手で、ユーザー側でリファクタリングしても元の低品質なコードに書き戻すこともあるという少し厳しい評価が下されていました。 しかし TypeScript と LLM の組み合わせには良い点も多く、GitHub の公開コードが豊富で学習量が多いこと、安全性よりも表現力を選んだピーキーな型システムが自然言語と対応した型のモデリングをしやすいこと、豊富な静的解析手段とユーザー層の厚さがあることなどが挙げられていました。 現時点でのベストプラクティスとしては、PoC/プロトタイプのコード生成（1 ファイル完結 800 行以内が目安）に活用し、人間によるインターフェース設計、失敗パターンのプロンプトへの反映、成功するパターンのドキュメント化、そしてこちらでも Lint ルールの整備についての言及がありました。 そして最後にテスト駆動開発や LLM の得意領域・発達段階を予測する技術、プロンプトエンジニアリングの重要性の増加など Agentic Coding によるプログラミング自体の変質と不変である点について説明され締めくくられました。 感想 これらのセッションを通して、私が携わる新規プロダクト開発において、 実践できている部分 と 改善の余地がある部分 が明確になりました。 実践できている点として、全社的に積極的に利用している AI エディタ「Cursor」のプロジェクトルールや自立型 AI エージェント「Devin」の knowledge には、プロジェクトごとに解空間を明確にするコンテキストを与えています。これは、「AI Coding Agent Enablement in TypeScript」で述べられていた「コンテキスト注入」と「解空間を絞る」という考え方に合致していると感じました。また、コードと仕様を記述したドキュメントを同じリポジトリ内で管理し、開発を進めている点も、AI へのコンテキスト注入に貢献していると言えるでしょう。 開発フローにおいても、AI の特性を踏まえた工夫を凝らしています。「AI Coding Agent Enablement in TypeScript」で言及があった「3 回くらいループした末に any とかキャストで誤魔化しがち」という点に対し、例えば API 開発では、まず仕様やテストケースのドキュメントをコードベースと同じファイル内に記述し、次に Request や Response Body を zod を用いて厳密に型を記述します。これらをエンジニアがレビューした後、テストデータのセットアップや記法などをエンジニアが整え、残りを AI で実装を進めます。さらにアプリケーションコードの実装においても、用意したユニットテストが通過するという制約の元 AI に実装させることにより、型解決などに AI エージェントが費やす時間が最小化され、 実装フェーズの開発工数を大幅に短縮することに成功 しています。 mizchi さんのセッションで言及のあったテスト駆動開発（Test Driven Development）のスキルは今後もより重要になっていくでしょう。しかし、もう少し先の未来では、弊社メドレーが大切にしている価値観（Our Essential）の一つである「 ドキュメントドリブン 」に倣い、 ドキュメントドリブン開発（Document Driven Development） のスキルがより重要になっていくのではないか、と私は考えています。 具体的なイメージ さらに「Speed is King」の思想を体現するために、Linter と Formatter には Biome、パッケージマネージャーには Bun を採用するなどツールチェインの速度にはかなりシビアな意思決定をしており、より AI エージェントが生産的に活動できるような体制を整えています。 一方で、 改善の余地がある点 も明確になりました。特に双方のセッションで強調されていた「機械的検査とフィードバック」の継続的な改善、すなわち Linter については開発初期から現在に至るまであまり積極的に更新できていないと痛感しています。AI に与えるフィードバックをその場での単発のもので終わらせるのではなく、（人間と同じように）再発防止策を考えさせるように Linter を定期的にアップデートし、より決定的で高速に AI エージェントが機能するような環境をより一層整備していきます。 さいごに TypeScript の可能性を肌で感じ、熱意ある仲間たちと出会い、技術への情熱を改めて確認できた素晴らしいイベントでした。 メドレーは今後も TSKaigi だけでなく、他の技術イベントやコミュニティの発展を積極的に支援し、参加、貢献していきます。 過去にスポンサーとして協賛した技術カンファレンスの参加レポート記事はこちら！ RubyKaigi 2025 参加レポート - Platinum Sponsor として協賛しました！ | MEDLEY Developer Portal はじめに こんにちは！ 人材プラットフォーム本部プロダクト開発室 第一開発グループ所属の山下です。 メドレーには今年2月に入社したエンジニアで、日本最大級の医療介護求人サイト ジョブメドレー の開発を担当しています。 メドレーは 4 月 1... developer.medley.jp pmconf 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは。医療プラットフォーム本部で Product Manager をしている佐藤です。2024 年 5 月にメドレーにジョインし、医療機関向けプロダクト開発に奔走しています。社内では ”papa”、家では”おじさん”と呼ばれ可愛がら... developer.medley.jp JSConf JP 2024に プレミアムスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは！人材プラットフォーム本部で技術広報兼エンジニア採用をしている重田(@Shige0096)です。2024 年 11 月にメドレーにジョインし、初の社外イベントに参加してきました。 今回、メドレーは 2024/11/23 に九段坂上... developer.medley.jp DroidKaigi 2024にゴールドスポンサーとして協賛しました！ | MEDLEY Developer Portal こんにちは。人材プラットフォーム本部でエンジニアをしている山河です。2023 年 4 月に新卒として入社し、徐々に業務の幅を広げています！ さて、メドレーは 2024/9/11 〜 9/13 の 3 日間にベルサール渋谷ガーデンにて開催され... developer.medley.jp TSKaigi 2025 の運営スタッフの皆さん、登壇者の皆さん、一緒に盛り上がった参加者の皆さん、本当にありがとうございました！ メドレーではエンジニアを積極採用中です！ メドレーでは領域を問わず、TypeScript を積極的に活用して医療ヘルスケアの未来をつくるプロダクトを開発しています。 TypeScript を活用した医療ヘルスケア領域の課題解決に興味がある方は、ぜひお気軽にご連絡ください！ 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp ※カジュアル面談ご希望の際は、<その他> にてその旨をご記載ください

はじめに こんにちは。医療プラットフォーム本部 CLINICS 開発グループの吉岡( @yuya333_ )と村上( @yuporonM )です。 吉岡は 2022 年に、村上は 2024 年に新卒でエンジニアとしてメドレーに入社しました。 私たちは、医科診療所向けの電子カルテである CLINICS カルテ を開発しています。CLINICS カルテは 2025 年 3 月に iPad 手書き機能をリリースしました。iPad 手書き機能とは、iPad を使って主訴・所見やシェーマ（身体の部位の絵）を手書きできる機能です。 主訴・所見の手書き シェーマの手書き 本記事では iPad 手書き機能を開発するにあたって工夫した点を紹介します。 ライブラリ選定 手書き機能を開発するにあたって、手書き処理すべてを実装するのは工数の観点から現実的ではありませんでした。 そのため、要件を満たせるかつメンテナンス面から以下のライブラリが候補となりました。 fabric konva メドレーでは、歯科診療所向けに電子カルテ Dentis を開発しており、Dentis では既に手書き機能を提供しています。そこで、手書き機能の実装に関して知見を持っている Dentis のエンジニアにライブラリ選定について相談したところ、以下の理由で fabric を採用することに決めました。 konva では線が荒くなってしまうことがある https://github.com/konvajs/konva/issues/1144 で解消方法も紹介されていましたが、細かく線を書きたいケースに対応できない konva では線を描くたびに再レンダリングが発生してしまう mousemove や touchevent のデータをキャッシュすることで解決できるが、遅延が気になる また、fabric を使用した手書き機能の実装方法に関しては、2024 年 12 月にメドレーのアドベントカレンダーで吉岡が書いた以下の記事を参考にしてみてください。 React+fabric.jsで作る手書きアプリ zenn.dev 手書き機能で工夫したポイント 4 選 工夫 1. 手を画面につけながらペンで手書きできるようにした 画面に手をつけながらペンで書いたときに、以下のように線が乱れてしまうことがありました。 画面に接触した手はペンや指で書いたときよりも接触面積が大きくなるので、接触部分が一定よりも大きくなった場合には線を書けないように実装しました。具体的には、 radiusX プロパティを使用して、radiusX がある値より大きいときには、 isDrawingMode が false になるようにしました。 canvas . on ( "mouse:down:before" , ( e ) => { if ( "TouchEvent" in window && e . e instanceof TouchEvent ) { const touch = e . e . touches . item ( 0 ); if (! touch ) { return ; } // 接触面積がペンや指よりも大きいときに線を書けなくする if ( touch . radiusX > 35 ) { canvas . isDrawingMode = false ; } } }); // 画面から手を離す度にisDrawingModeをリセット canvas . on ( "mouse:up:before" , () => { canvas . isDrawingMode = true ; }); 工夫 2. 消しゴムで線を消すときのラグを解消した 消しゴム機能は erase2d ライブラリを使って実装しました。 fabric v5 までは消しゴム機能が内包されていましたが、fabric v6 から erase2d に切り出されました。 erase2d を使って消しゴムを実装すると、次の動画のようにユーザビリティを大きく損なうほどのラグが発生していました。 このラグは PC では発生せず、iPad でのみ発生していました。 この現象について原因を調査したところ、以下の 2 点が原因であることが分かりました。 原因 1. Retina ディスプレイによるピクセル密度の違い iPad は Retina ディスプレイを搭載しており、ピクセル密度が通常のディスプレイよりも高くなっていました。 検証に利用していた 11 インチ iPad Air (M2) では、PC と比較してピクセル密度が 4 倍にもなっていました。 原因 2. ピクセル密度に依存した消しゴム機能特有の処理 消しゴム機能は、ペン機能と比較して複雑な処理が行われていました。 ペンは 1 つのキャンバスに線を描くだけであるのに対して、消しゴムは複数のキャンバスを扱い、それらを合成する処理が必要でした。 具体的には、消しゴムの軌跡を一時的なキャンバスに描画し、それをメインキャンバスに合成するといった処理等が行われていました。 これは、ピクセル密度に依存しており、ピクセル密度が高い環境では負荷が高くなっていました。 // https://github.com/ShaMan123/erase2d/blob/7ee2b789b4c9161d662ea8c8aaf87af4c37bab13/packages/core/src/erase.ts#L15-L40 export const erase = ( destination : CanvasRenderingContext2D , // メインキャンバス source : CanvasRenderingContext2D , // 消しゴムの軌跡が描かれたキャンバス erasingEffect ?: CanvasRenderingContext2D // 消したくないものを保護するためのキャンバス ) => { // メインキャンバスから、消しゴムの軌跡部分を消去 drawImage ( destination , source , "destination-out" ); if ( erasingEffect ) { // 消しゴムの軌跡に、消したくないものがあれば、消さずに保護 drawImage ( source , erasingEffect , "source-in" ); } else { // 消しゴムの軌跡を描いたキャンバスを初期化 source . save (); source . resetTransform (); source . clearRect ( 0 , 0 , source . canvas . width , source . canvas . height ); source . restore (); } }; これらの原因によって、Retina ディスプレイの高解像度環境では消しゴムで線を消すときにラグが発生していました。 解決策として Canvas の初期化時に enableRetinaScaling オプションを false に設定し、Retina ディスプレイの高解像度環境においても同じピクセル密度で処理を行うようにしました。 const canvas = new fabric . Canvas ( canvasElement , { enableRetinaScaling: false , }); この設定により、一定の解像度を担保しつつ、iPad でも滑らかな消しゴム操作を実現できました。 工夫 3. iPad で手書きして保存した画像を PC に即時反映されるようにした iPad で手書きしながら PC でカルテを使うということを想定しているため、iPad で保存した手書き画像は PC に即時反映される必要があります。こちらを実現するために、以下が候補に挙げられました。 SSE(Server-Sent Events) WebSocket Firebase Realtime Database Firebase Realtime Database を既に使用しており、今回保存するのは更新時間のみで、保存容量が大幅に増えることもないため、今回は Firebase Realtime Database を使用することにしました。 以下が、Realtime Database で変更の監視及び通知を行う実装です。 import { initializeApp } from "firebase/app" ; import { getDatabase , off , onValue , ref , set } from "firebase/database" ; const app = initializeApp ( { /* 省略’*/ }, "firebaseapp" ); const db = () => { return getDatabase ( app ); }; const PATH = "medicalRecordChiefComplaintImages" ; // refを生成 const medicalRecordChiefComplaintImagesRef = ( medicalRecordId : string ) => { return ref ( db (), `/ ${ PATH } / ${ medicalRecordId } ` ); }; // 主訴所見の手書き画像が更新されたことを通知する export const updateMedicalRecordChiefComplaintImageIds = async ({ medicalRecordId , }: { medicalRecordId : string ; }) => { await set ( medicalRecordChiefComplaintImagesRef ( medicalRecordId ), Date . now ()); }; // 主訴所見の手書き画像の変更を監視する export const watchMedicalRecordChiefComplaintImages = ({ medicalRecordId , refreshMedicalRecordChiefComplaintImages , }: { medicalRecordId : string ; refreshMedicalRecordChiefComplaintImages : () => void ; }) => { onValue ( medicalRecordChiefComplaintImagesRef ( medicalRecordId ), () => { // Realtime Databaseが更新されたときに実行する処理 refreshMedicalRecordChiefComplaintImages (); }); }; // 主訴所見の手書き画像の変更の監視を解除する export const unwatchMedicalRecordChiefComplaintImages = ({ medicalRecordId , }: { medicalRecordId : string ; }) => { off ( medicalRecordChiefComplaintImagesRef ( medicalRecordId )); }; フロントエンドでは、データフェッチに TanStack Query を使用しています。以下のように Realtime Database によって手書き画像の更新を監視して refetch しています。 export const useMedicalChiefComplaintImagesWatchQuery = ({ medicalRecordId , initialChiefComplaintImages , }: UseMedicalChiefComplaintImagesWatchQueryProps ) => { const medicalChiefComplaintImagesQuery = useQuery ({ queryKey: medicalChiefComplaintImageKey . list ( medicalRecordId ), queryFn : () => query . get ( request . get ( medicalRecordId )), }); useEffect (() => { watchMedicalRecordChiefComplaintImages ({ medicalRecordId: medicalRecordId , // Realtime Databaseの更新時にrefetchする refreshMedicalRecordChiefComplaintImages: medicalChiefComplaintImagesQuery . refetch , }); return () => unwatchMedicalRecordChiefComplaintImages ({ medicalRecordId }); }, [ medicalRecordId , medicalChiefComplaintImagesQuery . refetch ]); return medicalChiefComplaintImagesQuery ; }; 最後に、iPad で手書き画像を更新したタイミングで updateMedicalRecordChiefComplaintImageIds を呼び出せば、以下のように iPad での変更が PC に即時に反映されるようになります。 工夫 4. 手書きツールバーを自由に配置できるようにした 手書き機能では太さや色の変更、ペンと消しゴムの切り替え、履歴管理ができるようにツールバーを実装しています。ツールバーは頻繁に使われるため、ユーザーが使用しやすい位置に移動できるようにしました。こちらは dnd-kit を使用して実装しました。 動画にあるようにツールバーが親要素からはみ出ないようになっています。こちらは restrictToParentElement を使用することで実現できます。 また、CSS ライブラリに emotion を使用しており、今回の Draggable 対応では動的にスタイルを変更する必要があるため、 style prop を使うように注意する必要があります（ https://emotion.sh/docs/best-practices#use-the-style-prop-for-dynamic-styles ）。 ライブラリの不具合 上記のようにユーザーが使いやすいように手書き機能を開発しましたが、消しゴムで線を消すと消えて欲しくない背景画像まで消えてしまうという不具合がライブラリに存在していました。こちらは同じ fabric を使用している Dentis のエンジニア大岡に相談したところ、ライブラリに PR を出して解消していただけました！ fix(): backgroundImage/overlayImage erasable by yasupeke · Pull Request #49 · ShaMan123/erase2d I always appreciate the convenience of using this tool. I have fixed an issue where the erasable setting for backgroundImage/overlayImage was not being applied. Please review the changes. github.com まとめ 本記事では、Web でユーザビリティの高い手書きアプリケーションを実装するための工夫点について紹介しました。手書き機能の実装においては、実装速度とユーザビリティを両立するために適切なライブラリ選定が重要です。私達は fabric を採用することで滑らかな手書きアプリケーションを実現できました。 実装にあたり、以下の 4 つを工夫しました。 手を画面に置きながら書ける機能： 接触面積の大きさを検出してペン入力と区別することで、自然な書き心地を実現しました 消しゴム操作のラグ解消： Retina ディスプレイ対応を最適化し、高負荷な消しゴム処理でもスムーズな操作感を実現しました リアルタイム同期： Firebase Realtime Database を活用し、複数デバイス間での即時反映を実現しました 柔軟な UI： dnd-kit によるドラッグ可能なツールバーで、ユーザー体験を向上しました また、ライブラリの不具合に対してはプロダクトを横断したコミュニケーションやコミュニティと協力することで解決しました。これらの工夫により、医科診療所で快適に使用できる手書き機能を開発することができました。 今後もユーザビリティを重視しながら、より使いやすい機能の開発を続けていきます。 We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、「お話だけでも聞いてみたい！」「ちょっと雑談してみたい！」でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ 「メドレーの開発チームについて知りたい方！ぜひお話ししましょう！」- 德永 諒介さん pitta.me

はじめに こんにちは。医療プラットフォーム本部 CLINICS 開発グループの吉岡( @yuya333_ )と村上( @yuporonM )です。 吉岡は 2022 年に、村上は 2024 年に新卒でエンジニアとしてメドレーに入社しました。 私たちは、医科診療所向けの電子カルテである CLINICS カルテ を開発しています。CLINICS カルテは 2025 年 3 月に iPad 手書き機能をリリースしました。iPad 手書き機能とは、iPad を使って主訴・所見やシェーマ（身体の部位の絵）を手書きできる機能です。 主訴・所見の手書き シェーマの手書き 本記事では iPad 手書き機能を開発するにあたって工夫した点を紹介します。 ライブラリ選定 手書き機能を開発するにあたって、手書き処理すべてを実装するのは工数の観点から現実的ではありませんでした。 そのため、要件を満たせるかつメンテナンス面から以下のライブラリが候補となりました。 fabric konva メドレーでは、歯科診療所向けに電子カルテ Dentis を開発しており、Dentis では既に手書き機能を提供しています。そこで、手書き機能の実装に関して知見を持っている Dentis のエンジニアにライブラリ選定について相談したところ、以下の理由で fabric を採用することに決めました。 konva では線が荒くなってしまうことがある https://github.com/konvajs/konva/issues/1144 で解消方法も紹介されていましたが、細かく線を書きたいケースに対応できない konva では線を描くたびに再レンダリングが発生してしまう mousemove や touchevent のデータをキャッシュすることで解決できるが、遅延が気になる また、fabric を使用した手書き機能の実装方法に関しては、2024 年 12 月にメドレーのアドベントカレンダーで吉岡が書いた以下の記事を参考にしてみてください。 React+fabric.jsで作る手書きアプリ zenn.dev 手書き機能で工夫したポイント 4 選 工夫 1. 手を画面につけながらペンで手書きできるようにした 画面に手をつけながらペンで書いたときに、以下のように線が乱れてしまうことがありました。 画面に接触した手はペンや指で書いたときよりも接触面積が大きくなるので、接触部分が一定よりも大きくなった場合には線を書けないように実装しました。具体的には、 radiusX プロパティを使用して、radiusX がある値より大きいときには、 isDrawingMode が false になるようにしました。 canvas . on ( "mouse:down:before" , ( e ) => { if ( "TouchEvent" in window && e . e instanceof TouchEvent ) { const touch = e . e . touches . item ( 0 ); if (! touch ) { return ; } // 接触面積がペンや指よりも大きいときに線を書けなくする if ( touch . radiusX > 35 ) { canvas . isDrawingMode = false ; } } }); // 画面から手を離す度にisDrawingModeをリセット canvas . on ( "mouse:up:before" , () => { canvas . isDrawingMode = true ; }); 工夫 2. 消しゴムで線を消すときのラグを解消した 消しゴム機能は erase2d ライブラリを使って実装しました。 fabric v5 までは消しゴム機能が内包されていましたが、fabric v6 から erase2d に切り出されました。 erase2d を使って消しゴムを実装すると、次の動画のようにユーザビリティを大きく損なうほどのラグが発生していました。 このラグは PC では発生せず、iPad でのみ発生していました。 この現象について原因を調査したところ、以下の 2 点が原因であることが分かりました。 原因 1. Retina ディスプレイによるピクセル密度の違い iPad は Retina ディスプレイを搭載しており、ピクセル密度が通常のディスプレイよりも高くなっていました。 検証に利用していた 11 インチ iPad Air (M2) では、PC と比較してピクセル密度が 4 倍にもなっていました。 原因 2. ピクセル密度に依存した消しゴム機能特有の処理 消しゴム機能は、ペン機能と比較して複雑な処理が行われていました。 ペンは 1 つのキャンバスに線を描くだけであるのに対して、消しゴムは複数のキャンバスを扱い、それらを合成する処理が必要でした。 具体的には、消しゴムの軌跡を一時的なキャンバスに描画し、それをメインキャンバスに合成するといった処理等が行われていました。 これは、ピクセル密度に依存しており、ピクセル密度が高い環境では負荷が高くなっていました。 // https://github.com/ShaMan123/erase2d/blob/7ee2b789b4c9161d662ea8c8aaf87af4c37bab13/packages/core/src/erase.ts#L15-L40 export const erase = ( destination : CanvasRenderingContext2D , // メインキャンバス source : CanvasRenderingContext2D , // 消しゴムの軌跡が描かれたキャンバス erasingEffect ?: CanvasRenderingContext2D // 消したくないものを保護するためのキャンバス ) => { // メインキャンバスから、消しゴムの軌跡部分を消去 drawImage ( destination , source , "destination-out" ); if ( erasingEffect ) { // 消しゴムの軌跡に、消したくないものがあれば、消さずに保護 drawImage ( source , erasingEffect , "source-in" ); } else { // 消しゴムの軌跡を描いたキャンバスを初期化 source . save (); source . resetTransform (); source . clearRect ( 0 , 0 , source . canvas . width , source . canvas . height ); source . restore (); } }; これらの原因によって、Retina ディスプレイの高解像度環境では消しゴムで線を消すときにラグが発生していました。 解決策として Canvas の初期化時に enableRetinaScaling オプションを false に設定し、Retina ディスプレイの高解像度環境においても同じピクセル密度で処理を行うようにしました。 const canvas = new fabric . Canvas ( canvasElement , { enableRetinaScaling: false , }); この設定により、一定の解像度を担保しつつ、iPad でも滑らかな消しゴム操作を実現できました。 工夫 3. iPad で手書きして保存した画像を PC に即時反映されるようにした iPad で手書きしながら PC でカルテを使うということを想定しているため、iPad で保存した手書き画像は PC に即時反映される必要があります。こちらを実現するために、以下が候補に挙げられました。 SSE(Server-Sent Events) WebSocket Firebase Realtime Database Firebase Realtime Database を既に使用しており、今回保存するのは更新時間のみで、保存容量が大幅に増えることもないため、今回は Firebase Realtime Database を使用することにしました。 以下が、Realtime Database で変更の監視及び通知を行う実装です。 import { initializeApp } from "firebase/app" ; import { getDatabase , off , onValue , ref , set } from "firebase/database" ; const app = initializeApp ( { /* 省略’*/ }, "firebaseapp" ); const db = () => { return getDatabase ( app ); }; const PATH = "medicalRecordChiefComplaintImages" ; // refを生成 const medicalRecordChiefComplaintImagesRef = ( medicalRecordId : string ) => { return ref ( db (), `/ ${ PATH } / ${ medicalRecordId } ` ); }; // 主訴所見の手書き画像が更新されたことを通知する export const updateMedicalRecordChiefComplaintImageIds = async ({ medicalRecordId , }: { medicalRecordId : string ; }) => { await set ( medicalRecordChiefComplaintImagesRef ( medicalRecordId ), Date . now ()); }; // 主訴所見の手書き画像の変更を監視する export const watchMedicalRecordChiefComplaintImages = ({ medicalRecordId , refreshMedicalRecordChiefComplaintImages , }: { medicalRecordId : string ; refreshMedicalRecordChiefComplaintImages : () => void ; }) => { onValue ( medicalRecordChiefComplaintImagesRef ( medicalRecordId ), () => { // Realtime Databaseが更新されたときに実行する処理 refreshMedicalRecordChiefComplaintImages (); }); }; // 主訴所見の手書き画像の変更の監視を解除する export const unwatchMedicalRecordChiefComplaintImages = ({ medicalRecordId , }: { medicalRecordId : string ; }) => { off ( medicalRecordChiefComplaintImagesRef ( medicalRecordId )); }; フロントエンドでは、データフェッチに TanStack Query を使用しています。以下のように Realtime Database によって手書き画像の更新を監視して refetch しています。 export const useMedicalChiefComplaintImagesWatchQuery = ({ medicalRecordId , initialChiefComplaintImages , }: UseMedicalChiefComplaintImagesWatchQueryProps ) => { const medicalChiefComplaintImagesQuery = useQuery ({ queryKey: medicalChiefComplaintImageKey . list ( medicalRecordId ), queryFn : () => query . get ( request . get ( medicalRecordId )), }); useEffect (() => { watchMedicalRecordChiefComplaintImages ({ medicalRecordId: medicalRecordId , // Realtime Databaseの更新時にrefetchする refreshMedicalRecordChiefComplaintImages: medicalChiefComplaintImagesQuery . refetch , }); return () => unwatchMedicalRecordChiefComplaintImages ({ medicalRecordId }); }, [ medicalRecordId , medicalChiefComplaintImagesQuery . refetch ]); return medicalChiefComplaintImagesQuery ; }; 最後に、iPad で手書き画像を更新したタイミングで updateMedicalRecordChiefComplaintImageIds を呼び出せば、以下のように iPad での変更が PC に即時に反映されるようになります。 工夫 4. 手書きツールバーを自由に配置できるようにした 手書き機能では太さや色の変更、ペンと消しゴムの切り替え、履歴管理ができるようにツールバーを実装しています。ツールバーは頻繁に使われるため、ユーザーが使用しやすい位置に移動できるようにしました。こちらは dnd-kit を使用して実装しました。 動画にあるようにツールバーが親要素からはみ出ないようになっています。こちらは restrictToParentElement を使用することで実現できます。 また、CSS ライブラリに emotion を使用しており、今回の Draggable 対応では動的にスタイルを変更する必要があるため、 style prop を使うように注意する必要があります（ https://emotion.sh/docs/best-practices#use-the-style-prop-for-dynamic-styles ）。 ライブラリの不具合 上記のようにユーザーが使いやすいように手書き機能を開発しましたが、消しゴムで線を消すと消えて欲しくない背景画像まで消えてしまうという不具合がライブラリに存在していました。こちらは同じ fabric を使用している Dentis のエンジニア大岡に相談したところ、ライブラリに PR を出して解消していただけました！ fix(): backgroundImage/overlayImage erasable by yasupeke · Pull Request #49 · ShaMan123/erase2d I always appreciate the convenience of using this tool. I have fixed an issue where the erasable setting for backgroundImage/overlayImage was not being applied. Please review the changes. github.com まとめ 本記事では、Web でユーザビリティの高い手書きアプリケーションを実装するための工夫点について紹介しました。手書き機能の実装においては、実装速度とユーザビリティを両立するために適切なライブラリ選定が重要です。私達は fabric を採用することで滑らかな手書きアプリケーションを実現できました。 実装にあたり、以下の 4 つを工夫しました。 手を画面に置きながら書ける機能： 接触面積の大きさを検出してペン入力と区別することで、自然な書き心地を実現しました 消しゴム操作のラグ解消： Retina ディスプレイ対応を最適化し、高負荷な消しゴム処理でもスムーズな操作感を実現しました リアルタイム同期： Firebase Realtime Database を活用し、複数デバイス間での即時反映を実現しました 柔軟な UI： dnd-kit によるドラッグ可能なツールバーで、ユーザー体験を向上しました また、ライブラリの不具合に対してはプロダクトを横断したコミュニケーションやコミュニティと協力することで解決しました。これらの工夫により、医科診療所で快適に使用できる手書き機能を開発することができました。 今後もユーザビリティを重視しながら、より使いやすい機能の開発を続けていきます。 We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、「お話だけでも聞いてみたい！」「ちょっと雑談してみたい！」でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ 「メドレーの開発チームについて知りたい方！ぜひお話ししましょう！」- 德永 諒介さん pitta.me

はじめに こんにちは。医療プラットフォーム本部 CLINICS 開発グループの吉岡( @yuya333_ )と村上( @yuporonM )です。 吉岡は 2022 年に、村上は 2024 年に新卒でエンジニアとしてメドレーに入社しました。 私たちは、医科診療所向けの電子カルテである CLINICS カルテ を開発しています。CLINICS カルテは 2025 年 3 月に iPad 手書き機能をリリースしました。iPad 手書き機能とは、iPad を使って主訴・所見やシェーマ（身体の部位の絵）を手書きできる機能です。 主訴・所見の手書き シェーマの手書き 本記事では iPad 手書き機能を開発するにあたって工夫した点を紹介します。 ライブラリ選定 手書き機能を開発するにあたって、手書き処理すべてを実装するのは工数の観点から現実的ではありませんでした。 そのため、要件を満たせるかつメンテナンス面から以下のライブラリが候補となりました。 fabric konva メドレーでは、歯科診療所向けに電子カルテ Dentis を開発しており、Dentis では既に手書き機能を提供しています。そこで、手書き機能の実装に関して知見を持っている Dentis のエンジニアにライブラリ選定について相談したところ、以下の理由で fabric を採用することに決めました。 konva では線が荒くなってしまうことがある https://github.com/konvajs/konva/issues/1144 で解消方法も紹介されていましたが、細かく線を書きたいケースに対応できない konva では線を描くたびに再レンダリングが発生してしまう mousemove や touchevent のデータをキャッシュすることで解決できるが、遅延が気になる また、fabric を使用した手書き機能の実装方法に関しては、2024 年 12 月にメドレーのアドベントカレンダーで吉岡が書いた以下の記事を参考にしてみてください。 React+fabric.jsで作る手書きアプリ zenn.dev 手書き機能で工夫したポイント 4 選 工夫 1. 手を画面につけながらペンで手書きできるようにした 画面に手をつけながらペンで書いたときに、以下のように線が乱れてしまうことがありました。 画面に接触した手はペンや指で書いたときよりも接触面積が大きくなるので、接触部分が一定よりも大きくなった場合には線を書けないように実装しました。具体的には、 radiusX プロパティを使用して、radiusX がある値より大きいときには、 isDrawingMode が false になるようにしました。 canvas . on ( "mouse:down:before" , ( e ) => { if ( "TouchEvent" in window && e . e instanceof TouchEvent ) { const touch = e . e . touches . item ( 0 ); if (! touch ) { return ; } // 接触面積がペンや指よりも大きいときに線を書けなくする if ( touch . radiusX > 35 ) { canvas . isDrawingMode = false ; } } }); // 画面から手を離す度にisDrawingModeをリセット canvas . on ( "mouse:up:before" , () => { canvas . isDrawingMode = true ; }); 工夫 2. 消しゴムで線を消すときのラグを解消した 消しゴム機能は erase2d ライブラリを使って実装しました。 fabric v5 までは消しゴム機能が内包されていましたが、fabric v6 から erase2d に切り出されました。 erase2d を使って消しゴムを実装すると、次の動画のようにユーザビリティを大きく損なうほどのラグが発生していました。 このラグは PC では発生せず、iPad でのみ発生していました。 この現象について原因を調査したところ、以下の 2 点が原因であることが分かりました。 原因 1. Retina ディスプレイによるピクセル密度の違い iPad は Retina ディスプレイを搭載しており、ピクセル密度が通常のディスプレイよりも高くなっていました。 検証に利用していた 11 インチ iPad Air (M2) では、PC と比較してピクセル密度が 4 倍にもなっていました。 原因 2. ピクセル密度に依存した消しゴム機能特有の処理 消しゴム機能は、ペン機能と比較して複雑な処理が行われていました。 ペンは 1 つのキャンバスに線を描くだけであるのに対して、消しゴムは複数のキャンバスを扱い、それらを合成する処理が必要でした。 具体的には、消しゴムの軌跡を一時的なキャンバスに描画し、それをメインキャンバスに合成するといった処理等が行われていました。 これは、ピクセル密度に依存しており、ピクセル密度が高い環境では負荷が高くなっていました。 // https://github.com/ShaMan123/erase2d/blob/7ee2b789b4c9161d662ea8c8aaf87af4c37bab13/packages/core/src/erase.ts#L15-L40 export const erase = ( destination : CanvasRenderingContext2D , // メインキャンバス source : CanvasRenderingContext2D , // 消しゴムの軌跡が描かれたキャンバス erasingEffect ?: CanvasRenderingContext2D // 消したくないものを保護するためのキャンバス ) => { // メインキャンバスから、消しゴムの軌跡部分を消去 drawImage ( destination , source , "destination-out" ); if ( erasingEffect ) { // 消しゴムの軌跡に、消したくないものがあれば、消さずに保護 drawImage ( source , erasingEffect , "source-in" ); } else { // 消しゴムの軌跡を描いたキャンバスを初期化 source . save (); source . resetTransform (); source . clearRect ( 0 , 0 , source . canvas . width , source . canvas . height ); source . restore (); } }; これらの原因によって、Retina ディスプレイの高解像度環境では消しゴムで線を消すときにラグが発生していました。 解決策として Canvas の初期化時に enableRetinaScaling オプションを false に設定し、Retina ディスプレイの高解像度環境においても同じピクセル密度で処理を行うようにしました。 const canvas = new fabric . Canvas ( canvasElement , { enableRetinaScaling: false , }); この設定により、一定の解像度を担保しつつ、iPad でも滑らかな消しゴム操作を実現できました。 工夫 3. iPad で手書きして保存した画像を PC に即時反映されるようにした iPad で手書きしながら PC でカルテを使うということを想定しているため、iPad で保存した手書き画像は PC に即時反映される必要があります。こちらを実現するために、以下が候補に挙げられました。 SSE(Server-Sent Events) WebSocket Firebase Realtime Database Firebase Realtime Database を既に使用しており、今回保存するのは更新時間のみで、保存容量が大幅に増えることもないため、今回は Firebase Realtime Database を使用することにしました。 以下が、Realtime Database で変更の監視及び通知を行う実装です。 import { initializeApp } from "firebase/app" ; import { getDatabase , off , onValue , ref , set } from "firebase/database" ; const app = initializeApp ( { /* 省略’*/ }, "firebaseapp" ); const db = () => { return getDatabase ( app ); }; const PATH = "medicalRecordChiefComplaintImages" ; // refを生成 const medicalRecordChiefComplaintImagesRef = ( medicalRecordId : string ) => { return ref ( db (), `/ ${ PATH } / ${ medicalRecordId } ` ); }; // 主訴所見の手書き画像が更新されたことを通知する export const updateMedicalRecordChiefComplaintImageIds = async ({ medicalRecordId , }: { medicalRecordId : string ; }) => { await set ( medicalRecordChiefComplaintImagesRef ( medicalRecordId ), Date . now ()); }; // 主訴所見の手書き画像の変更を監視する export const watchMedicalRecordChiefComplaintImages = ({ medicalRecordId , refreshMedicalRecordChiefComplaintImages , }: { medicalRecordId : string ; refreshMedicalRecordChiefComplaintImages : () => void ; }) => { onValue ( medicalRecordChiefComplaintImagesRef ( medicalRecordId ), () => { // Realtime Databaseが更新されたときに実行する処理 refreshMedicalRecordChiefComplaintImages (); }); }; // 主訴所見の手書き画像の変更の監視を解除する export const unwatchMedicalRecordChiefComplaintImages = ({ medicalRecordId , }: { medicalRecordId : string ; }) => { off ( medicalRecordChiefComplaintImagesRef ( medicalRecordId )); }; フロントエンドでは、データフェッチに TanStack Query を使用しています。以下のように Realtime Database によって手書き画像の更新を監視して refetch しています。 export const useMedicalChiefComplaintImagesWatchQuery = ({ medicalRecordId , initialChiefComplaintImages , }: UseMedicalChiefComplaintImagesWatchQueryProps ) => { const medicalChiefComplaintImagesQuery = useQuery ({ queryKey: medicalChiefComplaintImageKey . list ( medicalRecordId ), queryFn : () => query . get ( request . get ( medicalRecordId )), }); useEffect (() => { watchMedicalRecordChiefComplaintImages ({ medicalRecordId: medicalRecordId , // Realtime Databaseの更新時にrefetchする refreshMedicalRecordChiefComplaintImages: medicalChiefComplaintImagesQuery . refetch , }); return () => unwatchMedicalRecordChiefComplaintImages ({ medicalRecordId }); }, [ medicalRecordId , medicalChiefComplaintImagesQuery . refetch ]); return medicalChiefComplaintImagesQuery ; }; 最後に、iPad で手書き画像を更新したタイミングで updateMedicalRecordChiefComplaintImageIds を呼び出せば、以下のように iPad での変更が PC に即時に反映されるようになります。 工夫 4. 手書きツールバーを自由に配置できるようにした 手書き機能では太さや色の変更、ペンと消しゴムの切り替え、履歴管理ができるようにツールバーを実装しています。ツールバーは頻繁に使われるため、ユーザーが使用しやすい位置に移動できるようにしました。こちらは dnd-kit を使用して実装しました。 動画にあるようにツールバーが親要素からはみ出ないようになっています。こちらは restrictToParentElement を使用することで実現できます。 また、CSS ライブラリに emotion を使用しており、今回の Draggable 対応では動的にスタイルを変更する必要があるため、 style prop を使うように注意する必要があります（ https://emotion.sh/docs/best-practices#use-the-style-prop-for-dynamic-styles ）。 ライブラリの不具合 上記のようにユーザーが使いやすいように手書き機能を開発しましたが、消しゴムで線を消すと消えて欲しくない背景画像まで消えてしまうという不具合がライブラリに存在していました。こちらは同じ fabric を使用している Dentis のエンジニア大岡に相談したところ、ライブラリに PR を出して解消していただけました！ fix(): backgroundImage/overlayImage erasable by yasupeke · Pull Request #49 · ShaMan123/erase2d I always appreciate the convenience of using this tool. I have fixed an issue where the erasable setting for backgroundImage/overlayImage was not being applied. Please review the changes. github.com まとめ 本記事では、Web でユーザビリティの高い手書きアプリケーションを実装するための工夫点について紹介しました。手書き機能の実装においては、実装速度とユーザビリティを両立するために適切なライブラリ選定が重要です。私達は fabric を採用することで滑らかな手書きアプリケーションを実現できました。 実装にあたり、以下の 4 つを工夫しました。 手を画面に置きながら書ける機能： 接触面積の大きさを検出してペン入力と区別することで、自然な書き心地を実現しました 消しゴム操作のラグ解消： Retina ディスプレイ対応を最適化し、高負荷な消しゴム処理でもスムーズな操作感を実現しました リアルタイム同期： Firebase Realtime Database を活用し、複数デバイス間での即時反映を実現しました 柔軟な UI： dnd-kit によるドラッグ可能なツールバーで、ユーザー体験を向上しました また、ライブラリの不具合に対してはプロダクトを横断したコミュニケーションやコミュニティと協力することで解決しました。これらの工夫により、医科診療所で快適に使用できる手書き機能を開発することができました。 今後もユーザビリティを重視しながら、より使いやすい機能の開発を続けていきます。 We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、「お話だけでも聞いてみたい！」「ちょっと雑談してみたい！」でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ 「メドレーの開発チームについて知りたい方！ぜひお話ししましょう！」- 德永 諒介さん pitta.me

はじめに こんにちは。医療プラットフォーム本部 CLINICS 開発グループの吉岡( @yuya333_ )と村上( @yuporonM )です。 吉岡は 2022 年に、村上は 2024 年に新卒でエンジニアとしてメドレーに入社しました。 私たちは、医科診療所向けの電子カルテである CLINICS カルテ を開発しています。CLINICS カルテは 2025 年 3 月に iPad 手書き機能をリリースしました。iPad 手書き機能とは、iPad を使って主訴・所見やシェーマ（身体の部位の絵）を手書きできる機能です。 主訴・所見の手書き シェーマの手書き 本記事では iPad 手書き機能を開発するにあたって工夫した点を紹介します。 ライブラリ選定 手書き機能を開発するにあたって、手書き処理すべてを実装するのは工数の観点から現実的ではありませんでした。 そのため、要件を満たせるかつメンテナンス面から以下のライブラリが候補となりました。 fabric konva メドレーでは、歯科診療所向けに電子カルテ Dentis を開発しており、Dentis では既に手書き機能を提供しています。そこで、手書き機能の実装に関して知見を持っている Dentis のエンジニアにライブラリ選定について相談したところ、以下の理由で fabric を採用することに決めました。 konva では線が荒くなってしまうことがある https://github.com/konvajs/konva/issues/1144 で解消方法も紹介されていましたが、細かく線を書きたいケースに対応できない konva では線を描くたびに再レンダリングが発生してしまう mousemove や touchevent のデータをキャッシュすることで解決できるが、遅延が気になる また、fabric を使用した手書き機能の実装方法に関しては、2024 年 12 月にメドレーのアドベントカレンダーで吉岡が書いた以下の記事を参考にしてみてください。 React+fabric.jsで作る手書きアプリ zenn.dev 手書き機能で工夫したポイント 4 選 工夫 1. 手を画面につけながらペンで手書きできるようにした 画面に手をつけながらペンで書いたときに、以下のように線が乱れてしまうことがありました。 画面に接触した手はペンや指で書いたときよりも接触面積が大きくなるので、接触部分が一定よりも大きくなった場合には線を書けないように実装しました。具体的には、 radiusX プロパティを使用して、radiusX がある値より大きいときには、 isDrawingMode が false になるようにしました。 canvas . on ( "mouse:down:before" , ( e ) => { if ( "TouchEvent" in window && e . e instanceof TouchEvent ) { const touch = e . e . touches . item ( 0 ); if (! touch ) { return ; } // 接触面積がペンや指よりも大きいときに線を書けなくする if ( touch . radiusX > 35 ) { canvas . isDrawingMode = false ; } } }); // 画面から手を離す度にisDrawingModeをリセット canvas . on ( "mouse:up:before" , () => { canvas . isDrawingMode = true ; }); 工夫 2. 消しゴムで線を消すときのラグを解消した 消しゴム機能は erase2d ライブラリを使って実装しました。 fabric v5 までは消しゴム機能が内包されていましたが、fabric v6 から erase2d に切り出されました。 erase2d を使って消しゴムを実装すると、次の動画のようにユーザビリティを大きく損なうほどのラグが発生していました。 このラグは PC では発生せず、iPad でのみ発生していました。 この現象について原因を調査したところ、以下の 2 点が原因であることが分かりました。 原因 1. Retina ディスプレイによるピクセル密度の違い iPad は Retina ディスプレイを搭載しており、ピクセル密度が通常のディスプレイよりも高くなっていました。 検証に利用していた 11 インチ iPad Air (M2) では、PC と比較してピクセル密度が 4 倍にもなっていました。 原因 2. ピクセル密度に依存した消しゴム機能特有の処理 消しゴム機能は、ペン機能と比較して複雑な処理が行われていました。 ペンは 1 つのキャンバスに線を描くだけであるのに対して、消しゴムは複数のキャンバスを扱い、それらを合成する処理が必要でした。 具体的には、消しゴムの軌跡を一時的なキャンバスに描画し、それをメインキャンバスに合成するといった処理等が行われていました。 これは、ピクセル密度に依存しており、ピクセル密度が高い環境では負荷が高くなっていました。 // https://github.com/ShaMan123/erase2d/blob/7ee2b789b4c9161d662ea8c8aaf87af4c37bab13/packages/core/src/erase.ts#L15-L40 export const erase = ( destination : CanvasRenderingContext2D , // メインキャンバス source : CanvasRenderingContext2D , // 消しゴムの軌跡が描かれたキャンバス erasingEffect ?: CanvasRenderingContext2D // 消したくないものを保護するためのキャンバス ) => { // メインキャンバスから、消しゴムの軌跡部分を消去 drawImage ( destination , source , "destination-out" ); if ( erasingEffect ) { // 消しゴムの軌跡に、消したくないものがあれば、消さずに保護 drawImage ( source , erasingEffect , "source-in" ); } else { // 消しゴムの軌跡を描いたキャンバスを初期化 source . save (); source . resetTransform (); source . clearRect ( 0 , 0 , source . canvas . width , source . canvas . height ); source . restore (); } }; これらの原因によって、Retina ディスプレイの高解像度環境では消しゴムで線を消すときにラグが発生していました。 解決策として Canvas の初期化時に enableRetinaScaling オプションを false に設定し、Retina ディスプレイの高解像度環境においても同じピクセル密度で処理を行うようにしました。 const canvas = new fabric . Canvas ( canvasElement , { enableRetinaScaling: false , }); この設定により、一定の解像度を担保しつつ、iPad でも滑らかな消しゴム操作を実現できました。 工夫 3. iPad で手書きして保存した画像を PC に即時反映されるようにした iPad で手書きしながら PC でカルテを使うということを想定しているため、iPad で保存した手書き画像は PC に即時反映される必要があります。こちらを実現するために、以下が候補に挙げられました。 SSE(Server-Sent Events) WebSocket Firebase Realtime Database Firebase Realtime Database を既に使用しており、今回保存するのは更新時間のみで、保存容量が大幅に増えることもないため、今回は Firebase Realtime Database を使用することにしました。 以下が、Realtime Database で変更の監視及び通知を行う実装です。 import { initializeApp } from "firebase/app" ; import { getDatabase , off , onValue , ref , set } from "firebase/database" ; const app = initializeApp ( { /* 省略’*/ }, "firebaseapp" ); const db = () => { return getDatabase ( app ); }; const PATH = "medicalRecordChiefComplaintImages" ; // refを生成 const medicalRecordChiefComplaintImagesRef = ( medicalRecordId : string ) => { return ref ( db (), `/ ${ PATH } / ${ medicalRecordId } ` ); }; // 主訴所見の手書き画像が更新されたことを通知する export const updateMedicalRecordChiefComplaintImageIds = async ({ medicalRecordId , }: { medicalRecordId : string ; }) => { await set ( medicalRecordChiefComplaintImagesRef ( medicalRecordId ), Date . now ()); }; // 主訴所見の手書き画像の変更を監視する export const watchMedicalRecordChiefComplaintImages = ({ medicalRecordId , refreshMedicalRecordChiefComplaintImages , }: { medicalRecordId : string ; refreshMedicalRecordChiefComplaintImages : () => void ; }) => { onValue ( medicalRecordChiefComplaintImagesRef ( medicalRecordId ), () => { // Realtime Databaseが更新されたときに実行する処理 refreshMedicalRecordChiefComplaintImages (); }); }; // 主訴所見の手書き画像の変更の監視を解除する export const unwatchMedicalRecordChiefComplaintImages = ({ medicalRecordId , }: { medicalRecordId : string ; }) => { off ( medicalRecordChiefComplaintImagesRef ( medicalRecordId )); }; フロントエンドでは、データフェッチに TanStack Query を使用しています。以下のように Realtime Database によって手書き画像の更新を監視して refetch しています。 export const useMedicalChiefComplaintImagesWatchQuery = ({ medicalRecordId , initialChiefComplaintImages , }: UseMedicalChiefComplaintImagesWatchQueryProps ) => { const medicalChiefComplaintImagesQuery = useQuery ({ queryKey: medicalChiefComplaintImageKey . list ( medicalRecordId ), queryFn : () => query . get ( request . get ( medicalRecordId )), }); useEffect (() => { watchMedicalRecordChiefComplaintImages ({ medicalRecordId: medicalRecordId , // Realtime Databaseの更新時にrefetchする refreshMedicalRecordChiefComplaintImages: medicalChiefComplaintImagesQuery . refetch , }); return () => unwatchMedicalRecordChiefComplaintImages ({ medicalRecordId }); }, [ medicalRecordId , medicalChiefComplaintImagesQuery . refetch ]); return medicalChiefComplaintImagesQuery ; }; 最後に、iPad で手書き画像を更新したタイミングで updateMedicalRecordChiefComplaintImageIds を呼び出せば、以下のように iPad での変更が PC に即時に反映されるようになります。 工夫 4. 手書きツールバーを自由に配置できるようにした 手書き機能では太さや色の変更、ペンと消しゴムの切り替え、履歴管理ができるようにツールバーを実装しています。ツールバーは頻繁に使われるため、ユーザーが使用しやすい位置に移動できるようにしました。こちらは dnd-kit を使用して実装しました。 動画にあるようにツールバーが親要素からはみ出ないようになっています。こちらは restrictToParentElement を使用することで実現できます。 また、CSS ライブラリに emotion を使用しており、今回の Draggable 対応では動的にスタイルを変更する必要があるため、 style prop を使うように注意する必要があります（ https://emotion.sh/docs/best-practices#use-the-style-prop-for-dynamic-styles ）。 ライブラリの不具合 上記のようにユーザーが使いやすいように手書き機能を開発しましたが、消しゴムで線を消すと消えて欲しくない背景画像まで消えてしまうという不具合がライブラリに存在していました。こちらは同じ fabric を使用している Dentis のエンジニア大岡に相談したところ、ライブラリに PR を出して解消していただけました！ fix(): backgroundImage/overlayImage erasable by yasupeke · Pull Request #49 · ShaMan123/erase2d I always appreciate the convenience of using this tool. I have fixed an issue where the erasable setting for backgroundImage/overlayImage was not being applied. Please review the changes. github.com まとめ 本記事では、Web でユーザビリティの高い手書きアプリケーションを実装するための工夫点について紹介しました。手書き機能の実装においては、実装速度とユーザビリティを両立するために適切なライブラリ選定が重要です。私達は fabric を採用することで滑らかな手書きアプリケーションを実現できました。 実装にあたり、以下の 4 つを工夫しました。 手を画面に置きながら書ける機能： 接触面積の大きさを検出してペン入力と区別することで、自然な書き心地を実現しました 消しゴム操作のラグ解消： Retina ディスプレイ対応を最適化し、高負荷な消しゴム処理でもスムーズな操作感を実現しました リアルタイム同期： Firebase Realtime Database を活用し、複数デバイス間での即時反映を実現しました 柔軟な UI： dnd-kit によるドラッグ可能なツールバーで、ユーザー体験を向上しました また、ライブラリの不具合に対してはプロダクトを横断したコミュニケーションやコミュニティと協力することで解決しました。これらの工夫により、医科診療所で快適に使用できる手書き機能を開発することができました。 今後もユーザビリティを重視しながら、より使いやすい機能の開発を続けていきます。 We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、「お話だけでも聞いてみたい！」「ちょっと雑談してみたい！」でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ 「メドレーの開発チームについて知りたい方！ぜひお話ししましょう！」- 德永 諒介さん pitta.me

はじめに こんにちは。医療プラットフォーム本部 CLINICS 開発グループの吉岡( @yuya333_ )と村上( @yuporonM )です。 吉岡は 2022 年に、村上は 2024 年に新卒でエンジニアとしてメドレーに入社しました。 私たちは、医科診療所向けの電子カルテである CLINICS カルテ を開発しています。CLINICS カルテは 2025 年 3 月に iPad 手書き機能をリリースしました。iPad 手書き機能とは、iPad を使って主訴・所見やシェーマ（身体の部位の絵）を手書きできる機能です。 主訴・所見の手書き シェーマの手書き 本記事では iPad 手書き機能を開発するにあたって工夫した点を紹介します。 ライブラリ選定 手書き機能を開発するにあたって、手書き処理すべてを実装するのは工数の観点から現実的ではありませんでした。 そのため、要件を満たせるかつメンテナンス面から以下のライブラリが候補となりました。 fabric konva メドレーでは、歯科診療所向けに電子カルテ Dentis を開発しており、Dentis では既に手書き機能を提供しています。そこで、手書き機能の実装に関して知見を持っている Dentis のエンジニアにライブラリ選定について相談したところ、以下の理由で fabric を採用することに決めました。 konva では線が荒くなってしまうことがある https://github.com/konvajs/konva/issues/1144 で解消方法も紹介されていましたが、細かく線を書きたいケースに対応できない konva では線を描くたびに再レンダリングが発生してしまう mousemove や touchevent のデータをキャッシュすることで解決できるが、遅延が気になる また、fabric を使用した手書き機能の実装方法に関しては、2024 年 12 月にメドレーのアドベントカレンダーで吉岡が書いた以下の記事を参考にしてみてください。 React+fabric.jsで作る手書きアプリ zenn.dev 手書き機能で工夫したポイント 4 選 工夫 1. 手を画面につけながらペンで手書きできるようにした 画面に手をつけながらペンで書いたときに、以下のように線が乱れてしまうことがありました。 画面に接触した手はペンや指で書いたときよりも接触面積が大きくなるので、接触部分が一定よりも大きくなった場合には線を書けないように実装しました。具体的には、 radiusX プロパティを使用して、radiusX がある値より大きいときには、 isDrawingMode が false になるようにしました。 canvas . on ( "mouse:down:before" , ( e ) => { if ( "TouchEvent" in window && e . e instanceof TouchEvent ) { const touch = e . e . touches . item ( 0 ); if (! touch ) { return ; } // 接触面積がペンや指よりも大きいときに線を書けなくする if ( touch . radiusX > 35 ) { canvas . isDrawingMode = false ; } } }); // 画面から手を離す度にisDrawingModeをリセット canvas . on ( "mouse:up:before" , () => { canvas . isDrawingMode = true ; }); 工夫 2. 消しゴムで線を消すときのラグを解消した 消しゴム機能は erase2d ライブラリを使って実装しました。 fabric v5 までは消しゴム機能が内包されていましたが、fabric v6 から erase2d に切り出されました。 erase2d を使って消しゴムを実装すると、次の動画のようにユーザビリティを大きく損なうほどのラグが発生していました。 このラグは PC では発生せず、iPad でのみ発生していました。 この現象について原因を調査したところ、以下の 2 点が原因であることが分かりました。 原因 1. Retina ディスプレイによるピクセル密度の違い iPad は Retina ディスプレイを搭載しており、ピクセル密度が通常のディスプレイよりも高くなっていました。 検証に利用していた 11 インチ iPad Air (M2) では、PC と比較してピクセル密度が 4 倍にもなっていました。 原因 2. ピクセル密度に依存した消しゴム機能特有の処理 消しゴム機能は、ペン機能と比較して複雑な処理が行われていました。 ペンは 1 つのキャンバスに線を描くだけであるのに対して、消しゴムは複数のキャンバスを扱い、それらを合成する処理が必要でした。 具体的には、消しゴムの軌跡を一時的なキャンバスに描画し、それをメインキャンバスに合成するといった処理等が行われていました。 これは、ピクセル密度に依存しており、ピクセル密度が高い環境では負荷が高くなっていました。 // https://github.com/ShaMan123/erase2d/blob/7ee2b789b4c9161d662ea8c8aaf87af4c37bab13/packages/core/src/erase.ts#L15-L40 export const erase = ( destination : CanvasRenderingContext2D , // メインキャンバス source : CanvasRenderingContext2D , // 消しゴムの軌跡が描かれたキャンバス erasingEffect ?: CanvasRenderingContext2D // 消したくないものを保護するためのキャンバス ) => { // メインキャンバスから、消しゴムの軌跡部分を消去 drawImage ( destination , source , "destination-out" ); if ( erasingEffect ) { // 消しゴムの軌跡に、消したくないものがあれば、消さずに保護 drawImage ( source , erasingEffect , "source-in" ); } else { // 消しゴムの軌跡を描いたキャンバスを初期化 source . save (); source . resetTransform (); source . clearRect ( 0 , 0 , source . canvas . width , source . canvas . height ); source . restore (); } }; これらの原因によって、Retina ディスプレイの高解像度環境では消しゴムで線を消すときにラグが発生していました。 解決策として Canvas の初期化時に enableRetinaScaling オプションを false に設定し、Retina ディスプレイの高解像度環境においても同じピクセル密度で処理を行うようにしました。 const canvas = new fabric . Canvas ( canvasElement , { enableRetinaScaling: false , }); この設定により、一定の解像度を担保しつつ、iPad でも滑らかな消しゴム操作を実現できました。 工夫 3. iPad で手書きして保存した画像を PC に即時反映されるようにした iPad で手書きしながら PC でカルテを使うということを想定しているため、iPad で保存した手書き画像は PC に即時反映される必要があります。こちらを実現するために、以下が候補に挙げられました。 SSE(Server-Sent Events) WebSocket Firebase Realtime Database Firebase Realtime Database を既に使用しており、今回保存するのは更新時間のみで、保存容量が大幅に増えることもないため、今回は Firebase Realtime Database を使用することにしました。 以下が、Realtime Database で変更の監視及び通知を行う実装です。 import { initializeApp } from "firebase/app" ; import { getDatabase , off , onValue , ref , set } from "firebase/database" ; const app = initializeApp ( { /* 省略’*/ }, "firebaseapp" ); const db = () => { return getDatabase ( app ); }; const PATH = "medicalRecordChiefComplaintImages" ; // refを生成 const medicalRecordChiefComplaintImagesRef = ( medicalRecordId : string ) => { return ref ( db (), `/ ${ PATH } / ${ medicalRecordId } ` ); }; // 主訴所見の手書き画像が更新されたことを通知する export const updateMedicalRecordChiefComplaintImageIds = async ({ medicalRecordId , }: { medicalRecordId : string ; }) => { await set ( medicalRecordChiefComplaintImagesRef ( medicalRecordId ), Date . now ()); }; // 主訴所見の手書き画像の変更を監視する export const watchMedicalRecordChiefComplaintImages = ({ medicalRecordId , refreshMedicalRecordChiefComplaintImages , }: { medicalRecordId : string ; refreshMedicalRecordChiefComplaintImages : () => void ; }) => { onValue ( medicalRecordChiefComplaintImagesRef ( medicalRecordId ), () => { // Realtime Databaseが更新されたときに実行する処理 refreshMedicalRecordChiefComplaintImages (); }); }; // 主訴所見の手書き画像の変更の監視を解除する export const unwatchMedicalRecordChiefComplaintImages = ({ medicalRecordId , }: { medicalRecordId : string ; }) => { off ( medicalRecordChiefComplaintImagesRef ( medicalRecordId )); }; フロントエンドでは、データフェッチに TanStack Query を使用しています。以下のように Realtime Database によって手書き画像の更新を監視して refetch しています。 export const useMedicalChiefComplaintImagesWatchQuery = ({ medicalRecordId , initialChiefComplaintImages , }: UseMedicalChiefComplaintImagesWatchQueryProps ) => { const medicalChiefComplaintImagesQuery = useQuery ({ queryKey: medicalChiefComplaintImageKey . list ( medicalRecordId ), queryFn : () => query . get ( request . get ( medicalRecordId )), }); useEffect (() => { watchMedicalRecordChiefComplaintImages ({ medicalRecordId: medicalRecordId , // Realtime Databaseの更新時にrefetchする refreshMedicalRecordChiefComplaintImages: medicalChiefComplaintImagesQuery . refetch , }); return () => unwatchMedicalRecordChiefComplaintImages ({ medicalRecordId }); }, [ medicalRecordId , medicalChiefComplaintImagesQuery . refetch ]); return medicalChiefComplaintImagesQuery ; }; 最後に、iPad で手書き画像を更新したタイミングで updateMedicalRecordChiefComplaintImageIds を呼び出せば、以下のように iPad での変更が PC に即時に反映されるようになります。 工夫 4. 手書きツールバーを自由に配置できるようにした 手書き機能では太さや色の変更、ペンと消しゴムの切り替え、履歴管理ができるようにツールバーを実装しています。ツールバーは頻繁に使われるため、ユーザーが使用しやすい位置に移動できるようにしました。こちらは dnd-kit を使用して実装しました。 動画にあるようにツールバーが親要素からはみ出ないようになっています。こちらは restrictToParentElement を使用することで実現できます。 また、CSS ライブラリに emotion を使用しており、今回の Draggable 対応では動的にスタイルを変更する必要があるため、 style prop を使うように注意する必要があります（ https://emotion.sh/docs/best-practices#use-the-style-prop-for-dynamic-styles ）。 ライブラリの不具合 上記のようにユーザーが使いやすいように手書き機能を開発しましたが、消しゴムで線を消すと消えて欲しくない背景画像まで消えてしまうという不具合がライブラリに存在していました。こちらは同じ fabric を使用している Dentis のエンジニア大岡に相談したところ、ライブラリに PR を出して解消していただけました！ fix(): backgroundImage/overlayImage erasable by yasupeke · Pull Request #49 · ShaMan123/erase2d I always appreciate the convenience of using this tool. I have fixed an issue where the erasable setting for backgroundImage/overlayImage was not being applied. Please review the changes. github.com まとめ 本記事では、Web でユーザビリティの高い手書きアプリケーションを実装するための工夫点について紹介しました。手書き機能の実装においては、実装速度とユーザビリティを両立するために適切なライブラリ選定が重要です。私達は fabric を採用することで滑らかな手書きアプリケーションを実現できました。 実装にあたり、以下の 4 つを工夫しました。 手を画面に置きながら書ける機能： 接触面積の大きさを検出してペン入力と区別することで、自然な書き心地を実現しました 消しゴム操作のラグ解消： Retina ディスプレイ対応を最適化し、高負荷な消しゴム処理でもスムーズな操作感を実現しました リアルタイム同期： Firebase Realtime Database を活用し、複数デバイス間での即時反映を実現しました 柔軟な UI： dnd-kit によるドラッグ可能なツールバーで、ユーザー体験を向上しました また、ライブラリの不具合に対してはプロダクトを横断したコミュニケーションやコミュニティと協力することで解決しました。これらの工夫により、医科診療所で快適に使用できる手書き機能を開発することができました。 今後もユーザビリティを重視しながら、より使いやすい機能の開発を続けていきます。 We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、「お話だけでも聞いてみたい！」「ちょっと雑談してみたい！」でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ 「メドレーの開発チームについて知りたい方！ぜひお話ししましょう！」- 德永 諒介さん pitta.me

はじめに こんにちは。医療プラットフォーム本部 CLINICS 開発グループの吉岡( @yuya333_ )と村上( @yuporonM )です。 吉岡は 2022 年に、村上は 2024 年に新卒でエンジニアとしてメドレーに入社しました。 私たちは、医科診療所向けの電子カルテである CLINICS カルテ を開発しています。CLINICS カルテは 2025 年 3 月に iPad 手書き機能をリリースしました。iPad 手書き機能とは、iPad を使って主訴・所見やシェーマ（身体の部位の絵）を手書きできる機能です。 主訴・所見の手書き シェーマの手書き 本記事では iPad 手書き機能を開発するにあたって工夫した点を紹介します。 ライブラリ選定 手書き機能を開発するにあたって、手書き処理すべてを実装するのは工数の観点から現実的ではありませんでした。 そのため、要件を満たせるかつメンテナンス面から以下のライブラリが候補となりました。 fabric konva メドレーでは、歯科診療所向けに電子カルテ Dentis を開発しており、Dentis では既に手書き機能を提供しています。そこで、手書き機能の実装に関して知見を持っている Dentis のエンジニアにライブラリ選定について相談したところ、以下の理由で fabric を採用することに決めました。 konva では線が荒くなってしまうことがある https://github.com/konvajs/konva/issues/1144 で解消方法も紹介されていましたが、細かく線を書きたいケースに対応できない konva では線を描くたびに再レンダリングが発生してしまう mousemove や touchevent のデータをキャッシュすることで解決できるが、遅延が気になる また、fabric を使用した手書き機能の実装方法に関しては、2024 年 12 月にメドレーのアドベントカレンダーで吉岡が書いた以下の記事を参考にしてみてください。 React+fabric.jsで作る手書きアプリ zenn.dev 手書き機能で工夫したポイント 4 選 工夫 1. 手を画面につけながらペンで手書きできるようにした 画面に手をつけながらペンで書いたときに、以下のように線が乱れてしまうことがありました。 画面に接触した手はペンや指で書いたときよりも接触面積が大きくなるので、接触部分が一定よりも大きくなった場合には線を書けないように実装しました。具体的には、 radiusX プロパティを使用して、radiusX がある値より大きいときには、 isDrawingMode が false になるようにしました。 canvas . on ( "mouse:down:before" , ( e ) => { if ( "TouchEvent" in window && e . e instanceof TouchEvent ) { const touch = e . e . touches . item ( 0 ); if (! touch ) { return ; } // 接触面積がペンや指よりも大きいときに線を書けなくする if ( touch . radiusX > 35 ) { canvas . isDrawingMode = false ; } } }); // 画面から手を離す度にisDrawingModeをリセット canvas . on ( "mouse:up:before" , () => { canvas . isDrawingMode = true ; }); 工夫 2. 消しゴムで線を消すときのラグを解消した 消しゴム機能は erase2d ライブラリを使って実装しました。 fabric v5 までは消しゴム機能が内包されていましたが、fabric v6 から erase2d に切り出されました。 erase2d を使って消しゴムを実装すると、次の動画のようにユーザビリティを大きく損なうほどのラグが発生していました。 このラグは PC では発生せず、iPad でのみ発生していました。 この現象について原因を調査したところ、以下の 2 点が原因であることが分かりました。 原因 1. Retina ディスプレイによるピクセル密度の違い iPad は Retina ディスプレイを搭載しており、ピクセル密度が通常のディスプレイよりも高くなっていました。 検証に利用していた 11 インチ iPad Air (M2) では、PC と比較してピクセル密度が 4 倍にもなっていました。 原因 2. ピクセル密度に依存した消しゴム機能特有の処理 消しゴム機能は、ペン機能と比較して複雑な処理が行われていました。 ペンは 1 つのキャンバスに線を描くだけであるのに対して、消しゴムは複数のキャンバスを扱い、それらを合成する処理が必要でした。 具体的には、消しゴムの軌跡を一時的なキャンバスに描画し、それをメインキャンバスに合成するといった処理等が行われていました。 これは、ピクセル密度に依存しており、ピクセル密度が高い環境では負荷が高くなっていました。 // https://github.com/ShaMan123/erase2d/blob/7ee2b789b4c9161d662ea8c8aaf87af4c37bab13/packages/core/src/erase.ts#L15-L40 export const erase = ( destination : CanvasRenderingContext2D , // メインキャンバス source : CanvasRenderingContext2D , // 消しゴムの軌跡が描かれたキャンバス erasingEffect ?: CanvasRenderingContext2D // 消したくないものを保護するためのキャンバス ) => { // メインキャンバスから、消しゴムの軌跡部分を消去 drawImage ( destination , source , "destination-out" ); if ( erasingEffect ) { // 消しゴムの軌跡に、消したくないものがあれば、消さずに保護 drawImage ( source , erasingEffect , "source-in" ); } else { // 消しゴムの軌跡を描いたキャンバスを初期化 source . save (); source . resetTransform (); source . clearRect ( 0 , 0 , source . canvas . width , source . canvas . height ); source . restore (); } }; これらの原因によって、Retina ディスプレイの高解像度環境では消しゴムで線を消すときにラグが発生していました。 解決策として Canvas の初期化時に enableRetinaScaling オプションを false に設定し、Retina ディスプレイの高解像度環境においても同じピクセル密度で処理を行うようにしました。 const canvas = new fabric . Canvas ( canvasElement , { enableRetinaScaling: false , }); この設定により、一定の解像度を担保しつつ、iPad でも滑らかな消しゴム操作を実現できました。 工夫 3. iPad で手書きして保存した画像を PC に即時反映されるようにした iPad で手書きしながら PC でカルテを使うということを想定しているため、iPad で保存した手書き画像は PC に即時反映される必要があります。こちらを実現するために、以下が候補に挙げられました。 SSE(Server-Sent Events) WebSocket Firebase Realtime Database Firebase Realtime Database を既に使用しており、今回保存するのは更新時間のみで、保存容量が大幅に増えることもないため、今回は Firebase Realtime Database を使用することにしました。 以下が、Realtime Database で変更の監視及び通知を行う実装です。 import { initializeApp } from "firebase/app" ; import { getDatabase , off , onValue , ref , set } from "firebase/database" ; const app = initializeApp ( { /* 省略’*/ }, "firebaseapp" ); const db = () => { return getDatabase ( app ); }; const PATH = "medicalRecordChiefComplaintImages" ; // refを生成 const medicalRecordChiefComplaintImagesRef = ( medicalRecordId : string ) => { return ref ( db (), `/ ${ PATH } / ${ medicalRecordId } ` ); }; // 主訴所見の手書き画像が更新されたことを通知する export const updateMedicalRecordChiefComplaintImageIds = async ({ medicalRecordId , }: { medicalRecordId : string ; }) => { await set ( medicalRecordChiefComplaintImagesRef ( medicalRecordId ), Date . now ()); }; // 主訴所見の手書き画像の変更を監視する export const watchMedicalRecordChiefComplaintImages = ({ medicalRecordId , refreshMedicalRecordChiefComplaintImages , }: { medicalRecordId : string ; refreshMedicalRecordChiefComplaintImages : () => void ; }) => { onValue ( medicalRecordChiefComplaintImagesRef ( medicalRecordId ), () => { // Realtime Databaseが更新されたときに実行する処理 refreshMedicalRecordChiefComplaintImages (); }); }; // 主訴所見の手書き画像の変更の監視を解除する export const unwatchMedicalRecordChiefComplaintImages = ({ medicalRecordId , }: { medicalRecordId : string ; }) => { off ( medicalRecordChiefComplaintImagesRef ( medicalRecordId )); }; フロントエンドでは、データフェッチに TanStack Query を使用しています。以下のように Realtime Database によって手書き画像の更新を監視して refetch しています。 export const useMedicalChiefComplaintImagesWatchQuery = ({ medicalRecordId , initialChiefComplaintImages , }: UseMedicalChiefComplaintImagesWatchQueryProps ) => { const medicalChiefComplaintImagesQuery = useQuery ({ queryKey: medicalChiefComplaintImageKey . list ( medicalRecordId ), queryFn : () => query . get ( request . get ( medicalRecordId )), }); useEffect (() => { watchMedicalRecordChiefComplaintImages ({ medicalRecordId: medicalRecordId , // Realtime Databaseの更新時にrefetchする refreshMedicalRecordChiefComplaintImages: medicalChiefComplaintImagesQuery . refetch , }); return () => unwatchMedicalRecordChiefComplaintImages ({ medicalRecordId }); }, [ medicalRecordId , medicalChiefComplaintImagesQuery . refetch ]); return medicalChiefComplaintImagesQuery ; }; 最後に、iPad で手書き画像を更新したタイミングで updateMedicalRecordChiefComplaintImageIds を呼び出せば、以下のように iPad での変更が PC に即時に反映されるようになります。 工夫 4. 手書きツールバーを自由に配置できるようにした 手書き機能では太さや色の変更、ペンと消しゴムの切り替え、履歴管理ができるようにツールバーを実装しています。ツールバーは頻繁に使われるため、ユーザーが使用しやすい位置に移動できるようにしました。こちらは dnd-kit を使用して実装しました。 動画にあるようにツールバーが親要素からはみ出ないようになっています。こちらは restrictToParentElement を使用することで実現できます。 また、CSS ライブラリに emotion を使用しており、今回の Draggable 対応では動的にスタイルを変更する必要があるため、 style prop を使うように注意する必要があります（ https://emotion.sh/docs/best-practices#use-the-style-prop-for-dynamic-styles ）。 ライブラリの不具合 上記のようにユーザーが使いやすいように手書き機能を開発しましたが、消しゴムで線を消すと消えて欲しくない背景画像まで消えてしまうという不具合がライブラリに存在していました。こちらは同じ fabric を使用している Dentis のエンジニア大岡に相談したところ、ライブラリに PR を出して解消していただけました！ fix(): backgroundImage/overlayImage erasable by yasupeke · Pull Request #49 · ShaMan123/erase2d I always appreciate the convenience of using this tool. I have fixed an issue where the erasable setting for backgroundImage/overlayImage was not being applied. Please review the changes. github.com まとめ 本記事では、Web でユーザビリティの高い手書きアプリケーションを実装するための工夫点について紹介しました。手書き機能の実装においては、実装速度とユーザビリティを両立するために適切なライブラリ選定が重要です。私達は fabric を採用することで滑らかな手書きアプリケーションを実現できました。 実装にあたり、以下の 4 つを工夫しました。 手を画面に置きながら書ける機能： 接触面積の大きさを検出してペン入力と区別することで、自然な書き心地を実現しました 消しゴム操作のラグ解消： Retina ディスプレイ対応を最適化し、高負荷な消しゴム処理でもスムーズな操作感を実現しました リアルタイム同期： Firebase Realtime Database を活用し、複数デバイス間での即時反映を実現しました 柔軟な UI： dnd-kit によるドラッグ可能なツールバーで、ユーザー体験を向上しました また、ライブラリの不具合に対してはプロダクトを横断したコミュニケーションやコミュニティと協力することで解決しました。これらの工夫により、医科診療所で快適に使用できる手書き機能を開発することができました。 今後もユーザビリティを重視しながら、より使いやすい機能の開発を続けていきます。 We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、「お話だけでも聞いてみたい！」「ちょっと雑談してみたい！」でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ 「メドレーの開発チームについて知りたい方！ぜひお話ししましょう！」- 德永 諒介さん pitta.me

はじめに こんにちは。医療プラットフォーム本部 CLINICS 開発グループの吉岡( @yuya333_ )と村上( @yuporonM )です。 吉岡は 2022 年に、村上は 2024 年に新卒でエンジニアとしてメドレーに入社しました。 私たちは、医科診療所向けの電子カルテである CLINICS カルテ を開発しています。CLINICS カルテは 2025 年 3 月に iPad 手書き機能をリリースしました。iPad 手書き機能とは、iPad を使って主訴・所見やシェーマ（身体の部位の絵）を手書きできる機能です。 主訴・所見の手書き シェーマの手書き 本記事では iPad 手書き機能を開発するにあたって工夫した点を紹介します。 ライブラリ選定 手書き機能を開発するにあたって、手書き処理すべてを実装するのは工数の観点から現実的ではありませんでした。 そのため、要件を満たせるかつメンテナンス面から以下のライブラリが候補となりました。 fabric konva メドレーでは、歯科診療所向けに電子カルテ Dentis を開発しており、Dentis では既に手書き機能を提供しています。そこで、手書き機能の実装に関して知見を持っている Dentis のエンジニアにライブラリ選定について相談したところ、以下の理由で fabric を採用することに決めました。 konva では線が荒くなってしまうことがある https://github.com/konvajs/konva/issues/1144 で解消方法も紹介されていましたが、細かく線を書きたいケースに対応できない konva では線を描くたびに再レンダリングが発生してしまう mousemove や touchevent のデータをキャッシュすることで解決できるが、遅延が気になる また、fabric を使用した手書き機能の実装方法に関しては、2024 年 12 月にメドレーのアドベントカレンダーで吉岡が書いた以下の記事を参考にしてみてください。 React+fabric.jsで作る手書きアプリ zenn.dev 手書き機能で工夫したポイント 4 選 工夫 1. 手を画面につけながらペンで手書きできるようにした 画面に手をつけながらペンで書いたときに、以下のように線が乱れてしまうことがありました。 画面に接触した手はペンや指で書いたときよりも接触面積が大きくなるので、接触部分が一定よりも大きくなった場合には線を書けないように実装しました。具体的には、 radiusX プロパティを使用して、radiusX がある値より大きいときには、 isDrawingMode が false になるようにしました。 canvas . on ( "mouse:down:before" , ( e ) => { if ( "TouchEvent" in window && e . e instanceof TouchEvent ) { const touch = e . e . touches . item ( 0 ); if (! touch ) { return ; } // 接触面積がペンや指よりも大きいときに線を書けなくする if ( touch . radiusX > 35 ) { canvas . isDrawingMode = false ; } } }); // 画面から手を離す度にisDrawingModeをリセット canvas . on ( "mouse:up:before" , () => { canvas . isDrawingMode = true ; }); 工夫 2. 消しゴムで線を消すときのラグを解消した 消しゴム機能は erase2d ライブラリを使って実装しました。 fabric v5 までは消しゴム機能が内包されていましたが、fabric v6 から erase2d に切り出されました。 erase2d を使って消しゴムを実装すると、次の動画のようにユーザビリティを大きく損なうほどのラグが発生していました。 このラグは PC では発生せず、iPad でのみ発生していました。 この現象について原因を調査したところ、以下の 2 点が原因であることが分かりました。 原因 1. Retina ディスプレイによるピクセル密度の違い iPad は Retina ディスプレイを搭載しており、ピクセル密度が通常のディスプレイよりも高くなっていました。 検証に利用していた 11 インチ iPad Air (M2) では、PC と比較してピクセル密度が 4 倍にもなっていました。 原因 2. ピクセル密度に依存した消しゴム機能特有の処理 消しゴム機能は、ペン機能と比較して複雑な処理が行われていました。 ペンは 1 つのキャンバスに線を描くだけであるのに対して、消しゴムは複数のキャンバスを扱い、それらを合成する処理が必要でした。 具体的には、消しゴムの軌跡を一時的なキャンバスに描画し、それをメインキャンバスに合成するといった処理等が行われていました。 これは、ピクセル密度に依存しており、ピクセル密度が高い環境では負荷が高くなっていました。 // https://github.com/ShaMan123/erase2d/blob/7ee2b789b4c9161d662ea8c8aaf87af4c37bab13/packages/core/src/erase.ts#L15-L40 export const erase = ( destination : CanvasRenderingContext2D , // メインキャンバス source : CanvasRenderingContext2D , // 消しゴムの軌跡が描かれたキャンバス erasingEffect ?: CanvasRenderingContext2D // 消したくないものを保護するためのキャンバス ) => { // メインキャンバスから、消しゴムの軌跡部分を消去 drawImage ( destination , source , "destination-out" ); if ( erasingEffect ) { // 消しゴムの軌跡に、消したくないものがあれば、消さずに保護 drawImage ( source , erasingEffect , "source-in" ); } else { // 消しゴムの軌跡を描いたキャンバスを初期化 source . save (); source . resetTransform (); source . clearRect ( 0 , 0 , source . canvas . width , source . canvas . height ); source . restore (); } }; これらの原因によって、Retina ディスプレイの高解像度環境では消しゴムで線を消すときにラグが発生していました。 解決策として Canvas の初期化時に enableRetinaScaling オプションを false に設定し、Retina ディスプレイの高解像度環境においても同じピクセル密度で処理を行うようにしました。 const canvas = new fabric . Canvas ( canvasElement , { enableRetinaScaling: false , }); この設定により、一定の解像度を担保しつつ、iPad でも滑らかな消しゴム操作を実現できました。 工夫 3. iPad で手書きして保存した画像を PC に即時反映されるようにした iPad で手書きしながら PC でカルテを使うということを想定しているため、iPad で保存した手書き画像は PC に即時反映される必要があります。こちらを実現するために、以下が候補に挙げられました。 SSE(Server-Sent Events) WebSocket Firebase Realtime Database Firebase Realtime Database を既に使用しており、今回保存するのは更新時間のみで、保存容量が大幅に増えることもないため、今回は Firebase Realtime Database を使用することにしました。 以下が、Realtime Database で変更の監視及び通知を行う実装です。 import { initializeApp } from "firebase/app" ; import { getDatabase , off , onValue , ref , set } from "firebase/database" ; const app = initializeApp ( { /* 省略’*/ }, "firebaseapp" ); const db = () => { return getDatabase ( app ); }; const PATH = "medicalRecordChiefComplaintImages" ; // refを生成 const medicalRecordChiefComplaintImagesRef = ( medicalRecordId : string ) => { return ref ( db (), `/ ${ PATH } / ${ medicalRecordId } ` ); }; // 主訴所見の手書き画像が更新されたことを通知する export const updateMedicalRecordChiefComplaintImageIds = async ({ medicalRecordId , }: { medicalRecordId : string ; }) => { await set ( medicalRecordChiefComplaintImagesRef ( medicalRecordId ), Date . now ()); }; // 主訴所見の手書き画像の変更を監視する export const watchMedicalRecordChiefComplaintImages = ({ medicalRecordId , refreshMedicalRecordChiefComplaintImages , }: { medicalRecordId : string ; refreshMedicalRecordChiefComplaintImages : () => void ; }) => { onValue ( medicalRecordChiefComplaintImagesRef ( medicalRecordId ), () => { // Realtime Databaseが更新されたときに実行する処理 refreshMedicalRecordChiefComplaintImages (); }); }; // 主訴所見の手書き画像の変更の監視を解除する export const unwatchMedicalRecordChiefComplaintImages = ({ medicalRecordId , }: { medicalRecordId : string ; }) => { off ( medicalRecordChiefComplaintImagesRef ( medicalRecordId )); }; フロントエンドでは、データフェッチに TanStack Query を使用しています。以下のように Realtime Database によって手書き画像の更新を監視して refetch しています。 export const useMedicalChiefComplaintImagesWatchQuery = ({ medicalRecordId , initialChiefComplaintImages , }: UseMedicalChiefComplaintImagesWatchQueryProps ) => { const medicalChiefComplaintImagesQuery = useQuery ({ queryKey: medicalChiefComplaintImageKey . list ( medicalRecordId ), queryFn : () => query . get ( request . get ( medicalRecordId )), }); useEffect (() => { watchMedicalRecordChiefComplaintImages ({ medicalRecordId: medicalRecordId , // Realtime Databaseの更新時にrefetchする refreshMedicalRecordChiefComplaintImages: medicalChiefComplaintImagesQuery . refetch , }); return () => unwatchMedicalRecordChiefComplaintImages ({ medicalRecordId }); }, [ medicalRecordId , medicalChiefComplaintImagesQuery . refetch ]); return medicalChiefComplaintImagesQuery ; }; 最後に、iPad で手書き画像を更新したタイミングで updateMedicalRecordChiefComplaintImageIds を呼び出せば、以下のように iPad での変更が PC に即時に反映されるようになります。 工夫 4. 手書きツールバーを自由に配置できるようにした 手書き機能では太さや色の変更、ペンと消しゴムの切り替え、履歴管理ができるようにツールバーを実装しています。ツールバーは頻繁に使われるため、ユーザーが使用しやすい位置に移動できるようにしました。こちらは dnd-kit を使用して実装しました。 動画にあるようにツールバーが親要素からはみ出ないようになっています。こちらは restrictToParentElement を使用することで実現できます。 また、CSS ライブラリに emotion を使用しており、今回の Draggable 対応では動的にスタイルを変更する必要があるため、 style prop を使うように注意する必要があります（ https://emotion.sh/docs/best-practices#use-the-style-prop-for-dynamic-styles ）。 ライブラリの不具合 上記のようにユーザーが使いやすいように手書き機能を開発しましたが、消しゴムで線を消すと消えて欲しくない背景画像まで消えてしまうという不具合がライブラリに存在していました。こちらは同じ fabric を使用している Dentis のエンジニア大岡に相談したところ、ライブラリに PR を出して解消していただけました！ fix(): backgroundImage/overlayImage erasable by yasupeke · Pull Request #49 · ShaMan123/erase2d I always appreciate the convenience of using this tool. I have fixed an issue where the erasable setting for backgroundImage/overlayImage was not being applied. Please review the changes. github.com まとめ 本記事では、Web でユーザビリティの高い手書きアプリケーションを実装するための工夫点について紹介しました。手書き機能の実装においては、実装速度とユーザビリティを両立するために適切なライブラリ選定が重要です。私達は fabric を採用することで滑らかな手書きアプリケーションを実現できました。 実装にあたり、以下の 4 つを工夫しました。 手を画面に置きながら書ける機能： 接触面積の大きさを検出してペン入力と区別することで、自然な書き心地を実現しました 消しゴム操作のラグ解消： Retina ディスプレイ対応を最適化し、高負荷な消しゴム処理でもスムーズな操作感を実現しました リアルタイム同期： Firebase Realtime Database を活用し、複数デバイス間での即時反映を実現しました 柔軟な UI： dnd-kit によるドラッグ可能なツールバーで、ユーザー体験を向上しました また、ライブラリの不具合に対してはプロダクトを横断したコミュニケーションやコミュニティと協力することで解決しました。これらの工夫により、医科診療所で快適に使用できる手書き機能を開発することができました。 今後もユーザビリティを重視しながら、より使いやすい機能の開発を続けていきます。 We’re hiring メドレーでは一緒に働く仲間を大募集しています！ カジュアル面談も実施しておりますので、「お話だけでも聞いてみたい！」「ちょっと雑談してみたい！」でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ メドレーの開発チームについて知りたい方！ぜひお話ししましょう！ 「メドレーの開発チームについて知りたい方！ぜひお話ししましょう！」- 德永 諒介さん pitta.me

はじめに こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。 このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。 この記事では、以下の内容についてお話しします。 医療プラットフォームにおける SRE チーム立ち上げの経緯 医療プラットフォームの中核である CLINICS について 医療プラットフォーム SRE チームの組織体制と役割 医療プラットフォーム SRE チームとしての展望 医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。 なぜ、医療プラットフォームで SRE チーム立ち上げたのか？ 医療プラットフォームの中核を担う CLINICS 医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。 その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。 また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。 CLINICS に求められる非機能要件 CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。 例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。 その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。 しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム） などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。 CLINICS を含む医療プラットフォームの成長に伴う技術課題 私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。 システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。 長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む ライブラリ対応の優先度が下がり、 EOL 対応に追われている アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない また、これらの課題は、 Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。 CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、 信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。 医療プラットフォーム SRE チームの発足 信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。 まずは、医療プラットフォームの中でも 中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。 2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。 CLINICS の信頼性向上を目指した SRE の取り組み ここからは CLINICS に対して現在行っている取り組みを説明します。 SRE チームの役割とミッション CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。 前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。 目標 1: トイル排除と中長期課題へのシフト 課題: 日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする 主な取り組み: 既存インフラリソースの Terraform import を実施 : 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。 定常的に発生する運用業務の自動化 : CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。 AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。 目標 2: 改善文化の浸透 課題: ポストモーテム 文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。 主な取り組み: ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。 チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。 アラート改善を定常的に回す仕組みの策定 : 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。 目標 3: SLO による信頼性可視化 課題: CLINICS の関係者が納得できる 信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する 主な取り組み: 重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。 SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。 SRE チームにおけるその他の取り組み 上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。 事業成長を見越したキャパシティプランニング システムのモニタリングによる事前の課題発見 障害対応プロセスの改善 インフラコストの削減 DB 等のパフォーマンス問題の改善 ライブラリ対応やセキュリティ対応の効率化 アーキテクチャとリリースフローの改善…など SRE チームの取り組みの成果が実を結び始める これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。 信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的とした Sidekiq Pro の導入など、信頼性向上にも取り組んでいます。 このように私たちの取り組みが徐々に成果を上げ始めています。 開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります 。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。 医療プラットフォーム SRE チームとしての展望 ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。 医療プラットフォーム全体への SRE ノウハウ展開 CLINICS での知見を活かし、今後、 Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。 CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。 プロダクトの拡充に対して柔軟に対応できる仕組みづくり 医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。 新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。 SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。 事業運営に関わる全関係者が納得する SRE 文化の醸成 SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。 SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。 まとめ：医療ヘルスケアの未来を支える SRE 医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。 SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。 何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？ 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 https://www.medley.jp/jobs/

はじめに こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。 このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。 この記事では、以下の内容についてお話しします。 医療プラットフォームにおける SRE チーム立ち上げの経緯 医療プラットフォームの中核である CLINICS について 医療プラットフォーム SRE チームの組織体制と役割 医療プラットフォーム SRE チームとしての展望 医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。 なぜ、医療プラットフォームで SRE チーム立ち上げたのか？ 医療プラットフォームの中核を担う CLINICS 医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。 その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。 また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。 CLINICS に求められる非機能要件 CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。 例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。 その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。 しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム） などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。 CLINICS を含む医療プラットフォームの成長に伴う技術課題 私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。 システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。 長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む ライブラリ対応の優先度が下がり、 EOL 対応に追われている アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない また、これらの課題は、 Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。 CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、 信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。 医療プラットフォーム SRE チームの発足 信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。 まずは、医療プラットフォームの中でも 中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。 2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。 CLINICS の信頼性向上を目指した SRE の取り組み ここからは CLINICS に対して現在行っている取り組みを説明します。 SRE チームの役割とミッション CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。 前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。 目標 1: トイル排除と中長期課題へのシフト 課題: 日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする 主な取り組み: 既存インフラリソースの Terraform import を実施 : 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。 定常的に発生する運用業務の自動化 : CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。 AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。 目標 2: 改善文化の浸透 課題: ポストモーテム 文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。 主な取り組み: ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。 チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。 アラート改善を定常的に回す仕組みの策定 : 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。 目標 3: SLO による信頼性可視化 課題: CLINICS の関係者が納得できる 信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する 主な取り組み: 重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。 SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。 SRE チームにおけるその他の取り組み 上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。 事業成長を見越したキャパシティプランニング システムのモニタリングによる事前の課題発見 障害対応プロセスの改善 インフラコストの削減 DB 等のパフォーマンス問題の改善 ライブラリ対応やセキュリティ対応の効率化 アーキテクチャとリリースフローの改善…など SRE チームの取り組みの成果が実を結び始める これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。 信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的とした Sidekiq Pro の導入など、信頼性向上にも取り組んでいます。 このように私たちの取り組みが徐々に成果を上げ始めています。 開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります 。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。 医療プラットフォーム SRE チームとしての展望 ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。 医療プラットフォーム全体への SRE ノウハウ展開 CLINICS での知見を活かし、今後、 Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。 CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。 プロダクトの拡充に対して柔軟に対応できる仕組みづくり 医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。 新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。 SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。 事業運営に関わる全関係者が納得する SRE 文化の醸成 SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。 SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。 まとめ：医療ヘルスケアの未来を支える SRE 医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。 SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。 何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？ 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。 このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。 この記事では、以下の内容についてお話しします。 医療プラットフォームにおける SRE チーム立ち上げの経緯 医療プラットフォームの中核である CLINICS について 医療プラットフォーム SRE チームの組織体制と役割 医療プラットフォーム SRE チームとしての展望 医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。 なぜ、医療プラットフォームで SRE チーム立ち上げたのか？ 医療プラットフォームの中核を担う CLINICS 医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。 その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。 また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。 CLINICS に求められる非機能要件 CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。 例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。 その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。 しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム） などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。 CLINICS を含む医療プラットフォームの成長に伴う技術課題 私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。 システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。 長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む ライブラリ対応の優先度が下がり、 EOL 対応に追われている アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない また、これらの課題は、 Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。 CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、 信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。 医療プラットフォーム SRE チームの発足 信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。 まずは、医療プラットフォームの中でも 中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。 2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。 CLINICS の信頼性向上を目指した SRE の取り組み ここからは CLINICS に対して現在行っている取り組みを説明します。 SRE チームの役割とミッション CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。 前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。 目標 1: トイル排除と中長期課題へのシフト 課題: 日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする 主な取り組み: 既存インフラリソースの Terraform import を実施 : 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。 定常的に発生する運用業務の自動化 : CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。 AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。 目標 2: 改善文化の浸透 課題: ポストモーテム 文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。 主な取り組み: ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。 チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。 アラート改善を定常的に回す仕組みの策定 : 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。 目標 3: SLO による信頼性可視化 課題: CLINICS の関係者が納得できる 信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する 主な取り組み: 重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。 SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。 SRE チームにおけるその他の取り組み 上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。 事業成長を見越したキャパシティプランニング システムのモニタリングによる事前の課題発見 障害対応プロセスの改善 インフラコストの削減 DB 等のパフォーマンス問題の改善 ライブラリ対応やセキュリティ対応の効率化 アーキテクチャとリリースフローの改善…など SRE チームの取り組みの成果が実を結び始める これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。 信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的とした Sidekiq Pro の導入など、信頼性向上にも取り組んでいます。 このように私たちの取り組みが徐々に成果を上げ始めています。 開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります 。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。 医療プラットフォーム SRE チームとしての展望 ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。 医療プラットフォーム全体への SRE ノウハウ展開 CLINICS での知見を活かし、今後、 Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。 CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。 プロダクトの拡充に対して柔軟に対応できる仕組みづくり 医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。 新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。 SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。 事業運営に関わる全関係者が納得する SRE 文化の醸成 SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。 SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。 まとめ：医療ヘルスケアの未来を支える SRE 医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。 SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。 何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？ 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。 このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。 この記事では、以下の内容についてお話しします。 医療プラットフォームにおける SRE チーム立ち上げの経緯 医療プラットフォームの中核である CLINICS について 医療プラットフォーム SRE チームの組織体制と役割 医療プラットフォーム SRE チームとしての展望 医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。 なぜ、医療プラットフォームで SRE チーム立ち上げたのか？ 医療プラットフォームの中核を担う CLINICS 医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。 その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。 また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。 CLINICS に求められる非機能要件 CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。 例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。 その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。 しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム） などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。 CLINICS を含む医療プラットフォームの成長に伴う技術課題 私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。 システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。 長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む ライブラリ対応の優先度が下がり、 EOL 対応に追われている アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない また、これらの課題は、 Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。 CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、 信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。 医療プラットフォーム SRE チームの発足 信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。 まずは、医療プラットフォームの中でも 中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。 2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。 CLINICS の信頼性向上を目指した SRE の取り組み ここからは CLINICS に対して現在行っている取り組みを説明します。 SRE チームの役割とミッション CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。 前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。 目標 1: トイル排除と中長期課題へのシフト 課題: 日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする 主な取り組み: 既存インフラリソースの Terraform import を実施 : 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。 定常的に発生する運用業務の自動化 : CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。 AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。 目標 2: 改善文化の浸透 課題: ポストモーテム 文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。 主な取り組み: ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。 チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。 アラート改善を定常的に回す仕組みの策定 : 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。 目標 3: SLO による信頼性可視化 課題: CLINICS の関係者が納得できる 信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する 主な取り組み: 重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。 SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。 SRE チームにおけるその他の取り組み 上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。 事業成長を見越したキャパシティプランニング システムのモニタリングによる事前の課題発見 障害対応プロセスの改善 インフラコストの削減 DB 等のパフォーマンス問題の改善 ライブラリ対応やセキュリティ対応の効率化 アーキテクチャとリリースフローの改善…など SRE チームの取り組みの成果が実を結び始める これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。 信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的とした Sidekiq Pro の導入など、信頼性向上にも取り組んでいます。 このように私たちの取り組みが徐々に成果を上げ始めています。 開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります 。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。 医療プラットフォーム SRE チームとしての展望 ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。 医療プラットフォーム全体への SRE ノウハウ展開 CLINICS での知見を活かし、今後、 Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。 CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。 プロダクトの拡充に対して柔軟に対応できる仕組みづくり 医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。 新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。 SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。 事業運営に関わる全関係者が納得する SRE 文化の醸成 SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。 SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。 まとめ：医療ヘルスケアの未来を支える SRE 医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。 SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。 何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？ 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 https://www.medley.jp/jobs/

はじめに こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。 このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。 この記事では、以下の内容についてお話しします。 医療プラットフォームにおける SRE チーム立ち上げの経緯 医療プラットフォームの中核である CLINICS について 医療プラットフォーム SRE チームの組織体制と役割 医療プラットフォーム SRE チームとしての展望 医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。 なぜ、医療プラットフォームで SRE チーム立ち上げたのか？ 医療プラットフォームの中核を担う CLINICS 医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。 その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。 また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。 CLINICS に求められる非機能要件 CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。 例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。 その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。 しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム） などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。 CLINICS を含む医療プラットフォームの成長に伴う技術課題 私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。 システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。 長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む ライブラリ対応の優先度が下がり、 EOL 対応に追われている アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない また、これらの課題は、 Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。 CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、 信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。 医療プラットフォーム SRE チームの発足 信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。 まずは、医療プラットフォームの中でも 中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。 2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。 CLINICS の信頼性向上を目指した SRE の取り組み ここからは CLINICS に対して現在行っている取り組みを説明します。 SRE チームの役割とミッション CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。 前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。 目標 1: トイル排除と中長期課題へのシフト 課題: 日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする 主な取り組み: 既存インフラリソースの Terraform import を実施 : 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。 定常的に発生する運用業務の自動化 : CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。 AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。 目標 2: 改善文化の浸透 課題: ポストモーテム 文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。 主な取り組み: ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。 チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。 アラート改善を定常的に回す仕組みの策定 : 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。 目標 3: SLO による信頼性可視化 課題: CLINICS の関係者が納得できる 信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する 主な取り組み: 重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。 SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。 SRE チームにおけるその他の取り組み 上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。 事業成長を見越したキャパシティプランニング システムのモニタリングによる事前の課題発見 障害対応プロセスの改善 インフラコストの削減 DB 等のパフォーマンス問題の改善 ライブラリ対応やセキュリティ対応の効率化 アーキテクチャとリリースフローの改善…など SRE チームの取り組みの成果が実を結び始める これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。 信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的とした Sidekiq Pro の導入など、信頼性向上にも取り組んでいます。 このように私たちの取り組みが徐々に成果を上げ始めています。 開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります 。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。 医療プラットフォーム SRE チームとしての展望 ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。 医療プラットフォーム全体への SRE ノウハウ展開 CLINICS での知見を活かし、今後、 Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。 CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。 プロダクトの拡充に対して柔軟に対応できる仕組みづくり 医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。 新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。 SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。 事業運営に関わる全関係者が納得する SRE 文化の醸成 SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。 SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。 まとめ：医療ヘルスケアの未来を支える SRE 医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。 SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。 何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？ 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。 このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。 この記事では、以下の内容についてお話しします。 医療プラットフォームにおける SRE チーム立ち上げの経緯 医療プラットフォームの中核である CLINICS について 医療プラットフォーム SRE チームの組織体制と役割 医療プラットフォーム SRE チームとしての展望 医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。 なぜ、医療プラットフォームで SRE チーム立ち上げたのか？ 医療プラットフォームの中核を担う CLINICS 医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。 その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。 また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。 CLINICS に求められる非機能要件 CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。 例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。 その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。 しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム） などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。 CLINICS を含む医療プラットフォームの成長に伴う技術課題 私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。 システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。 長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む ライブラリ対応の優先度が下がり、 EOL 対応に追われている アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない また、これらの課題は、 Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。 CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、 信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。 医療プラットフォーム SRE チームの発足 信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。 まずは、医療プラットフォームの中でも 中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。 2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。 CLINICS の信頼性向上を目指した SRE の取り組み ここからは CLINICS に対して現在行っている取り組みを説明します。 SRE チームの役割とミッション CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。 前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。 目標 1: トイル排除と中長期課題へのシフト 課題: 日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする 主な取り組み: 既存インフラリソースの Terraform import を実施 : 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。 定常的に発生する運用業務の自動化 : CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。 AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。 目標 2: 改善文化の浸透 課題: ポストモーテム 文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。 主な取り組み: ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。 チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。 アラート改善を定常的に回す仕組みの策定 : 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。 目標 3: SLO による信頼性可視化 課題: CLINICS の関係者が納得できる 信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する 主な取り組み: 重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。 SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。 SRE チームにおけるその他の取り組み 上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。 事業成長を見越したキャパシティプランニング システムのモニタリングによる事前の課題発見 障害対応プロセスの改善 インフラコストの削減 DB 等のパフォーマンス問題の改善 ライブラリ対応やセキュリティ対応の効率化 アーキテクチャとリリースフローの改善…など SRE チームの取り組みの成果が実を結び始める これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。 信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的とした Sidekiq Pro の導入など、信頼性向上にも取り組んでいます。 このように私たちの取り組みが徐々に成果を上げ始めています。 開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります 。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。 医療プラットフォーム SRE チームとしての展望 ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。 医療プラットフォーム全体への SRE ノウハウ展開 CLINICS での知見を活かし、今後、 Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。 CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。 プロダクトの拡充に対して柔軟に対応できる仕組みづくり 医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。 新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。 SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。 事業運営に関わる全関係者が納得する SRE 文化の醸成 SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。 SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。 まとめ：医療ヘルスケアの未来を支える SRE 医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。 SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。 何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？ 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。 このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。 この記事では、以下の内容についてお話しします。 医療プラットフォームにおける SRE チーム立ち上げの経緯 医療プラットフォームの中核である CLINICS について 医療プラットフォーム SRE チームの組織体制と役割 医療プラットフォーム SRE チームとしての展望 医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。 なぜ、医療プラットフォームで SRE チーム立ち上げたのか？ 医療プラットフォームの中核を担う CLINICS 医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。 その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。 また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。 CLINICS に求められる非機能要件 CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。 例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。 その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。 しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム） などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。 CLINICS を含む医療プラットフォームの成長に伴う技術課題 私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。 システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。 長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む ライブラリ対応の優先度が下がり、 EOL 対応に追われている アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない また、これらの課題は、 Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。 CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、 信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。 医療プラットフォーム SRE チームの発足 信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。 まずは、医療プラットフォームの中でも 中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。 2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。 CLINICS の信頼性向上を目指した SRE の取り組み ここからは CLINICS に対して現在行っている取り組みを説明します。 SRE チームの役割とミッション CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。 前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。 目標 1: トイル排除と中長期課題へのシフト 課題: 日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする 主な取り組み: 既存インフラリソースの Terraform import を実施 : 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。 定常的に発生する運用業務の自動化 : CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。 AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。 目標 2: 改善文化の浸透 課題: ポストモーテム 文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。 主な取り組み: ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。 チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。 アラート改善を定常的に回す仕組みの策定 : 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。 目標 3: SLO による信頼性可視化 課題: CLINICS の関係者が納得できる 信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する 主な取り組み: 重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。 SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。 SRE チームにおけるその他の取り組み 上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。 事業成長を見越したキャパシティプランニング システムのモニタリングによる事前の課題発見 障害対応プロセスの改善 インフラコストの削減 DB 等のパフォーマンス問題の改善 ライブラリ対応やセキュリティ対応の効率化 アーキテクチャとリリースフローの改善…など SRE チームの取り組みの成果が実を結び始める これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。 信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的とした Sidekiq Pro の導入など、信頼性向上にも取り組んでいます。 このように私たちの取り組みが徐々に成果を上げ始めています。 開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります 。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。 医療プラットフォーム SRE チームとしての展望 ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。 医療プラットフォーム全体への SRE ノウハウ展開 CLINICS での知見を活かし、今後、 Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。 CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。 プロダクトの拡充に対して柔軟に対応できる仕組みづくり 医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。 新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。 SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。 事業運営に関わる全関係者が納得する SRE 文化の醸成 SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。 SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。 まとめ：医療ヘルスケアの未来を支える SRE 医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。 SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。 何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？ 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

はじめに こんにちは、医療プラットフォーム本部 SRE グループの大塚です。入社から 3 年ほど CLINICS のソフトウェアエンジニアとして開発に携わり、その中でプロダクトの安定稼働のための信頼性向上の技術的な取り込みも担当していました。 このたび、医療プラットフォームにおけるシステムの安定稼働と信頼性の確保がこれまで以上に求められる状況になり、正式に SRE チームを立ち上げました。医療機関向け SaaS である CLINICS の信頼性向上を主眼に発足し、立ち上げから SLO の策定や運用効率化などの成果が出ています。 この記事では、以下の内容についてお話しします。 医療プラットフォームにおける SRE チーム立ち上げの経緯 医療プラットフォームの中核である CLINICS について 医療プラットフォーム SRE チームの組織体制と役割 医療プラットフォーム SRE チームとしての展望 医療系 SaaS に興味があるエンジニアや、SRE としてのキャリアに関心がある方に向けて書いています。医療の発展にテクノロジーで貢献したいと考える方にとって参考になれば幸いです。 なぜ、医療プラットフォームで SRE チーム立ち上げたのか？ 医療プラットフォームの中核を担う CLINICS 医療プラットフォームは「医療ヘルスケアの未来をつくる」、「納得できる医療」の実現のために、様々な医療領域のプロダクトを提供しています。 その中でも、医療機関向け SaaS である CLINICS は高い信頼性が求められています。CLINICS は電子カルテ、予約管理、会計システム、オンライン診療など、診療所の基幹業務をトータルでサポートするクラウドサービスです。診療所の日々の運営に不可欠な業務を担うシステムであるため、高い信頼性と安定性が求められます。 また、CLINICS は医療機関と患者をつなぐ接点でもあり、システムには患者向けの API なども含まれます。そのため、システムの信頼性は患者の観点から見ても重要です。 CLINICS に求められる非機能要件 CLINICS は診療業務の基幹システムであり、診療所の業務をリアルタイムでサポートします。機能面の品質はもちろん、非機能要件（信頼性、可用性、パフォーマンス、保守性など）も極めて重要です。 例えば、システムの応答速度が遅くなり患者が受付や会計で長時間待たされると、医療機関だけでなく患者の体験も悪化します。そして、システム停止は診療所の業務が遂行できなくなることを意味します。 その結果、CLINICS サポートへの負荷増大や医療機関の信頼性低下などの影響を招きます。障害復旧対応で開発計画の変更が余儀なくされ、開発速度の低下を生じさせる一因になります。 しかし、CLINICS においてはこれらの非機能要件を満たすことは簡単ではありません。CLINICS は医療プラットフォームの中で最も歴史が長いプロダクトです。契約医療機関数は数千を超え、診療所の業務時間中は常に大量のデータとトラフィックを処理します。また、 CLINICS はレセコン（診療報酬請求事務を管理・自動化するシステム） などの複数のシステムで構成され、インフラなどの運用コストも高くなっています。 CLINICS を含む医療プラットフォームの成長に伴う技術課題 私自身も CLINICS のソフトウェアエンジニアとして開発に携わり、インフラに詳しいメンバー数人と共に可用性や信頼性に関するタスクを担当してきました。しかし、事業の成長に伴いシステム規模が拡大する中で、機能開発とシステム信頼性の両立が困難になっていました。 システムが深刻な状態には至っていませんでしたが、概ね以下のような課題を抱えていました。 長年の運用の中で非効率な DB へのクエリが蓄積し、処理に時間がかかる箇所が散見される トイル（SRE における反復的な運用作業）が増大し、運用業務の負荷が大きくなり、さらに悪循環を生む ライブラリ対応の優先度が下がり、 EOL 対応に追われている アラートの振り返りと暫定的な再発防止策は実施するが、根本対応までやりきれない また、これらの課題は、 Dentis や Pharms などの医療プラットフォーム内の他のプロダクトでも発生する可能性が高いです。他のプロダクトも CLINICS と同様の体制で開発と運用されており、すでに同じ課題が顕在化しつつあります。 CLINICS の医療機関数は日々増加しており、今後も事業拡大が見込まれます。それは他のプロダクトでも同様です。CLINICS に限らず医療プラットフォーム全体の成長を加速させるには、 信頼性の高い基盤構築に向き合えるチーム体制の構築が不可欠です。 医療プラットフォーム SRE チームの発足 信頼性課題などの中長期的な課題解決を目指す医療プラットフォーム SRE チームを発足しました。CLINICS に限らず、医療プラットフォーム全体を対応範囲としています。先程述べたように、システム信頼性の課題は医療プラットフォーム全体の課題であるためです。SRE チームが医療プラットフォームの横断組織として機能することで、システム信頼性に関する知見を集約します。 まずは、医療プラットフォームの中でも 中心的な役割を担う大規模なシステムである CLINICS の信頼性向上を最優先課題としています。SRE チームは CLINICS での取り組みの中で得た知見を医療プラットフォーム全体に還元します。 2025 年 4 月現在、SRE チームは CLINICS プロダクトに専任する形で活動しています。一般に知られている Embedded SRE です。この形態では、SRE チームメンバーが開発チームに直接入り込み、密に連携しながら信頼性向上に取り組みます。 CLINICS の信頼性向上を目指した SRE の取り組み ここからは CLINICS に対して現在行っている取り組みを説明します。 SRE チームの役割とミッション CLINICS における SRE チームのミッションは 「事業成長を支え、安定した開発基盤と顧客の信頼性を維持する文化、仕組みを構築すること」 です。SRE チームは信頼性向上に専念することで、開発チームは機能開発に集中できる状態を目指し、CLINICS プロダクトは事業と品質の両輪での成長を図ります。 前半で述べた課題に対応するために、SRE チームの立ち上げ時にまず 3 つの重点目標を設定しました。それぞれの目標に対する取り組みと一部の成果を紹介します。 目標 1: トイル排除と中長期課題へのシフト 課題: 日常的な運用作業（トイル）を自動化し、少人数での複数システムの運用ができ、足元の課題から中長期的な課題へ時間を使えるようにする 主な取り組み: 既存インフラリソースの Terraform import を実施 : 新しいインフラリソースは Terraform で作成されていました。しかし、リリース初期から存在するリソースは違い、インフラ運用の属人化を引き起こしていました。Terraform import を定常的に実施し、誰でも実装可能で、レビューしやすい運用を実現しました。 定常的に発生する運用業務の自動化 : CLINICS は運用するシステムも多く、月次の更新処理や定常的なスケールアップ対応など、数多くの運用タスクがありました。 AWS Step Functions などにより定常的な業務を自動化し、運用負荷軽減を実現しました。 目標 2: 改善文化の浸透 課題: ポストモーテム 文化(障害後の振り返り文化)を確立し、再発防止が適切に実行され、改善課題が積み上がり続ける状態から脱する。 主な取り組み: ポストモーテムの標準化: 以前から振り返りの文化はありましたが、定式化されておらず、各々が各自の形式で振り返りを実施していました。 チームでのナレッジ共有がなされず、障害対応での属人化の要因となっていました。体系的に障害を振り返る仕組みを作り、CLINICS のチーム全体に展開することで、チームでの障害対応力を向上させました。 アラート改善を定常的に回す仕組みの策定 : 緊急性が高い事象や顧客とのコミュニケーションが必要な事象はアラートの検知時に迅速に解決できていました。しかし、タイミングの問題で発生する瑣末なフロントエンドのエラーなどは「オオカミ少年」になり、アラートを定期的に検知していました。開発チーム全体で根本対応できるものは実施する、すぐに解決が難しいものは一定期間無視するなど、対応ルールを精緻化しました。 目標 3: SLO による信頼性可視化 課題: CLINICS の関係者が納得できる 信頼性の指標(SLO) を構築し、改善施策はこれらの指標改善を優先する 主な取り組み: 重要な顧客体験 (Critical User Journey) の策定と SLO ダッシュボードの作成: CUJ(Critical User Journey) を特定し、Datadog 上に SLO のダッシュボードを作成しました。フロントエンドのパフォーマンスモニタリングを目的とした Datadog RUM(Realtime User Monitoring) などを導入することで、オブザーバビリティの強化も実現し、顧客体験をより厳密にトラッキングできるようにしました。 SLO モニタリングの実施: 作成したダッシュボードをもとに受付、診察、会計など 3 つの顧客体験について、可用性、レイテンシー、エラー率の目標値を設定しました。閾値の調整やエラーバジェットのモニタリングを定期実施し、アラート改善に役立てる取り組みを実現しました。 SRE チームにおけるその他の取り組み 上記の取り組み以外にも、SRE の一般的な以下の業務にも取り組んでいます。 事業成長を見越したキャパシティプランニング システムのモニタリングによる事前の課題発見 障害対応プロセスの改善 インフラコストの削減 DB 等のパフォーマンス問題の改善 ライブラリ対応やセキュリティ対応の効率化 アーキテクチャとリリースフローの改善…など SRE チームの取り組みの成果が実を結び始める これらの取り組みにより、CLINICS 開発メンバー全体（開発チームを含む）の運用負担が軽減されました。 信頼性の維持をしつつ、目の前の課題だけでなく将来を見据えた取り組みに注力する余裕が生まれています。開発チームとの協業を強化し、機能開発時に SLO の組み込みを進め、改善目標の指標としても活用する計画を立てています。他にも障害時の信頼性向上を目的とした Sidekiq Pro の導入など、信頼性向上にも取り組んでいます。 このように私たちの取り組みが徐々に成果を上げ始めています。 開発チームと SRE チームの協働により、当初実現したかった CLINICS の機能開発とシステム信頼性の両立が実現しつつあります 。今後もこの連携と SRE の取り組みを深め、より安定したサービス提供を目指してまいります。 医療プラットフォーム SRE チームとしての展望 ここまでは、CLINICS における SRE の取り組みを書いてきました。ここからは、今後医療プラットフォーム全体に SRE としてどのように貢献しようとしているのかの展望を述べます。 医療プラットフォーム全体への SRE ノウハウ展開 CLINICS での知見を活かし、今後、 Dentis や Pharms といった医療プラットフォームの他のプロダクトにも SRE のノウハウを展開していく予定です。 CLINICS は規模が大きく、信頼性要求も高いため、培ったノウハウは他のプロダクトにも十分応用できると考えています。ノウハウを展開することで、医療プラットフォーム全体での信頼性の底上げを実現します。 プロダクトの拡充に対して柔軟に対応できる仕組みづくり 医療プラットフォームは、「医療ヘルスケアの未来をつくる」というミッション実現のために、今後も新規開発や M&A によるプロダクト増加も見込まれます。 新たなプロダクトが加わった際にも、医療プラットフォーム標準の信頼性水準に迅速に引き上げることが重要です。 SRE チームは、医療プラットフォームに属する全てのプロダクトが高い信頼性を維持できる体制を目指します。 事業運営に関わる全関係者が納得する SRE 文化の醸成 SRE の取り組みは開発チームだけのものではありません。ポストモーテムや開発優先度の判断において、非開発メンバーの視点は不可欠です。プロダクトマネージャーや QA メンバーはもちろん、カスタマーサクセス・サポートチームも信頼性の考え方を共有することで、「なぜ機能開発より安定性向上を優先すべきか」といった判断に事業全体の納得感が生まれます。 SLO などの指標は単なる技術的な数値ではなく、顧客体験と事業成長を支える重要な要素です。医療プラットフォーム全体で信頼性と機能開発のバランスを適切に取りながら前進できる文化を育むこと、これも SRE チームの重要なミッションの一つです。 まとめ：医療ヘルスケアの未来を支える SRE 医療プラットフォームの SRE 立ち上げについてお伝えしました。医療プラットフォームの成長と「医療ヘルスケアの未来」創造のために、SRE による信頼性確保は欠かせないミッションです。 SRE としても医療プラットフォームとしても、挑戦したいことは山積みです。事業成長を加速し、医療機関と患者の体験を向上させるために、SRE の活動は不可欠です。 何より、「医療ヘルスケアの未来をつくる」というミッションに共感し、技術で医療の課題解決に貢献したいという情熱を持つ方をお待ちしています。私たちと一緒にこのミッションを実現しませんか？ 興味を持たれた方は、以下のリンクより、ぜひカジュアル面談の応募をお願いします。 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp

メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林( @terukura )です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組んでいますが、メドレーでは**「全職種が全業務で当たり前に AI を活用している企業：AI for All」**を目指して、それぞれの役割や業務に合わせた AI 活用を進めています。 メドレーでは「AI for All」を旗印に、AI 活用戦略を大きく 3 つの領域に分けています。 AI for All 1. AI 活用による業務オペレーションの効率化 ：日々の業務プロセスを AI で効率化し、ルーティンワークの時間を削減することで、より創造的な業務に集中できる環境を作ります。 2. AI 活用によるエンジニアリング生産性向上 ：開発サイクルの短縮と品質向上を実現し、より多くの価値を生み出せるようにします。 3. AI 活用によるプロダクト価値提供 ：ユーザーに直接価値を届ける AI 機能を実装し、メドレーのサービスをさらに進化させます。 またこれらの領域をそれぞれブーストさせるために、土台となる基礎活動もしっかり推進しています。 安心・安全な AI 活用のためのガイドライン整備 ：医療領域を扱う企業として、セキュリティとプライバシー保護は最優先事項です。社内では「AI ガイドライン」を整備し、明確な指針を提供することで、安心して AI ツールを活用できる環境を整えています。 AI Enabling ：全社の AI 活用レベルを底上げするため、様々な AI ツールや活用環境の整備、最新ツールの評価・共有、定期的な勉強会開催などを推進しています。社内 AI プラットフォームとして Dify を導入し、各部門が様々なモデルやフローの検証・活用を容易に行える環境を提供することで、技術的な障壁を低減しています。 今回の blog では、こうした全社的な取り組みの中でもエンジニア面談・面接でよく質問いただく 「AI 活用によるエンジニアリング生産性向上」 について、具体的な活用ツールなども踏まえてご紹介できればと思います。 プロダクト開発・エンジニアリングの変化 特に最近では、Claude Sonnet 3.7 の登場もあり、コーディング領域における AI 活用は大きなゲームチェンジを迎えていると感じています。 エンジニアリング生産性の飛躍的な向上が現実のものとなり、従来の開発スタイルを根本から見直す時期に来ています。 開発スタイルの変化 AI を活用しているエンジニアとそうでないエンジニアの間で、処理できるタスク量に大きな差が生まれつつあります。もちろん、AI が活用しやすい領域とそうでない領域があるものの、その差は想像以上に大きく、今後さらに拡大していくでしょう。 メドレーでは 2025 年末までに、プロダクト開発のあらゆる職種(PdM/QA/Design/Engineer)・工程において AI 活用率 100%を目指しています。これは単なる数値目標ではなく、全デベロッパーが AI を自分の「パートナー」として効果的に活用できる状態を実現するためのビジョンです。 活用している AI ツール メドレーのエンジニアリング組織では、様々な AI ツールを開発プロセスに組み込み、生産性と創造性を高めています。以下では、特に効果を発揮している主要なツールとその実際の活用シーンについてご紹介します。 コード生成・開発支援ツール: Cursor、GitHub Copilot、Cline、Windsurf 元々 GitHub Copilot は全社導入していましたが、最近では Cursor をはじめとする AI エージェントや AI 搭載コードエディタも全社で利用できる環境を整えています。 これらのツールは単なるコード補完にとどまらず、開発体験そのものを変革しています。 思考支援・問題解決ツール: Claude、ChatGPT、Gemini、NotebookLM 対話型 AI は、思考のパートナーとして日々活躍しています。特に複雑な課題に直面した際、これらのツールを活用して問題解決の糸口を見つけています。 UIUX のプロトタイピングにもこれらのツールが大いに貢献しています。特に artifact 生成機能を活用することで、アイデアから視覚的な UI 案まで素早く作成でき、PdM・デザイナー・エンジニア間のコミュニケーションが格段にスムーズになっていく兆しを感じています。 自律型開発エージェント: Devin Devin は、開発スタイルに新たな可能性をもたらしています。「非同期での開発」を可能にし、開発者が他のタスクに取り組んでいる間でも、定型的な開発作業や特定の機能実装を進めることが現実となってきています。 検証初月で約 1,500 ACUs（約 375 時間相当）の活用実績があり、Devin を活用しているデベロッパーも現在 80 名を超えています。今後も予算の一部を Devin に割り当て、さらなる活用強化を進めています。 AI 開発プラットフォーム: Dify Dify のようなプラットフォームは、社内の AI 活用の実験場となっています。様々なモデルやプロンプトの検証、複雑な AI ワークフローの構築など、AI の可能性を探求する基盤として活用しています。 AI ツール活用の今後の基本方針 これらのツールを適材適所で組み合わせることで、開発プロセス全体の効率化を実現し、全社員が AI を自分のパートナーとして活用できる環境づくりを進めています。 その際、私たちが特に重視している点は以下の 2 つです： 単なるツール導入にとどまらず、効果的な活用方法のナレッジを組織内で共有し、継続的に改善していくこと FourKeys を軸に開発生産性をモニタリングし、データに基づいた改善を進めること まだ過渡期ではありますが、すでに複数のチームで開発サイクルの短縮や品質向上といった、生産性向上の明確な兆候が表れ始めています。 推進・検証中の領域 以下の領域は現在積極的に推進・検証中です。成果が出次第、順次アウトプットしていきます。 AI×QA AI を活用したテスト自動生成によるテストカバレッジの向上と QA 工数の削減 エッジケースの自動検出機能による人間が見落としがちなバグの早期発見 AI× データマネージメント 大規模データセットからのインサイト抽出と意思決定支援 データクレンジングと前処理の自動化によるデータ品質向上 「AI ファースト」の開発フロー AI が理解しやすいコード構造とドキュメント体系の標準化 ナレッジやルールを AI が理解しやすい形で蓄積・管理 MCP の利用ルールとガードレールの整備 安全かつ効率的な AI 活用のための社内 MCP ポリシーとガードレール設計 ドメイン知識を組み込んだ自社 MCP の開発と展開 AI 活用時代のエンジニア採用・人材要件 AI ツールを効果的に活用できる思考力と指示能力を重視した採用基準 技術的深さと AI との協業スキルを評価する新たな人材ペルソナ AI 関連費用対効果・費用モニタリング 各種ツールのコスト・モデルのコストなど様々なコスト管理 生産性モニタリング 医療 ×AI の可能性 医療現場では従来から画像診断や遺伝子解析などの臨床領域で AI 活用が進んでいますが、その他の業務領域にも AI を取り入れることで、さらなる効率化や価値創出の可能性が広がっていると考えています。 患者情報の入力や整理、診療記録の作成、医療スタッフ間のコミュニケーション、スケジュール管理など、医療現場の日常業務に AI を活用することで、医療従事者の負担を軽減し、本来の患者ケアにより集中できる環境づくりにつながる可能性があると思います。 メドレーは医療 DX から医療 AX へと進化する中で、医療従事者と患者の双方に価値を提供できる独自のポジションにあります。今後も AI を活用した新しいプロダクトラインアップを発表予定ですので、ご期待ください！ We’re hiring メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！ カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me

メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林( @terukura )です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組んでいますが、メドレーでは**「全職種が全業務で当たり前に AI を活用している企業：AI for All」**を目指して、それぞれの役割や業務に合わせた AI 活用を進めています。 メドレーでは「AI for All」を旗印に、AI 活用戦略を大きく 3 つの領域に分けています。 AI for All 1. AI 活用による業務オペレーションの効率化 ：日々の業務プロセスを AI で効率化し、ルーティンワークの時間を削減することで、より創造的な業務に集中できる環境を作ります。 2. AI 活用によるエンジニアリング生産性向上 ：開発サイクルの短縮と品質向上を実現し、より多くの価値を生み出せるようにします。 3. AI 活用によるプロダクト価値提供 ：ユーザーに直接価値を届ける AI 機能を実装し、メドレーのサービスをさらに進化させます。 またこれらの領域をそれぞれブーストさせるために、土台となる基礎活動もしっかり推進しています。 安心・安全な AI 活用のためのガイドライン整備 ：医療領域を扱う企業として、セキュリティとプライバシー保護は最優先事項です。社内では「AI ガイドライン」を整備し、明確な指針を提供することで、安心して AI ツールを活用できる環境を整えています。 AI Enabling ：全社の AI 活用レベルを底上げするため、様々な AI ツールや活用環境の整備、最新ツールの評価・共有、定期的な勉強会開催などを推進しています。社内 AI プラットフォームとして Dify を導入し、各部門が様々なモデルやフローの検証・活用を容易に行える環境を提供することで、技術的な障壁を低減しています。 今回の blog では、こうした全社的な取り組みの中でもエンジニア面談・面接でよく質問いただく 「AI 活用によるエンジニアリング生産性向上」 について、具体的な活用ツールなども踏まえてご紹介できればと思います。 プロダクト開発・エンジニアリングの変化 特に最近では、Claude Sonnet 3.7 の登場もあり、コーディング領域における AI 活用は大きなゲームチェンジを迎えていると感じています。 エンジニアリング生産性の飛躍的な向上が現実のものとなり、従来の開発スタイルを根本から見直す時期に来ています。 開発スタイルの変化 AI を活用しているエンジニアとそうでないエンジニアの間で、処理できるタスク量に大きな差が生まれつつあります。もちろん、AI が活用しやすい領域とそうでない領域があるものの、その差は想像以上に大きく、今後さらに拡大していくでしょう。 メドレーでは 2025 年末までに、プロダクト開発のあらゆる職種(PdM/QA/Design/Engineer)・工程において AI 活用率 100%を目指しています。これは単なる数値目標ではなく、全デベロッパーが AI を自分の「パートナー」として効果的に活用できる状態を実現するためのビジョンです。 活用している AI ツール メドレーのエンジニアリング組織では、様々な AI ツールを開発プロセスに組み込み、生産性と創造性を高めています。以下では、特に効果を発揮している主要なツールとその実際の活用シーンについてご紹介します。 コード生成・開発支援ツール: Cursor、GitHub Copilot、Cline、Windsurf 元々 GitHub Copilot は全社導入していましたが、最近では Cursor をはじめとする AI エージェントや AI 搭載コードエディタも全社で利用できる環境を整えています。 これらのツールは単なるコード補完にとどまらず、開発体験そのものを変革しています。 思考支援・問題解決ツール: Claude、ChatGPT、Gemini、NotebookLM 対話型 AI は、思考のパートナーとして日々活躍しています。特に複雑な課題に直面した際、これらのツールを活用して問題解決の糸口を見つけています。 UIUX のプロトタイピングにもこれらのツールが大いに貢献しています。特に artifact 生成機能を活用することで、アイデアから視覚的な UI 案まで素早く作成でき、PdM・デザイナー・エンジニア間のコミュニケーションが格段にスムーズになっていく兆しを感じています。 自律型開発エージェント: Devin Devin は、開発スタイルに新たな可能性をもたらしています。「非同期での開発」を可能にし、開発者が他のタスクに取り組んでいる間でも、定型的な開発作業や特定の機能実装を進めることが現実となってきています。 検証初月で約 1,500 ACUs（約 375 時間相当）の活用実績があり、Devin を活用しているデベロッパーも現在 80 名を超えています。今後も予算の一部を Devin に割り当て、さらなる活用強化を進めています。 AI 開発プラットフォーム: Dify Dify のようなプラットフォームは、社内の AI 活用の実験場となっています。様々なモデルやプロンプトの検証、複雑な AI ワークフローの構築など、AI の可能性を探求する基盤として活用しています。 AI ツール活用の今後の基本方針 これらのツールを適材適所で組み合わせることで、開発プロセス全体の効率化を実現し、全社員が AI を自分のパートナーとして活用できる環境づくりを進めています。 その際、私たちが特に重視している点は以下の 2 つです： 単なるツール導入にとどまらず、効果的な活用方法のナレッジを組織内で共有し、継続的に改善していくこと FourKeys を軸に開発生産性をモニタリングし、データに基づいた改善を進めること まだ過渡期ではありますが、すでに複数のチームで開発サイクルの短縮や品質向上といった、生産性向上の明確な兆候が表れ始めています。 推進・検証中の領域 以下の領域は現在積極的に推進・検証中です。成果が出次第、順次アウトプットしていきます。 AI×QA AI を活用したテスト自動生成によるテストカバレッジの向上と QA 工数の削減 エッジケースの自動検出機能による人間が見落としがちなバグの早期発見 AI× データマネージメント 大規模データセットからのインサイト抽出と意思決定支援 データクレンジングと前処理の自動化によるデータ品質向上 「AI ファースト」の開発フロー AI が理解しやすいコード構造とドキュメント体系の標準化 ナレッジやルールを AI が理解しやすい形で蓄積・管理 MCP の利用ルールとガードレールの整備 安全かつ効率的な AI 活用のための社内 MCP ポリシーとガードレール設計 ドメイン知識を組み込んだ自社 MCP の開発と展開 AI 活用時代のエンジニア採用・人材要件 AI ツールを効果的に活用できる思考力と指示能力を重視した採用基準 技術的深さと AI との協業スキルを評価する新たな人材ペルソナ AI 関連費用対効果・費用モニタリング 各種ツールのコスト・モデルのコストなど様々なコスト管理 生産性モニタリング 医療 ×AI の可能性 医療現場では従来から画像診断や遺伝子解析などの臨床領域で AI 活用が進んでいますが、その他の業務領域にも AI を取り入れることで、さらなる効率化や価値創出の可能性が広がっていると考えています。 患者情報の入力や整理、診療記録の作成、医療スタッフ間のコミュニケーション、スケジュール管理など、医療現場の日常業務に AI を活用することで、医療従事者の負担を軽減し、本来の患者ケアにより集中できる環境づくりにつながる可能性があると思います。 メドレーは医療 DX から医療 AX へと進化する中で、医療従事者と患者の双方に価値を提供できる独自のポジションにあります。今後も AI を活用した新しいプロダクトラインアップを発表予定ですので、ご期待ください！ We’re hiring メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！ カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me

メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林( @terukura )です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組んでいますが、メドレーでは**「全職種が全業務で当たり前に AI を活用している企業：AI for All」**を目指して、それぞれの役割や業務に合わせた AI 活用を進めています。 メドレーでは「AI for All」を旗印に、AI 活用戦略を大きく 3 つの領域に分けています。 AI for All 1. AI 活用による業務オペレーションの効率化 ：日々の業務プロセスを AI で効率化し、ルーティンワークの時間を削減することで、より創造的な業務に集中できる環境を作ります。 2. AI 活用によるエンジニアリング生産性向上 ：開発サイクルの短縮と品質向上を実現し、より多くの価値を生み出せるようにします。 3. AI 活用によるプロダクト価値提供 ：ユーザーに直接価値を届ける AI 機能を実装し、メドレーのサービスをさらに進化させます。 またこれらの領域をそれぞれブーストさせるために、土台となる基礎活動もしっかり推進しています。 安心・安全な AI 活用のためのガイドライン整備 ：医療領域を扱う企業として、セキュリティとプライバシー保護は最優先事項です。社内では「AI ガイドライン」を整備し、明確な指針を提供することで、安心して AI ツールを活用できる環境を整えています。 AI Enabling ：全社の AI 活用レベルを底上げするため、様々な AI ツールや活用環境の整備、最新ツールの評価・共有、定期的な勉強会開催などを推進しています。社内 AI プラットフォームとして Dify を導入し、各部門が様々なモデルやフローの検証・活用を容易に行える環境を提供することで、技術的な障壁を低減しています。 今回の blog では、こうした全社的な取り組みの中でもエンジニア面談・面接でよく質問いただく 「AI 活用によるエンジニアリング生産性向上」 について、具体的な活用ツールなども踏まえてご紹介できればと思います。 プロダクト開発・エンジニアリングの変化 特に最近では、Claude Sonnet 3.7 の登場もあり、コーディング領域における AI 活用は大きなゲームチェンジを迎えていると感じています。 エンジニアリング生産性の飛躍的な向上が現実のものとなり、従来の開発スタイルを根本から見直す時期に来ています。 開発スタイルの変化 AI を活用しているエンジニアとそうでないエンジニアの間で、処理できるタスク量に大きな差が生まれつつあります。もちろん、AI が活用しやすい領域とそうでない領域があるものの、その差は想像以上に大きく、今後さらに拡大していくでしょう。 メドレーでは 2025 年末までに、プロダクト開発のあらゆる職種(PdM/QA/Design/Engineer)・工程において AI 活用率 100%を目指しています。これは単なる数値目標ではなく、全デベロッパーが AI を自分の「パートナー」として効果的に活用できる状態を実現するためのビジョンです。 活用している AI ツール メドレーのエンジニアリング組織では、様々な AI ツールを開発プロセスに組み込み、生産性と創造性を高めています。以下では、特に効果を発揮している主要なツールとその実際の活用シーンについてご紹介します。 コード生成・開発支援ツール: Cursor、GitHub Copilot、Cline、Windsurf 元々 GitHub Copilot は全社導入していましたが、最近では Cursor をはじめとする AI エージェントや AI 搭載コードエディタも全社で利用できる環境を整えています。 これらのツールは単なるコード補完にとどまらず、開発体験そのものを変革しています。 思考支援・問題解決ツール: Claude、ChatGPT、Gemini、NotebookLM 対話型 AI は、思考のパートナーとして日々活躍しています。特に複雑な課題に直面した際、これらのツールを活用して問題解決の糸口を見つけています。 UIUX のプロトタイピングにもこれらのツールが大いに貢献しています。特に artifact 生成機能を活用することで、アイデアから視覚的な UI 案まで素早く作成でき、PdM・デザイナー・エンジニア間のコミュニケーションが格段にスムーズになっていく兆しを感じています。 自律型開発エージェント: Devin Devin は、開発スタイルに新たな可能性をもたらしています。「非同期での開発」を可能にし、開発者が他のタスクに取り組んでいる間でも、定型的な開発作業や特定の機能実装を進めることが現実となってきています。 検証初月で約 1,500 ACUs（約 375 時間相当）の活用実績があり、Devin を活用しているデベロッパーも現在 80 名を超えています。今後も予算の一部を Devin に割り当て、さらなる活用強化を進めています。 AI 開発プラットフォーム: Dify Dify のようなプラットフォームは、社内の AI 活用の実験場となっています。様々なモデルやプロンプトの検証、複雑な AI ワークフローの構築など、AI の可能性を探求する基盤として活用しています。 AI ツール活用の今後の基本方針 これらのツールを適材適所で組み合わせることで、開発プロセス全体の効率化を実現し、全社員が AI を自分のパートナーとして活用できる環境づくりを進めています。 その際、私たちが特に重視している点は以下の 2 つです： 単なるツール導入にとどまらず、効果的な活用方法のナレッジを組織内で共有し、継続的に改善していくこと FourKeys を軸に開発生産性をモニタリングし、データに基づいた改善を進めること まだ過渡期ではありますが、すでに複数のチームで開発サイクルの短縮や品質向上といった、生産性向上の明確な兆候が表れ始めています。 推進・検証中の領域 以下の領域は現在積極的に推進・検証中です。成果が出次第、順次アウトプットしていきます。 AI×QA AI を活用したテスト自動生成によるテストカバレッジの向上と QA 工数の削減 エッジケースの自動検出機能による人間が見落としがちなバグの早期発見 AI× データマネージメント 大規模データセットからのインサイト抽出と意思決定支援 データクレンジングと前処理の自動化によるデータ品質向上 「AI ファースト」の開発フロー AI が理解しやすいコード構造とドキュメント体系の標準化 ナレッジやルールを AI が理解しやすい形で蓄積・管理 MCP の利用ルールとガードレールの整備 安全かつ効率的な AI 活用のための社内 MCP ポリシーとガードレール設計 ドメイン知識を組み込んだ自社 MCP の開発と展開 AI 活用時代のエンジニア採用・人材要件 AI ツールを効果的に活用できる思考力と指示能力を重視した採用基準 技術的深さと AI との協業スキルを評価する新たな人材ペルソナ AI 関連費用対効果・費用モニタリング 各種ツールのコスト・モデルのコストなど様々なコスト管理 生産性モニタリング 医療 ×AI の可能性 医療現場では従来から画像診断や遺伝子解析などの臨床領域で AI 活用が進んでいますが、その他の業務領域にも AI を取り入れることで、さらなる効率化や価値創出の可能性が広がっていると考えています。 患者情報の入力や整理、診療記録の作成、医療スタッフ間のコミュニケーション、スケジュール管理など、医療現場の日常業務に AI を活用することで、医療従事者の負担を軽減し、本来の患者ケアにより集中できる環境づくりにつながる可能性があると思います。 メドレーは医療 DX から医療 AX へと進化する中で、医療従事者と患者の双方に価値を提供できる独自のポジションにあります。今後も AI を活用した新しいプロダクトラインアップを発表予定ですので、ご期待ください！ We’re hiring メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！ カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me

メドレーの AI 活用戦略 こんにちは！メドレー株式会社 人材プラットフォーム本部 VPoE の倉林( @terukura )です。今回は、メドレーにおける AI 活用の取り組みについてご紹介します。 昨今、多くの企業が AI の活用に取り組んでいますが、メドレーでは**「全職種が全業務で当たり前に AI を活用している企業：AI for All」**を目指して、それぞれの役割や業務に合わせた AI 活用を進めています。 メドレーでは「AI for All」を旗印に、AI 活用戦略を大きく 3 つの領域に分けています。 AI for All 1. AI 活用による業務オペレーションの効率化 ：日々の業務プロセスを AI で効率化し、ルーティンワークの時間を削減することで、より創造的な業務に集中できる環境を作ります。 2. AI 活用によるエンジニアリング生産性向上 ：開発サイクルの短縮と品質向上を実現し、より多くの価値を生み出せるようにします。 3. AI 活用によるプロダクト価値提供 ：ユーザーに直接価値を届ける AI 機能を実装し、メドレーのサービスをさらに進化させます。 またこれらの領域をそれぞれブーストさせるために、土台となる基礎活動もしっかり推進しています。 安心・安全な AI 活用のためのガイドライン整備 ：医療領域を扱う企業として、セキュリティとプライバシー保護は最優先事項です。社内では「AI ガイドライン」を整備し、明確な指針を提供することで、安心して AI ツールを活用できる環境を整えています。 AI Enabling ：全社の AI 活用レベルを底上げするため、様々な AI ツールや活用環境の整備、最新ツールの評価・共有、定期的な勉強会開催などを推進しています。社内 AI プラットフォームとして Dify を導入し、各部門が様々なモデルやフローの検証・活用を容易に行える環境を提供することで、技術的な障壁を低減しています。 今回の blog では、こうした全社的な取り組みの中でもエンジニア面談・面接でよく質問いただく 「AI 活用によるエンジニアリング生産性向上」 について、具体的な活用ツールなども踏まえてご紹介できればと思います。 プロダクト開発・エンジニアリングの変化 特に最近では、Claude Sonnet 3.7 の登場もあり、コーディング領域における AI 活用は大きなゲームチェンジを迎えていると感じています。 エンジニアリング生産性の飛躍的な向上が現実のものとなり、従来の開発スタイルを根本から見直す時期に来ています。 開発スタイルの変化 AI を活用しているエンジニアとそうでないエンジニアの間で、処理できるタスク量に大きな差が生まれつつあります。もちろん、AI が活用しやすい領域とそうでない領域があるものの、その差は想像以上に大きく、今後さらに拡大していくでしょう。 メドレーでは 2025 年末までに、プロダクト開発のあらゆる職種(PdM/QA/Design/Engineer)・工程において AI 活用率 100%を目指しています。これは単なる数値目標ではなく、全デベロッパーが AI を自分の「パートナー」として効果的に活用できる状態を実現するためのビジョンです。 活用している AI ツール メドレーのエンジニアリング組織では、様々な AI ツールを開発プロセスに組み込み、生産性と創造性を高めています。以下では、特に効果を発揮している主要なツールとその実際の活用シーンについてご紹介します。 コード生成・開発支援ツール: Cursor、GitHub Copilot、Cline、Windsurf 元々 GitHub Copilot は全社導入していましたが、最近では Cursor をはじめとする AI エージェントや AI 搭載コードエディタも全社で利用できる環境を整えています。 これらのツールは単なるコード補完にとどまらず、開発体験そのものを変革しています。 思考支援・問題解決ツール: Claude、ChatGPT、Gemini、NotebookLM 対話型 AI は、思考のパートナーとして日々活躍しています。特に複雑な課題に直面した際、これらのツールを活用して問題解決の糸口を見つけています。 UIUX のプロトタイピングにもこれらのツールが大いに貢献しています。特に artifact 生成機能を活用することで、アイデアから視覚的な UI 案まで素早く作成でき、PdM・デザイナー・エンジニア間のコミュニケーションが格段にスムーズになっていく兆しを感じています。 自律型開発エージェント: Devin Devin は、開発スタイルに新たな可能性をもたらしています。「非同期での開発」を可能にし、開発者が他のタスクに取り組んでいる間でも、定型的な開発作業や特定の機能実装を進めることが現実となってきています。 検証初月で約 1,500 ACUs（約 375 時間相当）の活用実績があり、Devin を活用しているデベロッパーも現在 80 名を超えています。今後も予算の一部を Devin に割り当て、さらなる活用強化を進めています。 AI 開発プラットフォーム: Dify Dify のようなプラットフォームは、社内の AI 活用の実験場となっています。様々なモデルやプロンプトの検証、複雑な AI ワークフローの構築など、AI の可能性を探求する基盤として活用しています。 AI ツール活用の今後の基本方針 これらのツールを適材適所で組み合わせることで、開発プロセス全体の効率化を実現し、全社員が AI を自分のパートナーとして活用できる環境づくりを進めています。 その際、私たちが特に重視している点は以下の 2 つです： 単なるツール導入にとどまらず、効果的な活用方法のナレッジを組織内で共有し、継続的に改善していくこと FourKeys を軸に開発生産性をモニタリングし、データに基づいた改善を進めること まだ過渡期ではありますが、すでに複数のチームで開発サイクルの短縮や品質向上といった、生産性向上の明確な兆候が表れ始めています。 推進・検証中の領域 以下の領域は現在積極的に推進・検証中です。成果が出次第、順次アウトプットしていきます。 AI×QA AI を活用したテスト自動生成によるテストカバレッジの向上と QA 工数の削減 エッジケースの自動検出機能による人間が見落としがちなバグの早期発見 AI× データマネージメント 大規模データセットからのインサイト抽出と意思決定支援 データクレンジングと前処理の自動化によるデータ品質向上 「AI ファースト」の開発フロー AI が理解しやすいコード構造とドキュメント体系の標準化 ナレッジやルールを AI が理解しやすい形で蓄積・管理 MCP の利用ルールとガードレールの整備 安全かつ効率的な AI 活用のための社内 MCP ポリシーとガードレール設計 ドメイン知識を組み込んだ自社 MCP の開発と展開 AI 活用時代のエンジニア採用・人材要件 AI ツールを効果的に活用できる思考力と指示能力を重視した採用基準 技術的深さと AI との協業スキルを評価する新たな人材ペルソナ AI 関連費用対効果・費用モニタリング 各種ツールのコスト・モデルのコストなど様々なコスト管理 生産性モニタリング 医療 ×AI の可能性 医療現場では従来から画像診断や遺伝子解析などの臨床領域で AI 活用が進んでいますが、その他の業務領域にも AI を取り入れることで、さらなる効率化や価値創出の可能性が広がっていると考えています。 患者情報の入力や整理、診療記録の作成、医療スタッフ間のコミュニケーション、スケジュール管理など、医療現場の日常業務に AI を活用することで、医療従事者の負担を軽減し、本来の患者ケアにより集中できる環境づくりにつながる可能性があると思います。 メドレーは医療 DX から医療 AX へと進化する中で、医療従事者と患者の双方に価値を提供できる独自のポジションにあります。今後も AI を活用した新しいプロダクトラインアップを発表予定ですので、ご期待ください！ We’re hiring メドレーでは一緒に働く仲間を大募集しています。 AI と共に成長したいエンジニアの方 、ぜひお話させてください！ カジュアル面談も実施しております。話だけでも聞いてみたい!ちょっと雑談してみたい!でも構いませんので、お気軽にお問い合わせください！ 募集の一覧 募集の一覧 | 株式会社メドレー メドレーの採用情報はこちらからご確認ください。 www.medley.jp 医療エンジニアリング領域盛り上がっています！メドレーについてお話します！ メドレーの人材プラットフォーム事業についてお話しします！ 「メドレーの人材プラットフォーム事業についてお話しします！」- 倉林 昭和さん pitta.me