SaaS事業者向けソリューション

SaaSビジネスにおいて、画面遷移の「遅延」は解約(チャーン)を、「ダウンタイム」はSLA違約とMRRの毀損を、通知メールの「不達」は顧客業務の停止を意味します。
そして、貴社を騙るなりすましメールは、顧客のアカウント乗っ取りと、預かっている顧客データの漏えいに直結します。
Spelldataは、SaaS事業者に求められる可用性・性能・セキュリティを、統計的品質管理と実測データで満たします。
各技術が「何を防ぎ、何を防がないか」を仕様の原典に基づいて明示し、その上で複数の層を組み合わせて全体の防御を構成するのが、私達の提案の特徴です。

顧客からのセキュリティ評価に耐える体制へ

SaaS事業者は、顧客企業からセキュリティチェックシートで評価される側です。
ISMS認証(ISO/IEC 27001)やSOC 2報告書、政府調達を狙うならISMAPと、求められる水準は年々上がっています。
Spelldataは、ご提案の際に、各ソリューションがこれらの評価でどの統制項目(送信ドメイン認証、可用性管理、アクセス制御、攻撃対象領域の管理など)の裏付けになるかを整理してお示しし、貴社のチェックシート回答・監査対応を支援します。
導入支援・技術サポートはすべて国内で内製し、再委託を行わないため、貴社が顧客に説明する委託先管理の観点でも評価が容易です。

6つの防御層

メールの到達性からネットワークの深部まで、6つの層でSaaSインフラを防御します。

第1層:なりすましとメール不達の根絶(DMARC / BIMI)

なりすましメール対策

招待、通知、パスワードリセット、請求。
SaaSにとってトランザクションメールは業務の生命線であり、届かなければ顧客の業務が止まります。
Gmailは2024年2月から、Outlookは2025年5月から、1日5,000通以上の送信者にSPF・DKIM・DMARCの設定を必須化しており、SaaS事業者の多くはこの「大量送信者」に該当します。
MailData (PowerDMARC)により、送信者要件への準拠から、DMARCポリシーの「p=reject(拒否)」への移行までを支援します。
DMARC(RFC 9989、2026年5月に旧RFC 7489を置き換えた最新仕様)は、貴社の正規ドメインおよびそのサブドメインを直接騙るなりすましメールを認証で判別し、受信箱に届く前に排除します
一方、仕様上、類似ドメイン(cousin domain)や表示名の偽装はDMARCの対象外です。
そこでBIMIとVMC(認証マーク証明書)を組み合わせ、GmailやApple Mailなどの対応環境で正規メールにのみブランドロゴを表示させ、利用者が正規の通知メールを視覚的に識別できる手段を提供します。

第2層:TLS証明書「47日ルール」への対応(証明書管理の自動化)

電子証明書

TLS証明書の手動運用は、2029年に破綻します。
CA/Browser Forumの決定(Ballot SC-081)により、証明書の最大有効期間は2026年3月から200日、2027年3月から100日、2029年3月15日以降は47日へと段階的に短縮されます。
ドメイン認証情報の再利用期間も最終的に10日まで短縮されるため、47日時代には証明書1枚あたり年8回前後の更新が必要になります。
顧客ごとのカスタムドメインを抱えるマルチテナントのSaaSでは、証明書は数百枚規模になり、更新漏れの1枚が顧客向けサービスの停止として表面化します。
世界標準のDigiCertにより、ACMEによる発行・更新の自動化と、棚卸し・期限監視を含む証明書ライフサイクル管理を導入し、短縮スケジュールに耐える運用体制を構築します
証明書の透明性(Certificate Transparency)ログの監視と組み合わせることで、貴社ドメインを対象とした証明書の不正発行も検知できます。
BIMIに必要なVMC(認証マーク証明書)の発行にも対応し、第1層のブランド保護と連動します。

第3層:公開サービスのDDoS防御とDNSの保護

DNSとエッジネットワークの防御

マルチテナントのSaaSでは、一度のDDoS攻撃が全顧客のサービス停止に波及し、SLAクレジットの支払いに直結します。
公開資産には、エッジネットワークでの攻撃吸収と、名前解決の保護が必要です。
CloudflareGcoreの大規模エッジネットワークで悪意あるトラフィックを吸収し、攻撃を受けている最中でもサービスを継続させます
DNSSEC(RFC 4033RFC 4035)によりDNS応答に電子署名を付与し、検証を行うリゾルバーを経由した名前解決で、応答の改ざんを検出できるようにします。
DNSSECが提供するのはDNSデータの出所認証と完全性保証であり、DoS対策や通信の秘匿は提供しません。
レジストラ経由のドメイン乗っ取りに対しては、レジストリロックの併用を提案します。

第4層:実ユーザー視点の品質監視(SLAの証明)

モニタリング画面

