株式会社アンチパターンについて

小笹：株式会社アンチパターンは、「日本のソフトウェアエンジニアを憧れの職業へ」という理念を掲げて活動しています。スタートアップとしては珍しく、複数のサービスを提供しています。私たちのお客様は基本的にソフトウェア企業やSaaS企業ですが、そういった企業の成長サイクルを「プロダクト作り」「資金作り」「組織作り」という3つの円で捉えています。

しっかりプロダクトが作れると、スタートアップの場合は企業価値が高まることでファイナンスができますし、お客様から収益を得ることでも資金作りが可能です。その資金をソフトウェアに再投資するということは、イコール人に投資することだと考えています。プロダクト作りと組織作りが相互連動して発展していくのがソフトウェア企業のあり方だと考え、お客様のプロダクト作りや組織作りを支援しています。

小笹：クラウド・SaaSという領域でずっと活動しておりまして、特にAWSのパートナー企業としてSaaSコンピテンシーという認定も受けています。多くのSaaSをデリバリーしてきましたし、私たち自身もSaaS提供事業者として活動しています。

今日のテーマはテナント戦略にまつわるSaaSのお話です。アジェンダとしては、まず「SaaSとは」というところで少し基礎的な内容も含めて共通認識をとっていきます。次に「SaaSのコントロールプレーン」、そして「アプリケーションプレーンとデプロイモデル」について説明し、最後に生成AIによってB2B SaaSの在りように求められている変化と対応についてお話しします。

SaaSとは──ビジネス成長を支えるアーキテクチャの重要性

小笹：私たちは単純に法人向けのソフトウェアをSaaSとして捉えているわけではありません。SaaSに合わせて業務プロセスを変革するというところが、価値の中心だと考えています。個別にソフトウェアを作るのではなく、そのソフトウェア自体がナレッジを提供し、SaaSに合わせて業務を変えていく。このフィット・トゥ・スタンダードという考え方が浸透していくところが、SaaSの素晴らしい点です。

特にアメリカでSaaSが発展している背景の一つに、人材の流動性の高さがあります。新しく入ってきた人が業務で素早く価値を発揮していかなければならないとき、個社ごとの業務プロセスがあまりに複雑だと、新しい方がジョインしても価値を発揮しづらくなります。そのため、プロセス自体をソフトウェアに乗せていくことが流行っていきました。人材流動性が少しずつ高まっている日本でも、このトレンドは注目されるべきだと考えています。

小笹：自社開発やパッケージソフトが一社の中で閉じていた世界から、SaaSを利用するというパラダイムになっていったときには、複数の企業が同じSaaSを相乗りして使っていくことになります。コストやリスクを割り勘効果で分担しながら価値を享受できるというのが、SaaS利用者側の大きなメリットです。

一方で、個社ごとに作っていたアプリケーションと違い、SaaS提供事業者のカバー範囲は一気に広がります。契約企業分すべてのシステム構築と運用の責務を負うことになります。ですから、システム構築・運用をいかに効率的にスケールさせられるかが事業成長の鍵を握ると言っても過言ではありません。

ビジネス成長を加速させるアーキテクチャが肝要です。AWSのre:Inventの図を引用していますが、マルチテナントSaaSにおける売り上げはテナント数が増えていくことでも実現されます。相乗りするテナントに対して共有効果を通じて効率的に運用ができれば、1テナント当たりのコストはテナント数が増えるほど集積効果が働いて下がっていきます。

小笹：いわゆるプロダクトマーケットフィットなどを経て顧客数が増大していくと、集積効果が働いて1テナント当たりのコストが下がり、利益率が高くなっていきます。とても素晴らしいモデルでは40%以上の利益率を叩き出すことができますが、これは集積効果を働かせられるアーキテクチャに起因しています。スケールメリットがしっかり生かせるアーキテクチャになっているかということが、ビジネスの成長を実現できるかにほぼイコールで関わってきます。

テナントとは、SaaSを利用するユーザーの契約単位のことです。提供形態によっては会社や部署がテナントになる場合もありますし、顧客のグループ一つ単位がテナントになる場合もあります。提供する先によってさまざまなテナントの定義があり得ます。

