Findy Tools
開発ツールのレビューサイト
検索結果がありません

カケハシのマルチプロダクト インフラアーキテクチャ

Xのツイートボタン
このエントリーをはてなブックマークに追加
Xのツイートボタン
このエントリーをはてなブックマークに追加

カケハシのマルチプロダクト インフラアーキテクチャ

会員限定コンテンツです。無料登録すると制限なしでお読みいただけます。
無料登録してアーキテクチャを見る
最終更新日 投稿日

アーキテクチャの工夫ポイント

株式会社カケハシは、「日本の医療体験を、しなやかに。」をミッションに、薬局向けSaaSを複数開発・提供しています。複数のプロダクトがシームレスに連携し、一貫したユーザー体験を提供するためには、それらを支える強固な共通基盤が不可欠です。私の所属する「認証権限基盤チーム」は、全プロダクトの土台となる認証・認可、およびユーザー・組織情報の管理基盤を開発・運用することで、事業全体のスケールと開発スピード向上に貢献しています。

■ アーキテクチャ設計の背景
【医療業界の特性】
カケハシが提供するプロダクトのほとんどは医療情報システムとして患者情報を取り扱うため、セキュリティ要件が非常に厳しいことが特徴です。
例えば、厚労省・経産省・総務省が策定する通称「3省2ガイドライン」では、多要素認証の必須化、各種データの長期保存、パスワードポリシーの厳格化、監査ログの記録などが求められています。また、薬機法や個人情報保護法などの法令遵守も必要です。
加えて、可用性の高いシステム設計も求められます。医療機関は24時間365日稼働しており、システム障害が業務に与える影響は非常に大きいためです。
また、患者情報は非常にセンシティブな情報であるため、情報漏洩や不正アクセスを防止するための厳格なセキュリティ対策も不可欠です。一方で、薬局業界は法人間の薬局グループの統廃合が頻繁に発生するため、堅牢なテナント分離と柔軟な組織管理の両立が求められます。

【マルチプロダクト展開】
カケハシでは複数のプロダクトを展開している一方で、全てのお客様が同じプロダクトを利用しているわけではありません。例えば、ある薬局グループは電子薬歴システムを利用している一方で、別の薬局グループは在庫管理システムのみを利用している場合があります。
このような状況下では、全てのプロダクトで共通したライセンシング・認可・ロール管理の実現は困難です。

■ 方針
これらの背景を踏まえ、私たちはプロダクトチームが本質的な価値提供に集中できるよう、認証・アカウント・アセットなど共通の関心事を独立したサブドメインとして切り出し、それぞれに特化した基盤を運用しています。
また、基盤とプロダクトのインターフェースとしては、API・データ基盤・イベントバスなど目的に応じた複数の手段を用意し、柔軟な連携を可能にしています。
特に、カケハシのような可用性が重要なシステムでは、基盤の障害がプロダクト全体に波及しないように、S3などの耐障害性の高いストレージへParquet形式でデータを蓄積し、Databricksなどのデータ基盤から配信するアーキテクチャが有効です。
ただし、リアルタイム性が求められるユースケースでは、API連携やイベントドリブンな設計も必要です。

  • データ連携
    • 定期的に一貫性のあるデータセットを取得したい場合
    • リアルタイム性よりも耐障害性を重視したい場合
  • API連携
    • 特定のキーに基づいてリアルタイムにデータを取得したい場合
  • イベント連携
    • 変更イベントをトリガーに非同期処理を実行したい場合

■ 認証領域
これまでのカケハシでは、各プロダクトが独自に認証・認可を実装しており、以下のような課題がありました。

  • 開発効率
    • 各プロダクトで同じような認証ロジックを重複して実装している
    • それぞれで認証ロジックが微妙に異なるため、障害の温床となる
  • セキュリティ
    • 法令やガイドラインの改定に伴うセキュリティ要件の変更に伴い、各プロダクトで個別に対応する必要がある
    • ガイドライン改定の度に、各プロダクトチームが独自にガイドラインを解釈して実装するため、解釈の違いによるセキュリティホールが発生するリスクがある

特に、2026年度から多要素認証が必須化されることが決定しており、全プロダクトでの対応が急務となっています。加えて、パスワードポリシーの要件や監査ログの保存要件も厳格化されており、プロダクトチームの負担が増大しています。
そこで、認証権限基盤チームでは以下のような取り組みを進めています。

  1. OpenID Connectによる認証基盤の構築
  2. 監査ログの一元的な記録と配信
  3. パスワードポリシーの一元管理
  4. 多要素認証の導入

