開発チームが信頼性向上のためにできること: 医療SaaS企業を支える共通基盤の挑戦 by kosui

SRE Kaigi 2026
セッション（30分）

開発チームが信頼性向上のためにできること: 医療SaaS企業を支える共通基盤の挑戦

kosui_me kosui kosui_me
2

■ 発表カテゴリ

・Architecture: SREの視点からのシステム設計

■ 発表概要（400字程度）

医療分野のSaaSでは、サービス提供者、顧客、そして何よりも患者にとって、セキュリティと可用性が最重要です。

私たちカケハシは、4つ以上の薬局向けSaaSを開発・運用する中で、厳しい医療要件とマルチプロダクト展開の課題に直面しました。私たちの組織規模や事業フェーズでは、イネイブリングを担うSREチームのみならず、基盤システムを開発・運用する開発チーム自身が信頼性へのオーナーシップを持つことが最も効果的だと考えました。

このセッションでは、共通基盤の開発チームが主体となり、以下の課題にアーキテクチャレベルで取り組んだ事例を紹介します。

  • 品質要求の相反
    高い可用性とセキュリティ要件を満たしつつ、データの整合性・一貫性も確保する必要がある
  • 顧客データのトレーサビリティ欠如
    障害発生時の原因調査やコンプライアンス対応が困難

これらの取り組みにより、新プロダクト開発時の認証実装コストを大幅に削減し、障害発生時の原因特定にかかる時間を短縮することに成功しました。

本セッションを通じて、SREという役割を持たない開発チームが、いかにしてサービスの信頼性を向上させられるか、具体的な方法を提案します。

■ 発表の詳細（1000字程度）

背景

医療業界の特性

カケハシが提供するプロダクトのほとんどは医療情報システムとして患者情報を取り扱うため、セキュリティ要件が非常に厳しいことが特徴です。
例えば、厚労省・経産省・総務省が策定する通称「3省2ガイドライン」では、多要素認証の必須化、各種データの長期保存、パスワードポリシーの厳格化、監査ログの記録などが求められています。また、薬機法や個人情報保護法などの法令遵守も必要です。

加えて、可用性の高いシステム設計も求められます。医療機関は24時間365日稼働しており、システム障害が業務に与える影響は非常に大きいためです。
また、患者情報は非常にセンシティブな情報であるため、情報漏洩や不正アクセスを防止するための厳格なセキュリティ対策も不可欠です。一方で、薬局業界は法人間の薬局グループの統廃合が頻繁に発生するため、堅牢なテナント分離と柔軟な組織管理の両立が求められます。

マルチプロダクト展開

カケハシでは複数のプロダクトを展開している一方で、各プロダクトは独立した開発チームが担当しています。これにより、各チームは自律的にプロダクトの開発・運用を行うことができますが、同時に共通の課題として以下の点が挙げられます。

  • 品質のばらつき
    各チームが独自に共通機能を実装しているため、セキュリティ要件の解釈や実装方法にばらつきが生じ、全体としての品質が低下するリスクがあります。
  • 開発コストの増大
    各チームが同じような機能をゼロから実装するため、開発リソースが分散し、効率的な開発が難しくなります。

課題

品質要求の相反

認証基盤の刷新プロジェクトでは高い稼働率とセキュリティ要件を満たす必要がある一方で、ユーザー・店舗・組織などのディレクトリサービスでは稼働率に加えデータの整合性・一貫性が求められます。これらを両立するために、インフラアーキテクチャとアプリケーションアーキテクチャの両面で工夫が必要でした。

トレーサビリティの欠如

既存の顧客基盤では、最新のデータのみが保存され、過去に顧客がどのようなユーザー・店舗・端末・ライセンスなどを保持していたかの履歴が保存されていませんでした。そのため、障害発生時の原因調査や、顧客のコンプライアンス要件への対応が困難でした。

解決策