小笹：テナントが相乗りしていくところをオフィスビルに例えると、ビルにいろいろなテナントが入居し、共有設備や資源として水道・電気・ガス、共同のエントランスが設けられています。実はこれがSaaSのアーキテクチャでも同じように再現されています。

SaaSコントロールプレーン──テナント管理の要

小笹：先ほどのテナント区画と書いてあった部分がアプリケーションプレーンというもので、お客様に直接価値を提供する機能群です。会計ソフトウェアで言えば、請求書の送付や見積書の作成といった売上に直結する機能がこれに当たります。

小笹：一方で、どのB2B SaaSにも共通で必要な機能群をコントロールプレーンと呼びます。SaaS提供事業者向けの管理画面、テナント管理、ユーザー管理、認証認可の提供、料金プランの作成やテナントごとの請求といった機能群がコントロールプレーンに属します。

コントロールプレーンを考えるにあたって、一番わかりやすいユースケースはオンボーディングです。ユーザーがセルフサインアップするケースも、SaaS提供事業者が管理画面からテナント用のリソースを作成するケースもありますが、まずサインアップ行為が行われてオンボーディングサービスが動き出します。

新規テナントであればテナント情報を作成するサービスに情報が流れ、ユーザーも新しく登録されます。料金プランがフリープランなのかスタンダードプランなのかも管理され、請求管理がされ、そのテナント用のリソースが立ち上がるプロビジョニングが発生します。オンボーディングのプロセスで、コントロールプレーンがどういったものかをオーバービューできると思います。

小笹：コントロールプレーンの中で重要なのがアイデンティティの考え方です。SaaSではSaaSアイデンティティという名前でアイデンティティが定義されています。ユーザーID、メールアドレス、名前、役割といったユーザー個人に紐づくアイデンティティはユーザーアイデンティティです。

一方、マルチテナントSaaSではテナントアイデンティティも非常に重要です。テナントID、組織名、料金プランといったテナントに紐づく情報が求められます。このテナントアイデンティティとユーザーアイデンティティを紐づけてSaaSアイデンティティという考え方で管理していくことが重要になります。

小笹：テナントにまつわる情報をテナントコンテキストと呼びます。具体的には、SaaSアイデンティティの主たる情報、契約情報、多言語対応であれば言語やタイムゾーンといった設定情報、インフラレベルでのリソースのスコープ、AIサービスなどでの利用量や制限に関する情報などが含まれます。テナントそれぞれの固有情報一式となるため、各サービスで適切に利用することが重要です。

テナントコンテキストは一般的にはJWTなどを使って全サービスで活用していきます。ユーザーがアプリケーションにアクセスした際、まだ認証されていなければコントロールプレーンにリダイレクトされ、SaaSアイデンティティやテナントコンテキストの取得が行われます。認証が成功してユーザーの元に戻り、認証済みのアクセスでアプリケーションが立ち上がります。

小笹：以降バックエンドの呼び出しが行われていくわけですが、サービス間の連携がある場合にはテナントコンテキストをヘッダの中に入れて引き回して使っていくイメージになります。一度取ったものをヘッダーに入れてコンテキストを扱うことで、各サービスでいちいちコントロールプレーンへ問い合わせをせずとも、アプリケーション全体でテナントコンテキストの引き回しができるようになります。

テナントのルーティングにもこのコンテキストが重要な情報になります。テナント1、2、3がある中で、テナントルーティングと呼ばれるサービスを用いて、テナント1用のサービス群やテナント2、3用のサービス群に振り分けていきます。

このときにはドメイン駆動のような形で、テナントごとにサブドメインを使って切っていくやり方もありますし、認証の情報を引き回してデータ駆動でやっていくやり方もあります。どちらにしても、どのテナントかを特定してそのコンテキストを引き回していくというところは変わりません。

SaaSアプリケーションプレーンとデプロイモデル──テナント分離のパターン

小笹：サイロはマルチテナントSaaSのデプロイモデルの一つで、サーバーやデータベースのリソースセットがテナントごとに存在するパターンです。この中でもコードベースは一つというのが重要です。