一方で、プロダクトごとに異なる認可ロジックやロール管理については、各プロダクトの特性に応じた柔軟な実装が求められるため、認証基盤ではなく各プロダクトでの実装を継続しています。
ただし、認可ロジックの実装にあたって必要なユーザー属性や組織情報については、認証結果として提供することで、プロダクトチームの負担軽減を図っています。
また、OpenID Connectは非常に柔軟な仕様であり、「どの認証手段を要求するか」「どの画面の表示を強制/禁止するか」などを認証リクエストごとに細かく指定できるため、プロダクトごとに異なる要件にも柔軟に対応できます。よって、プロダクトごとの個別要件を安易に認証基盤に取り込むのではなく、OpenID Connectの仕様を最大限活用することで、認証基盤の複雑化を防ぎ、運用コストの増大を抑制しています。

■ アセット基盤領域
アセット基盤は、主に端末管理とライセンス管理の2つの機能を提供しています。
実は、このシステムは一部のプロダクトでしか利用されておらず、全プロダクトで共通化する必要性は低いのですが、次の理由から共通基盤として切り出しています。

【CRM・台帳システムとの連携】
ライセンス管理のためには、顧客の契約情報やユーザー・店舗情報が必要であり、CRMや台帳システムと連携する必要があります。
これらのシステムに関する知見はプロダクトチームに蓄積されておらず、中長期的にプロダクトチームで開発・運用し続けることは困難です。
一方、従来より存在しているアカウント基盤は、顧客の契約時にユーザー・店舗情報を作成・変更するために、CRMと連携しています。
このように、プラットフォームシステムの実現にはCRM・台帳システムなどの外部システムと連携が必要となる場合が多く、ナレッジが社内に蓄積されているプラットフォームチームが担当することが合理的です。
つまり、「システムとしてリソース効率性のある共通化」を目指すのではなく、「ナレッジや関心を集約することによる運用効率性の向上」を目指しています。

■ データ基盤
それぞれのプラットフォームシステムは共通するデータ基盤へデータを蓄積し、Databricksなどの分析基盤からアクセスできるようにしています。
蓄積されるデータはDelta Lake形式でS3などの耐障害性の高いストレージに保存され、耐障害性と一貫性が確保されています。加えて、過去のデータのバージョンを容易に参照できるため、各プロダクトチームの障害発生時にプラットフォームチームで迅速に調査対応できます。
その他、それぞれのプラットフォームシステムで発生したビジネスイベントもデータ基盤へ配信されています。今後、これらのイベントをリアルタイム配信することで、各プロダクトの運用効率化を図る予定です。

今後の展望

■ 契約データの一元管理と配信
現在、契約データはCRMに保存されていますが、各プロダクトで利用するためにはAPI連携やバッチ処理などで個別に取得する必要があります。加えて、CRMはあくまで契約管理を目的としたシステムであり、各プロダクトの要件に応じた柔軟なデータ提供が困難です。
そこで、契約データを一元的に管理し、各プロダクトへ柔軟に配信するための契約基盤を構築する予定です。また、それに基づいたユーザー・店舗の変更イベントを併せて配信します。
これにより、各プロダクトチームは契約データの取得・更新やそれに伴う運用に関する負担を軽減でき、本質的な価値提供に集中できるようになります。

■ アカウント基盤データの抽象化と配信
現在、アカウント基盤は顧客のユーザー・店舗情報を管理していますが、各プロダクトで利用するためにはバッチ処理などで個別に取得する必要があります。
また、アカウント基盤に蓄積されたデータは抽象化が不十分であり、各プロダクトで独自に解釈・変換する必要があります。
そこで、アカウント基盤のデータモデルを抽象化した上で、各プロダクトへ柔軟に配信するための仕組みを構築する予定です。


◆執筆:認証・権限管理基盤チーム エンジニア 岩佐 幸翠

アーキテクチャを構成するツール

会社情報

株式会社カケハシ

株式会社カケハシ

カケハシは「日本の医療体験を、しなやかに。」をミッションとし、服薬指導のサポートも行えるクラウド型電子薬歴システム「Musubi」、薬局と患者さんをつなぐおくすり連絡帳システム「Pocket Musubi」、薬局向けの在庫管理・発注システムである「Musubi AI在庫管理」などを開発しています。 Musubi AI 在庫管理は、AI による高精度な需要予測により、これまで人的オペレーションに依存していた発注業務を半自動化し、薬局の業務効率化と医薬品の欠品・在庫リスク軽減を実現しています。