顧客から「遅い」と言われたとき、それが顧客側の回線起因か、貴社サービス起因かを、データで切り分けられますか。
「データセンターの監視モニターは正常だが、顧客からは繋がらない」という乖離は、ISPやキャリア網の障害で頻繁に起こります。
SpeedDataは、全国7都市(札幌・仙台・新潟・東京・名古屋・大阪・福岡)の計測センターから、実際のユーザーが使う回線(NTT/KDDIの固定回線、4キャリアの5G回線)で24時間365日計測します
データセンター内部からではなく、顧客と同じ経路で観測するため、キャリア網やISPに起因する障害も検知できます。
計測値は平均値ではなくパーセンタイルで管理し、遅延の分布と外れ値を統計的に分析することで、一時的な揺らぎと恒常的な品質劣化を切り分けます。
顧客が気づく前に障害を検知し、問い合わせが殺到する前に対処する「先回り」の運用を実現します。
第三者検証可能な実測データは、SLA達成状況の報告、ステータスページの裏付け、障害時の顧客説明の根拠として活用できます。

第5層:表示速度のSLA保証(Web高速化)

PerfData

ログイン、ダッシュボード、一覧画面。
SaaSの画面遷移の遅延は、日々の利用体験を削り、トライアルからの転換率と継続率に直結します。
「速くなったはず」という感覚ではなく、計測データで保証された速度が必要です。
PerfDataは、サーバの計算処理、ネットワーク処理、フロントエンド処理まで包括し、全体最適化でWebサイトやWebアプリケーションを高速化します。
中核となるのは計算処理の高速化です。
計算量の削減、計算処理の並列化、処理順序の変更によって計算待ち時間そのものを減らすため、設定変更にとどまる一般的な高速化とは到達点が異なります。
表示開始0.5秒以内、表示完了1秒以内を98パーセンタイルで達成し、この品質を契約上のSLAとして保証します
達成状況は第4層の実測データで継続的に検証するため、導入後の品質劣化も見逃しません。

第6層:管理系システムの隠蔽化(攻撃対象領域の最小化)

Tailscaleによる隠蔽化

管理画面、本番データベースへの運用アクセス、CI/CD、社内ツール。
利用者を特定できるこれらのシステムは、そもそもインターネットに公開する必要がありません。
顧客データを預かるSaaS事業者にとって、管理系への不正アクセスは全顧客を巻き込むインシデントになります。
Tailscaleを導入し、外部へのポート開放を不要にします。
認証されたデバイス以外からはサービスに到達できず、ポートスキャンでも発見されないため、攻撃対象領域を大幅に縮小します
CI/CDのシークレット管理も、攻撃対象領域の一部です。
Workload Identity Federationにより、GitHub ActionsなどのCIは短命なOIDCトークンでtailnetに認証でき、GitHub Secretsに長期有効な認証キーを保存する必要がなくなります。
盗まれるシークレットを、そもそも置かない構成にします。
フルリモートの開発体制でも、拠点VPNに縛られずに同じ防御を適用できます。
第3層のエッジ防御と組み合わせることで、「公開資産はエッジで吸収し、非公開資産は隠蔽する」という二層の防御を構成します。

SaaS・IT業界での導入実績

Spelldataは、大手企業を中心に350社以上へサービスを提供してきました。
そのうち、SaaS・IT業界のご契約実績は●社です(●年●月●日時点)。

SaaS事業者に一番ご導入頂いているサービスは、DMARC分析サービスの「MailData」です。
早期にp=rejectを達成し、BIMI・VMCの実装まで到達した支援実績を多数持つことが、弊社の強みです。

メール認証は「推奨」から「送信者要件」へ

Gmailはメール送信者のガイドラインで、2024年2月1日以降、1日5,000件を超える送信者にSPF・DKIM両方の設定とDMARCの設定を必須化しました。
Outlookも2025年5月5日から、1日5,000通以上の送信者に同様の要件の適用を開始しています。
さらに総務省は「フィッシングメール対策の強化に関する要請」(2025年9月)で、電気通信事業者に対してDMARCポリシーに基づく処理(隔離・拒否)の設定を求めており、受信側のメールインフラは認証されないメールの排除へと動いています。
要件を満たさなければ、なりすまされる前に、まず貴社の正規メールが届かなくなります。
なお、送信者要件の最低ラインはp=noneですが、p=noneは「観測」であって「防御」ではありません。
BIMIでブランドロゴを表示するには、DMARCを強制ポリシー(quarantineまたはreject)まで引き上げることが仕様上の要件であり、なりすましメールを受信箱に届けない実効性を持つのはp=rejectです。

DMARC分析は、DNSレコードと受信側から届くレポートの分析で完結します。
貴社システムの内部構成に触れず、既存ベンダーとの契約関係にも影響しないため、単独のサービスとして契約できます。
まずはDMARC分析から、弊社の実力を確認してください。