小笹：プールはテナントA、B、Cがリソースセットを共有するパターンです。共用のインフラであっても、適切な論理分離が必要になってきます。

小笹：ブリッジ型は、A、B、Cがサーバ・コンピュート層はプールで共有するけれども、データベースはサイロ型のようなアーキテクチャでやっていくパターンです。この分離がどういった状態であるかはプログラムのほうで考えすぎないよう抽象化していくことが重要です。コンピュート側がサイロでデータベース側がプールになっているブリッジも考えられます。

小笹：データベースの中での分離には、データベースレベルでの分離もありますし、スキーマやテーブルでテナントを分離するパターンもあります。PostgreSQLの場合ですとRow Level Securityという考え方があり、行レベルで分離していくパターンもあります。セキュリティ要件や性能などでバランスを取って意思決定する必要があります。

サイロ、プール、ブリッジの中で、これが最強だというものは存在しません。それぞれメリット・デメリットがあります。サイロだとデータベースの切り替えを考えなくていいというメリットがありますし、プールだと運用コストは低いですが、テナント分離のやり方を間違えると漏洩のリスクがあります。

小笹：契約している料金プランによってハイブリッドなモデルを採択することも検討できます。低位なプランならみんなが共用するものにしておいて、アドバンスドティアのような上位のお客様にはSLAをコミットするのでそれ用のリソースセットを用意するという複合型のモデルも存在します。

マイクロサービスになっている方であれば、より発展的なミックスモードデプロイモデルも可能です。サービスごとにコンピュートとデータベースのデプロイモデルが異なるような採択の仕方もできます。初期の段階でどのデプロイモデルを採択したとしても、事業の成長や提供価値の変容によって継続的にアーキテクティングを行っていくことが重要です。

小笹：アーキテクチャを検討する上で非常に重要な要素が、技術的なところ以外にも存在します。それはビジネス要件とテナント要件です。対象市場のテナント数が極端に少なければ、わざわざプールで作らずサイロでいいかもしれません。

コンプライアンスについても、例えば金融系や医療系でデータベースを物理的に分離しておくべきことが省庁などで定義されているような市場であれば、そういった規定によってアーキテクチャを選択しなければいけません。高い可用性を求められる場合にはコンピュート層をしっかり分離する必要があるケースもあります。

小笹：具体的な問いと選択で考えていきますと、セキュリティやコンプライアンスで完全物理分離が必要であればサイロにならざるを得ません。市場における想定テナント数が少なければサイロ、逆にすごく多ければプールから始めないとリソースセットがあまりに多すぎて運用が難しくなります。

性能要求がどの程度シビアかによっても、コンピューティングリソースに対するシビアさなのかデータベースリソースに対するシビアさなのかで、ブリッジモデルの形が決まってきます。

小笹：ここで注意が必要な点があります。専有インフラを作る、つまりサイロ型はテナントの境界を明確にはしてくれます。しかし、テナントコンテキストの扱いを間違えてしまうと、当然漏洩は起こり得ます。境界を明確にはするけれども、境界を保障してくれるものではありません。そこを間違えないよう、十分に注意して設計する必要があります。

特にコンプライアンスの観点で、なぜ完全に分離しなければいけないのかと考えたくなりますが、説明コストを考えるとサイロであったほうがいいケースはあります。技術的な観点だけでなく、テナント境界を明確にする必要があるケースが存在することは十分に意識していただければと思います。

生成AIによる変化と対応──新たな課題への取り組み

小笹：ここからは、生成AIが出てきたことによって従来のSaaSの在り方に加わった変化と、その対応策についてお話しします。

まず一つがコンプライアンス対応です。生成AIでは、モデルがデータを学習しないかなど、さまざまな観点での問い合わせが増えていると思います。

その中で新しいデプロイモデルとして出てきているのが、生成AI活用のSaaSにおけるアカウントレベルのブリッジパターンです。SaaS提供事業者側にはアプリケーションやデータベース、汎用的な基盤モデルがあります。一方、お客様のAWSアカウント内には、テナントデータで学習・チューニングされた基盤モデルが置かれます。SaaS提供事業者のアプリケーションから、お客様のAWSアカウント内にあるこのチューニング済みモデルへアクセスするという構成です。データの所有自体をお客様のAWSアカウント内に閉じることで、データを所有している主管はお客様にあるということを担保するモデルです。