インフラレイヤ - データの永続化と配信

  • PostgreSQLの行レベルセキュリティ
    顧客データを他の顧客から参照・変更できないようにするため、PostgreSQLの行レベルセキュリティを活用し、テーブルの行ごとに権限を制御しています。
  • DynamoDBとOutboxパターン
    認証基盤では、高い稼働率と障害時の復旧容易性を実現するため、セッション情報などをDynamoDBに保存しています。また、ログイン履歴などの変更データを他プロダクトに配信するためのOutboxパターンについても解説します。
  • Delta Lake形式によるデータ配信
    頻繁な変更が少ない顧客データ（ユーザー・店舗・組織など）はDelta Lake形式でS3に保存し、データ基盤や他プロダクトから参照できるようにしています。これにより、データの整合性を保ちながら、可用性とスケーラビリティを確保しています。さらに、Delta Lakeのタイムトラベル機能を活用することで、過去の状態を容易に再現できるようにしています。

アプリケーションレイヤ - データの整合性・一貫性とトレーサビリティの担保

  • ドメインイベントの永続化
    顧客のユーザー・店舗・端末・ライセンスなどの変更履歴をドメインイベントとして保存し、過去の状態を再現できるようにしています。これにより、障害発生時の原因調査やコンプライアンス要件への対応が容易になります。また、既存の顧客基盤に対してはデータ基盤を経由してスナップショットからドメインイベントを生成し、システムのフルリプレイスを避けつつ、トレーサビリティを確保しました。
  • マイクロサービスではなくサービスベースアーキテクチャの採用
    共通基盤が抱える顧客データは相互に強く関連し、強い整合性が求められます。そのため、マイクロサービスではなく、サービスベースアーキテクチャを採用し、単一のデータベースを共有することでデータの整合性を確保しています。加えて、各サービスではサービス間通信を原則禁止し、必要な場合は読み込み専用のDBユーザーを介してデータを参照する設計としています。

結果と教訓

結果

  • 開発効率の向上
    認証・認可基盤を共通化したことで、新規プロダクト開発時にセキュリティ要件をゼロから考慮する必要がなくなり、開発者は本来のビジネスロジックに集中できるようになりました。
  • 基盤の品質向上
    テナント分離とデータの整合性・一貫性、そして開発効率を両立するアーキテクチャを採用したことで、基盤全体の品質向上へ寄与しました。
  • 障害調査時間の短縮
    顧客データの変更履歴をドメインイベントとして完全に追跡できるようにした結果、データ不整合や意図しない変更が発生した際の調査が容易になり、原因特定までの時間が大幅に短縮されました。

教訓

  • RLSのマイグレーションとパフォーマンス
    誤った権限を適用するとデータ漏洩や欠損のリスクが生じます。
  • スナップショットからのイベント生成の課題
    既存システムのデータをドメインイベントに変換する際、データの一貫性を保つために、イベント生成の順序やタイミングに注意が必要です。
  • サービスベースアーキテクチャにおける共通ライブラリの危険性
    安易に共通ライブラリを導入すると、サービス間の結合度が高まり、独立したデプロイやスケーリングが困難になるリスクがあります。
  • 即時性とのトレードオフ
    顧客データの変更を即時に他プロダクトに反映する必要がある場合、Delta Lake形式での保存は適さないことがあります。

関連する過去の公開資料:

■ 対象聴衆とその人たちが得られるもの

  • 非SREチームであっても主体的にサービスの信頼性を高めたいと考えている開発者、テックリード
    具体的なアーキテクチャ設計や実装例を通じて、信頼性向上のための実践的な手法を学べます。
  • ミッションクリティカルなサービスにおいて、開発チームがどのようにセキュリティや可用性の向上に貢献できるかを知りたい方
    医療分野に限らず、厳しいセキュリティ要件や高可用性が求められるサービスにおいて、開発チームが果たすべき役割と具体的なアプローチを理解できます。

■ なぜこのトピックについて話したいのか（モチベーション）

マルチプロダクトSaaS企業に限らず、プロダクト同士が相互に連携するコンパウンドスタートアップでは、共通基盤の重要性が増しています。

しかし、多くの共通基盤チームはあくまでアプリケーションの開発者から構成されているため、SREのような専門的な役割を持たないことが一般的です。

そのような状況下で、限られたリソースしか持たない組織においても、開発チームが主体的にサービスの信頼性を高めることが可能であることを広く伝えたいと考えています。

医療業界に限らず、ミッションクリティカルな領域で日本や世界を支える開発者が、自らの手でサービスの信頼性を向上させ、ひいては人々の暮らしへ安寧をもたらすための一助となれば幸いです。