マルチプロダクトのインフラアーキテクチャ特集：6社の設計思想と技術選定

フリー株式会社

freeeは「スモールビジネスを、世界の主役に。」というミッションのもと、だれもが自由に経営できる統合型経営プラットフォームを実現します。日本発のSaaS型クラウドサービスとして、パートナーや金融機関と連携することでオープンなプラットフォームを構築し、「マジ価値」を提供し続けます。

現在のインフラアーキテクチャ設計の工夫

freeeは統合型経営プラットフォームを提供しており、会計や人事労務といった各プロダクト間のシームレスな統合体験を強みとしています。例えば、あるプロダクトで登録した情報が別プロダクトでも活用できるなど、一貫した統合体験が核となります。そのため、統一されたID管理・認証・認可は必須要件であり、これらの分野を専門とするチームが全プロダクトで利用する共通基盤をマイクロサービスとして開発・提供しています。

一方で個々のプロダクトは、それぞれが専門性を持ち素早くビジネス要求に応えるために、ビジネスロジックやインフラ構成はプロダクト毎に独立して管理されています。例えば、法改正への迅速な対応や特定の業界向け機能の追加など、各プロダクトが直面する課題は様々です。市場の変化に対応するには、各開発チームが他プロダクトへの影響を気にせず、俊敏に開発できる体制が重要だからです。

開発チームは、設計・開発・テスト・運用といったプロダクト開発の一連のライフサイクルの全工程に参画し、プロダクトを成長させることが求められています。チーム間の連携によるコミュニケーションコストや待ち時間が発生せず、すべての工程で得られるフィードバックが自チームに即座に伝わり、開発生産性が最大化される状態を目指しているからです。インフラの設計・構築・保守もプロダクトや共通基盤の開発チームが行いますが、各々が全てを管理すると、セキュリティ設定のばらつきや車輪の再発明といった非効率やガバナンス上の課題が発生します。
そこで、SREチームが開発の土台となる標準構成を用意しています。これにはAmazon EKSの雛形や、基本的な監視・アラートの仕組みなどが含まれます。各開発チームはこれを元にTerraform等のコードでインフラを構築し、自分たちで運用・監視をします。インフラの変更はすべてGitHubのPull Requestをベースにすることで、コードレビューによる統制を可能にします。これにより、開発の迅速性とガバナンスを両立させ、開発者が自律的にインフラを扱える環境を実現しています。

今後の展望

プロダクト開発チームの主務は、事業ドメインに集中して迅速に価値を提供することです。
そのためには、私たちが開発した共通基盤の仕組みを導入するために、本来の価値提供に集中できない期間があってはなりません。理想は、そうした仕組みに関する専門知識がなくとも、誰もが簡単に導入できる状態です。
共通基盤を開発する私たちのチームは、単に仕組みを提供するだけでなく、プロダクト開発チーム全体の生産性や開発者体験を向上させる存在を目指していきます。そのために、誤った使い方を未然に防ぐガードレールの整備などを日々検討しています。

◆執筆：飯岡巧巳　IAM基盤開発部　バックエンドエンジニア　@haton14_jp

【フリー株式会社のエンジニア求人】
https://findy-code.io/companies/176/jobs

株式会社Hacobu

株式会社Hacobuは、物流領域に特化したクラウド型SaaS「MOVO（ムーボ）」シリーズを展開しています。トラック予約受付サービス「MOVO Berth」、動態管理サービス「MOVO Fleet」、配車受発注・管理サービス「MOVO Vista」など、複数のプロダクトを通じて物流現場の効率化を支援しています。私たちPlatformチームは、それら複数プロダクトを下支えする共通基盤の開発・運用を担っています。

現在のインフラアーキテクチャ設計の工夫

Hacobuのインフラは「共通化」と「分離」のバランスを取りながら設計されています。共通化は主に複数プロダクトで横断的に使われる機能を対象とし、逆にプロダクトごとに独立性を保ちたい部分や、障害の影響を限定したい部分は分離しています。

共通化されている部分としては、認証・ユーザ基盤や共通マスタデータ、通知サービスなどがあります。これらは全プロダクトで同じ仕組みを使えるよう、Platformチームが一元管理しています。また、EKS・Istio・Argo CDといったKubernetes基盤も共通化することで、運用効率を高め、プロダクトが増えても安定してスケールできる仕組みを実現しています。さらに、開発時によく利用される便利な機能をまとめた共通ライブラリを整備し、重複実装を避けつつ開発体験を向上させています。