小笹：コンプライアンス上は非常に利便性がいいのですが、アプリケーションのデプロイやデータを取得するためのAssumeRoleの仕組みが必要になるので開発コストは上がります。また、お客様がAWSアカウントをどの程度触れるべきかというガードレールをOUなどで設計する必要も出てきます。

認可についても、生成AIによってさらに複雑性が増加しています。テナント横断ではなく、同一テナント内でもルーティングが必要になってくるケースが出てきています。

小笹：特にRAGのシステムで起きている構造なのですが、ユーザーAとユーザーBのロールが違う場合にアクセスしていいベクトルDBが変わってくるというものです。例えば労務系のソフトウェアで人材をレコメンドしてくれるAI問い合わせ機能があったとき、ある権限のユーザーには給与情報も含めたベクトルDBを検索していいけれど、一般ユーザーには給与情報が考慮されていないベクトルDBに問い合わせがいくようにする、というユースケースです。

同じテナント内なのにリソースが変わるというのは、今までにはなかった問い合わせの仕方になります。SaaSアイデンティティの重要性が増している例の一つですね。

テナント情報漏洩のリスク箇所も増加しています。LLMを使って問い合わせをして答えを返すシステムでは、毎回LLMに問い合わせるとコストがかかるのでキャッシュを作成することが多いと思います。

小笹：しかし、キャッシュを作成する際にテナントコンテキストの情報を含めてキャッシュに登録しておかないと非常に危険です。例えばテナントAの方が「今月の売上を教えてください」と問い合わせてキャッシュを作成するとき、テナントIDをキーにキャッシュしておかないと、テナントBの人が同じ質問をしたときにキャッシュから返してしまい、テナントAの売上情報を返してしまうことになります。

テナントコンテキストは情報を取得する際に使うだけでなく、情報を作る際にも利用しておかないと、テナント情報が漏洩するリスクを増加させます。情報を登録するときにも、本当にそのテナントごとの情報なのかに着目することが重要です。

プライシングについても頭を悩ませています。従来のSaaS開発よりもテナントごとのコスト変動があまりにも大きすぎるのです。

小笹：アプリケーションでテナントごとに問い合わせが発生してLLMを使っている場合、テナントCはLLMの問い合わせが多くて原価がすごく高まっているのにテナントAはそうではない、というばらつきが非常に大きくなってきます。コントロールプレーンでのスロットリングなど制限を適切に設ける必要がありますし、多くのLLMサービスが使っているトークンという考え方で先にトークンの数量を買ってもらい、キャッシュフローを正常化させるアプローチも重要です。

昨今では、初期段階でサイロのアーキテクチャでやり始めて、インフラ原価に利益を乗せるコストプラス方式でスタートし、事業検証ができて価値の総量が確認できた段階からプライシングを変更するというスタートアップも出てきています。利益率は高くできないかもしれませんが、キャッシュフロー上の安全性は担保できる現実的なアプローチだと考えています。

また、AIエージェント開発におけるコア部分とテナント最適化部分の境界を考えることが非常に難しいというのが、AI時代のSaaSの問題です。

小笹：アプリケーションプレーンを俯瞰すると、テナント横断で共通のコンポーネントであるコア部分がある中で、テナント1用、テナント2用にLLMの選択やプロンプト、メモリーが存在するという状態になります。AIエージェントの品質は、いきなり精度が100%のものが出せるわけではなく、フィードバックループを回していくことが重要です。

小笹：テナントユーザーからのフィードバックデータを収集し、AIエージェント開発者が生成過程のデータを確認していくわけですが、プロンプトがコアとテナント用で全然違うというように個別最適化しすぎると完全に別システムになってしまいます。そうなると、コアの部分のチューニングをすればいいのかテナントごとの個別最適部分のチューニングをすればいいのか判断しづらくなり、フィードバックループを最適な形で回せなくなります。

小笹：集積すること、チューニングできる状態にすること、生成過程をオブザーブしていくことは重要ですが、コアの部分とテナント最適の部分がどういった棲み分けになっているかを把握したうえでデータを集めていかないと、品質を全体として向上させられない点は注意すべきポイントです。

具体的な対応策として、コントロールプレーンが担う要素が新しく追加されています。『マルチテナントSaaSアーキテクチャの構築』という本の作者であるトッド・ゴールディングスさんがAWS上で公開しているコンテンツによると、ガードレール、メモリ、ナレッジ/ツールズという3つの要素があります。

小笹：ガードレールはエージェントが行ってよい行動や出力の範囲を制限するもので、テナントの特定データへのアクセス制御だけでなく、禁止ワードやポリシーに基づいた制御を担います。メモリーはエージェントが過去にどういったやりとりをしていたかを保存するもので、会話の履歴やテナント別の履歴のストレージになります。ナレッジ/ツールズはエージェントが参照・利用してよい外部のリソースや機能群で、プロンプトやRAGのナレッジベース、外部SaaSへのMCP経由のAPIコールなどが含まれます。

全体として品質を向上させていくアプローチとして、さまざまなAIエージェントサービスを確認して私が考えているものが3つあります。

小笹：1つ目は、制限をかけることです。ユーザーができる行動や出力の範囲を制御し、入力の自由度を減らすことが提供事業者としての工夫になります。エンドユーザーがプロンプトを自由に書きすぎると全体の品質を一定化するのが難しくなりますので、例えば対話型AIサービスであれば、柔和なしゃべり方か論理的なしゃべり方かをセレクターで設定できるようにするといったコンフィグレーションを設けることで、プロンプトで定義しなくてもユーザーが実現したい態度をAIエージェントに求められるようになります。

2つ目は、インセンティブを一致させることです。IntercomというカスタマーサポートのAIサービスでは、問い合わせてきたユーザーへの回答をAIエージェントが100%、つまり人間が介在しないで解決した場合に初めて課金されるというプライシングモデルになっています。これによりユーザー側はエージェントを育てることにインセンティブが働きます。RAGのデータソースを追加したりプロンプトをチューニングしたりといったことによって、ビジネス的な構造で全体の品質を高めることができます。

3つ目は、評価基盤を作ることです。テナント情報をもとに生成したデータそのものは機微なデータが多く含まれるのでSaaS提供事業者でも見られないものだと思います。ですから、生成データそのものではなくメタデータとして抽象化された特徴量のセットを用いて評価をメタ的に行っていきます。こういった構造データを用いて評価基盤を作ることで、テナント最適化されている部分があっても全体の品質を上げるアプローチが可能になります。

まとめ

小笹：改めてSaaSとは「ある業務に対するベストプラクティスを提供するビジネスおよびソフトウェアデリバリーのモデル」だと私たちは考えています。

AI時代になったことで、むしろテナントをどう扱っていくかがより重要になりましたし、よりシビアになったと感じています。事業戦略とテナント戦略、そして結果的なアーキテクティングは非常に密接に絡んでいるため、どういう事業計画を描いているのかをエンジニアとしてもビジネスサイドとよく話し合っていく必要があります。

正解がない中ではあるのですが、エンジニアとしては非常に楽しめる部分だと思っています。一緒に頭を悩ませていただければ嬉しいです。

SaaSus Platformのご紹介

小笹：私自身もSaaSを作ってきたことと、米国の最新トレンドを取り入れて、SaaSの開発・運用・販売を支援するSaaSとして「SaaSus Platform」を提供しています。SaaSのコントロールプレーンをソフトウェアで提供するというもので、管理画面とSDK・APIの形で機能提供しています。

小笹：どのSaaSにも共通で必要な部分なので、ここを私たちはビジネスとして捉えています。新しくSaaSを作る際や、既存のアプリケーションをSaaS化したいとき、社内でAIサービスを作ったら他でも売れるのではないかというパラダイムも全然あると思いますので、マルチテナントSaaS化する際にお使いいただける製品になっています。

アーカイブ動画・発表資料

イベント本編は、アーカイブ動画を公開しています。また、当日の発表資料も掲載しています。あわせてご覧ください。

▼動画・資料はこちら
アーキテクチャConference 2025

※動画の視聴にはFindyへのログインが必要です。