一方で、DBやS3などのデータストアはプロダクトごとに専用のリソースを持ち、データの独立性を確保しています。サービス間通信についても、Istioを利用して認証を必須化することで、不要な相互通信を防ぎ、セキュアなプロダクト間通信を実現しています。また、CI/CDについては共通化せず、各プロダクトチームの裁量に任せています。これは、プロダクトごとに異なる開発体制やリリースサイクルがあり、自由度を確保することが俊敏な開発につながると考えているためです。ただし、Kubernetesへのデプロイに関してはGitOpsを基盤として共通化しており、Argo CDを利用することで一貫性を担保しています。

共通基盤を活かしつつ各プロダクトの生産性を高めるために、Platformチームではさまざまな工夫を行っています。Datadogを活用してログやメトリクスを横断的に収集し、プロダクトを跨いだ統一的な監視を実現しています。TerraformはAtlantis経由で扱えるようにし、プロダクトエンジニアも安全にplan/applyできる仕組みを整えました。また、Argo CDによるGitOps運用を導入し、Kubernetesへのデプロイを標準化をしています。さらに、Platformチームとプロダクトチームの定例を月に一度設け、課題やベストプラクティスを共有することで、共通基盤を継続的に改善しています。

今後の展望

今後は「開発者体験のさらなる改善」を軸に、各プロダクトチームがより自律的に動けるよう、自動化やセルフサービス化を進めていきます。たとえば新規プロダクトの構築やモニタリング設定など、これまでPlatformチームが担っていた作業をセルフサービス化することで、プロダクトチームの開発スピードを一層高めたいと考えています。

また、コストの可視化にも取り組みます。各プロダクトが自分たちのインフラやオブザーバビリティの利用コストを簡単に把握できる仕組みを整備し、より健全で持続可能なサービス運用を実現することを目指しています。

さらに、ユーザーに安心してサービスを利用していただけるよう、セキュリティ面の強化にも注力します。共通基盤の信頼性強化やインフラのセキュリティ改善を継続的に進め、信頼性の高いプラットフォームを提供していきます。

◆執筆： 栗山 聖　テクノロジー本部　CTO室　プロダクト基盤部　@sheepland

【株式会社Hacobuのエンジニア求人】
https://findy-code.io/companies/667/jobs

株式会社カケハシ

株式会社カケハシは、「日本の医療体験を、しなやかに。」をミッションに、薬局向け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はあくまで契約管理を目的としたシステムであり、各プロダクトの要件に応じた柔軟なデータ提供が困難です。
そこで、契約データを一元的に管理し、各プロダクトへ柔軟に配信するための契約基盤を構築する予定です。また、それに基づいたユーザー・店舗の変更イベントを併せて配信します。
これにより、各プロダクトチームは契約データの取得・更新やそれに伴う運用に関する負担を軽減でき、本質的な価値提供に集中できるようになります。

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

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

【株式会社カケハシの求人】
https://recruit.kakehashi.life/
※ 株式会社カケハシの公式採用ページに飛びます

株式会社LayerX

LayerXは「すべての経済活動を、デジタル化する。」をミッションに掲げるSaaS+FinTechスタートアップです。 今回は、法人支出管理サービス「バクラク」のアーキテクチャについてご説明します。

現在のインフラアーキテクチャ設計の工夫

バクラク事業部では「経費精算」「請求書受取」「ビジネスカード」など法人支出管理に関わる複数のプロダクトを提供しています。
お客様があるプロダクトを一つだけ利用するだけでなく、複数のプロダクトを利用していただくことで共通のデータを統合したシームレスでより良い体験を提供することを目指しています。これを実現するにはプロダクト間の多様な連携が不可欠です。
そこで、プロダクトを跨いで集約されたGraphQLスキーマを導入し、GraphQLサーバ (graphql-gateway) を中心とするアーキテクチャに移行しています。各プロダクトのウェブアプリはgraphql-gatewayに問い合わせることで必要な情報にアクセスします。graphql-gatewayの裏側では、Protobufで定義した責務を実装するGoのConnect (https://connectrpc.com/) サービスが多数動作しており、各プロダクトの特定ドメインのデータを取得したり、またはプロダクトによらず共通で利用できるデータをサーブしたりします。graphql-gatewayとConnectのサービスは、ビジネスドメインに集中するべくコード生成を活用したmonorepoで開発しています。

今後の展望

ドメインの内部インタフェースのConnect化とgraphql-gatewayによるプロダクトを跨いだ集約の実現はこのアーキテクチャの目標の1つですが、まだ道半ばであり絶賛進行中です。一方で従来のプロダクトごとのBackend APIを新しいmonorepoのアーキテクチャとどのように・どれくらいの期間やスコープで統合していくかなどは引き続き向き合っていく必要があります。

また、monorepoで開発するConnectのサービスは、可能な限り疎結合になるように小さい単位で論理的に分割されています。この論理的なサービスは物理的なECS FargateのServiceと一対一でマッピングするという設計を当初行いました。それから時が経ちサービス数は順調に増加し、執筆時点では50+のサービスが存在します。チーム数の増加は緩やかなこともあり、物理的なECS Serviceに論理的なサービスを集約させることでインフラやデプロイの取り回しを改善する計画を立てています。

◆執筆：バクラク事業部 Platform Engineering部 SREチーム テックリード 　@itkq

【株式会社LayerXのエンジニア求人】
https://findy-code.io/companies/485/jobs

Sansan株式会社

Sansan株式会社は「出会いからイノベーションを生み出す」をミッションとして掲げ、働き方を変えるDXサービスを提供しています。主なサービスとして、ビジネスデータベース「Sansan」や名刺アプリ「Eight」、経理DXサービス「Bill One」、AI契約データベース「Contract One」を国内外で提供しています。
その中で研究開発部では、Sansan をはじめ Eight、Bill One、Contract One、新規事業や営業部門など、さまざまな部署に対してアプリケーションや API、Batch を提供しています。

現在のインフラアーキテクチャ設計の工夫

研究開発部の実行基盤である「Circuit」は、Amazon Elastic Kubernetes Service（EKS）を中心に構築されており、シングルクラスタマルチテナントのアーキテクチャを採用しています。 理由として、Circuitを作り出した当時のリーダー曰く当初運用を考えたときにクラスターをテナントごと複数維持する体制と仕組みの構築はしばらくはできないだろうという判断だったそうです。そんなCircuitの構成としてノードは EC2 と karpenter用のFargate を併用し、ノードスケーリングは karpenter、Pod スケーリングは KEDA が担っています。多くのワークロードでは、Istio が提供するメトリクスやSQSのAPIを KEDA のスケーリング指標として活用し、リクエストレートやレイテンシーに応じた自動スケーリングを実現しています。

監視基盤は、Istio やアプリケーションから収集したメトリクスを OpenTelemetry Collector に集約し、Managed Prometheus に永続化する構成です。さらに、運用監視や基盤全体の可観測性向上のために Datadog を併用しています。ログについては、fluent-bitを利用しNamespace、Pod名によってロググループを分けて保存しています。

テナントの分離境界としては、Namespace単位で定義したNodeClassを採用しています。 RBACなどの責務とNodePoolによる物理的な境界を設けることにより、他アプリケーションが Node を巻き込む障害を発生させた場合や、脆弱な Pod をデプロイしてしまった場合でも、別プロダクトのアプリケーションへの影響を最小限に抑えることができます。さらに、マルチテナント環境ではコスト按分が大きな課題となるため、NodeClass にコスト管理用のタグを付与し、各テナントの利用状況を可視化・按分できるようにしています。

(コスト按分に関しての詳しい話はこちらを参考にしてください)

開発者の生産性を上げる取り組みの観点では、API や Batch で共通的に利用できるCookiecutter による Manifest の テンプレートを用意しDocker Build / Push などのCIの共通化をしています。 また、ArgoCDを導入してよるほぼすべてのリソースを GitOps で管理することで、開発者は Kubernetes を深く意識することなく、容易に成果物をリリースできる環境を整えています。

今後の展望

今後の取り組みとして第一に挙げられるのは、可観測性の統合と向上です。
現在、監視ツールとしてDatadog、CloudWatch、Grafanaなどを併用しており、問題発生時には複数の画面を横断して調査する必要があるため、原因特定に時間を要しています。 加えて、トレースやカスタムメトリクスの可視化、他システムとのデータ連携が不十分であるため、アプリケーションの振る舞いを把握できるのが特定の開発者に限られ、属人化が進んでいます。その結果、バグ修正やパフォーマンス計測といった基本的な作業にも多くの時間が費やされているのが現状です。

こうした課題を解決するため、今後はテレメトリーデータを一元的に収集・可視化できる仕組みへ統合し、運用効率と可観測性の向上を目指します。
次に、マニフェスト管理の改善があります。従来のCookieCutterによる個別生成が、基盤全体の変更に対する追従性や管理コストの面で課題となっていました。特に、基盤に破壊的変更が生じた際、各マニフェストへの影響範囲の特定が難しく、変更の適用に多大な手間と時間がかかっていました。この問題を解決するため、今後は管理方式をHelmを用いたテンプレート化へと移行を予定しています。これにより、変更内容を一元的に管理・適用できる体制を整え、基盤の継続的な進化と安定性の両立を目指します。

◆執筆：上田 昂明 　@fresh_salmon256

【Sansan株式会社のエンジニア求人】
https://findy-code.io/companies/173/jobs

株式会社SmartHR

「SmartHR」は、人事・労務の業務効率化と、データ活用によるタレントマネジメントや組織のパフォーマンス向上を実現するクラウド人事労務ソフトです。労働にまつわる社会課題をなくし、誰もがその人らしく働ける社会の実現を目指し、働くすべての人の生産性向上を後押しします。私たちは、歴史に残る模範的なソフトウェアをつくる仲間を探しています。コアタイムなし、フルリモートワークOK。絶賛エンジニアを募集中です！

現在のインフラアーキテクチャ設計の工夫

　SmartHRは、基本機能と呼ばれるコア機能を提供するプロダクトと、オプション機能を提供する十数のプロダクトで構成されています。各プロダクトはそれぞれが独立したインフラアーキテクチャ上で稼働しており、データなどもプロダクト毎に管理しています。一方、従業員情報やアカウント情報といった共通データは基本機能で管理しており、基本機能〜オプション機能間でAPIを介してデータの連携をしています。

　現在は十数のプロダクトからなるSmartHRですが、サービス初期は新しい機能はSmartHR基本機能に実装されていました。しかし、機能が増えるにつれ開発速度の低下の課題が生じました。そこで、機能ごとにプロダクト・インフラを分離することで変更容易性を高め、開発スピードを向上させる決断をしました。合わせて、開発チームもプロダクト毎に分割し少人数チームを組成することで、スピード感あるプロダクト開発ができるようになりました。これが現在のSmartHRのマルチプロダクトの原型となっています。

　インフラが独立している一方で、基本のシステム構成はGoogle Cloudのマネージドサービスを積極的に採用した構成で統一されています。これは、インフラの運用・学習コストを下げプロダクト開発に集中できるようにするためです。また、インフラ構築にあたってはTerraformで構成管理するとともに、社内共通モジュールを整備することで構築までの時間の短縮やセキュリティの担保をしています。

　SmartHRは多くのプロダクトを提供する中で様々な課題に直面してきました。その一つに、プロダクト間のデータ連携があります。当初、プロダクト間のデータ連携は基本機能〜オプション機能間のみを想定していました。しかし、プロダクトが増えてくると、オプション機能間で相互にデータを参照したいといったニーズが生じました。この課題に対して、SmartHRではデータ基盤をGraphQL Federationで構築し、プロダクト間で相互データ連携を実現しています。 ※1

今後の展望

SmartHRは労務領域を出発点とし、タレントマネジメント領域や情シス領域などカバーする領域を拡大しています。また、2025年6月には「人的資本経営プラットフォーム」を目指すことを発表しました。この戦略を達成するため、そして増え続けるプロダクトを支えるために、プロダクト基盤のアーキテクチャの改善や機能の強化に取り組んでいます。

　SmartHRでは、これまでプロダクトごとにインフラを運用していましたが、プロダクトの増加に伴い、重複作業や運用コストが課題となっていました。この状況を改善するため、2024年にSREチームを立ち上げ、プロダクトの信頼性やスケーラビリティ向上に取り組んでいます。
　また、データ連携のようなマルチプロダクトを支える共通基盤づくりにも注力しています。ポリシーベースのアクセス制御やモジュラーモノリス化といったシステムの責務を明確に分割して成長できる仕組みの提供を通して、プロダクトチームがオーナーシップを持って自律的に価値を届けられる状態を目指して日々取り組んでいます。
※1 https://tech.smarthr.jp/entry/2024/07/09/114606

◆執筆：三上　拓也（みかみ　たくや）　技術統括本部　ESP・情シス開発本部　@mkmn252

【株式会社SmartHRのエンジニア求人】
https://findy-code.io/companies/334/jobs