📅 2025年12月15日 ⏱️ 12分で読めます

SaaSセキュリティ認証・審査の種類まとめ｜SOC 2・ISO 27001・プライバシーマーク・ISMAP・CASAの違い

執筆小林編集ファネルAi編集部監修ファネルAi監修チーム最終更新2025年12月15日

SaaSやAIツールを導入するとき、SOC 2、ISO 27001、プライバシーマーク、ISMAP、CASAなどの認証名だけを見ても、実際に何が確認されているかは分かりません。それぞれ確認する対象、監査の深さ、適用範囲、対象データが異なるためです。

結論として、セキュリティ認証は「多いほど良い」ではなく、「自社が預けるデータと利用目的に合っているか」で見るべきです。SOC 2はSaaSの内部統制、ISO 27001は情報セキュリティ管理体制、プライバシーマークは日本の個人情報保護、ISMAPは政府向けクラウド、CASAやGoogle OAuth審査はGoogleユーザーデータを扱うアプリの確認に強みがあります。

営業支援、AIエージェント、CRM、Google Workspace連携ツールでは、顧客情報、メール、ファイル、商談メモ、問い合わせ履歴など、業務上の重要データを外部サービスに預ける場面が増えています。導入前のチェックで「SOC 2取得済み」「ISO 27001認証済み」「プライバシーマーク取得済み」と書かれていても、その認証が自社のリスクに直接効くとは限りません。

この記事では、2025年12月時点でSaaS選定時によく確認される認証・審査を、実務での見方に絞って整理します。Google Workspace連携に特化した審査は Google Workspace連携サービスに必須のOAuth審査とは？でも詳しく解説しています。

SaaSセキュリティ認証を組織管理、個人情報、政府クラウド、Googleデータ、決済・医療などの確認範囲に分けた比較図 — セキュリティ認証は、組織の管理体制、個人情報保護、政府・金融向け、Googleユーザーデータ、決済や医療など、確認する範囲が異なります。

本記事のポイント

SOC 2、ISO 27001、プライバシーマーク、ISMAP、CASAはそれぞれ見ている対象が異なり、1つ取得していれば全領域が安全という意味ではない。
Google WorkspaceやGmail、Driveと連携するSaaSでは、CASAやGoogle OAuth審査がGoogleユーザーデータの扱いに直接関係する信頼材料になる。
導入審査では、ロゴの有無だけでなく、対象サービス、対象期間、監査報告書、適用範囲、データ保存場所、委託先まで確認する。

この記事で扱うテーマ

SaaSのセキュリティ認証は、何を見ているかで分ける

セキュリティ認証や審査は、すべて同じ意味ではありません。ある認証は組織全体の管理体制を見ます。別の認証は、個人情報保護の仕組みを見ます。Google APIやクレジットカード情報、医療情報のように、特定のデータに絞って確認する制度もあります。

導入判断で重要なのは、認証名を並べることではなく、「自社がそのSaaSに何を預けるか」と「その認証がどの範囲を確認しているか」を合わせることです。たとえば、Google DriveのファイルやGmail本文を扱うアプリなら、ISO 27001の有無だけでなく、Google OAuth審査やCASAの対象スコープを確認する必要があります。カード決済を扱うならPCI DSS、医療情報を扱うならHIPAAや国内法制への対応が論点になります。

種類	主に見る対象	SaaS選定での意味
SOC 2	セキュリティ、可用性、機密保持、処理の完全性、プライバシーに関する統制	SaaS事業者の運用統制を確認しやすい
ISO 27001	情報セキュリティマネジメントシステム	組織として情報セキュリティを管理しているかを見る
プライバシーマーク	日本の個人情報保護マネジメントシステム	日本国内の個人情報保護体制を確認しやすい
ISMAP	政府情報システム向けクラウドサービスのセキュリティ	行政・公共領域でのクラウド利用要件に関係する
CASA / Google OAuth審査	Google APIスコープとGoogleユーザーデータの取り扱い	Gmail、Drive、Calendar連携アプリの信頼材料になる

「SOC 2があるからCASAは不要」「ISO 27001があるからプライバシーマークは不要」と単純に置き換えることはできません。認証は代替関係ではなく、対象範囲ごとの補完関係として見るのが現実的です。

主要な認証・審査の種類と違い

SOC 2

SOC 2は、米国公認会計士協会（AICPA）の Trust Services Criteria に基づき、SaaS事業者の統制を評価する枠組みです。セキュリティを中心に、必要に応じて可用性、機密保持、処理の完全性、プライバシーを扱います。Type Iはある時点の設計、Type IIは一定期間の運用状況を対象にするため、導入審査ではType IIレポートの有無と対象期間を見ることが多くなります。

ISO/IEC 27001

ISO/IEC 27001は、情報セキュリティマネジメントシステム、つまりISMSの国際規格です。個別のSaaS機能だけでなく、組織としてリスクを特定し、管理策を運用し、継続的に改善する体制を確認します。認証範囲が会社全体なのか、特定部門や特定サービスなのかで意味が変わるため、認証書の適用範囲を確認する必要があります。

ISO/IEC 27701

ISO/IEC 27701は、プライバシー情報マネジメントの拡張規格です。個人データの管理、委託先との関係、本人対応、処理者・管理者としての責任を整理する文脈で使われます。プライバシー領域を重視するSaaSでは、ISO 27001と合わせて確認されることがあります。

プライバシーマーク

プライバシーマークは、日本国内で個人情報保護マネジメントシステムを運用している事業者に付与される制度です。国内顧客を対象にしたBtoB SaaSでは、個人情報保護の説明材料として使われやすい一方、クラウド基盤の技術的な安全性や海外移転、特定APIスコープの妥当性まで直接確認する制度ではありません。

ISMAP

ISMAPは、日本政府の情報システムで利用されるクラウドサービスを評価・登録する制度です。公共機関、自治体、政府系案件では重要な確認項目になります。一方で、民間企業向けSaaSすべてに必須というわけではありません。行政・公共領域に売るのか、一般企業向けなのかで優先度が変わります。

CASA / Google OAuth審査

CASAは、Google APIでrestricted scopesなどを扱うアプリに関係するセキュリティ評価です。SOC 2やISO 27001が組織全体の統制を見るのに対し、CASAやGoogle OAuth審査は、Googleユーザーデータにどのスコープでアクセスし、どのように保存・共有・削除するかにより近い審査です。Gmail、Google Drive、Google Calendarと連携するサービスでは、非常に直接的な信頼材料になります。

PCI DSS、HIPAA、GDPR、FedRAMP、CSA STAR、NIST、FISC

PCI DSSはカード会員データ、HIPAAは米国の医療情報、GDPRはEUの個人データ、FedRAMPは米国政府向けクラウド、CSA STARはクラウドセキュリティの透明性、NIST CSFやNIST SP 800系は管理策やリスク管理、FISC安全対策基準は日本の金融機関向けシステム安全対策でよく参照されます。これらは業界、地域、データ種別によって重要度が変わります。

導入判断では「ロゴ」ではなく「適用範囲」を確認する

セキュリティページに認証ロゴが並んでいても、それだけで導入判断を終えるのは危険です。認証が親会社だけに適用されている、対象サービスが別、監査期間が古い、レポートが開示されない、サブプロセッサが未整理、といったことがあるためです。

確認項目	見るべき問い	注意点
対象サービス	導入予定のSaaS本体が認証範囲に入っているか	会社名だけで判断しない
対象期間	SOC 2 Type IIや監査報告書の期間は最新か	古いレポートは現在の運用を示さない
対象データ	顧客情報、Googleデータ、決済、医療情報のどれを扱うか	データ種別と認証の対応を見る
保存場所	データ保管国、バックアップ、ログ、サブプロセッサは明示されているか	海外移転や委託先が論点になる
例外条件	顧客側の設定ミスや連携先は対象外になっていないか	共有責任モデルを確認する

とくにAIエージェントやCRM連携では、入力した情報が学習に使われるのか、外部APIへ送られるのか、ログに残るのか、誰が削除できるのかが重要です。AI利用のリスク評価は AIリスクアセスメントの進め方、社内での無断利用対策はシャドーAI対策でも整理しています。

Google Workspace連携SaaSではCASAの意味が大きい

Google Workspace連携SaaSでは、通常のSaaS認証に加えて、Google OAuthスコープの扱いを確認する必要があります。Gmail本文、Driveファイル、Calendar予定などは、企業の日常業務そのものに近いデータです。広いスコープを要求するアプリでは、GoogleのOAuth verificationやCASAが、ユーザーに見える機能と要求権限が一致しているか、データの保存・共有・削除方針が説明できるかを確認する材料になります。

これはSOC 2やISO 27001の価値を下げる話ではありません。SOC 2やISO 27001は組織の管理体制を見るうえで有効です。一方、Google Workspaceと深く連携するサービスでは、「そのプロダクトがGoogleユーザーデータへどうアクセスするのか」を直接見る審査も必要になります。導入企業は、認証を横並びで見るのではなく、自社の利用シナリオに近い審査を重く見るべきです。

たとえば、営業チームがGmailやDriveをCRMと連携する場合は、Google Workspace MarketplaceでCRMを選ぶ手順のような機能比較に加えて、OAuthスコープ、データ保存方針、削除手順、監査ログ、サポート体制を確認します。Google Workspace連携そのものの審査は、CASA審査・費用・スコープ設計の記事も参照してください。

SaaS導入前のセキュリティ確認チェックリスト

認証名を確認したら、次は自社の導入リスクに合わせて質問を具体化します。すべての認証を求めるのではなく、自社が預けるデータと業務影響から優先順位を決めます。

利用ケース	重視しやすい確認	追加で聞くこと
一般的なSaaS導入	SOC 2、ISO 27001	対象サービス、Type II期間、インシデント通知体制
個人情報を多く扱う	プライバシーマーク、ISO 27701、DPA	利用目的、第三者提供、削除・開示対応
Google Workspace連携	Google OAuth審査、CASA	要求スコープ、restricted scopes、保存範囲
公共・政府向け	ISMAP、FedRAMP	対象クラウド、リージョン、運用要件
金融・決済・医療	FISC、PCI DSS、HIPAA	業界要件、監査証跡、アクセス制御

セキュリティ確認は、導入を止めるための手続きではありません。どのデータを預けるか、どの業務に使うか、どこまで社内で制御できるかを先に整理すると、必要な認証と質問が自然に絞れます。

よくある質問（FAQ）

SOC 2とISO 27001はどちらが上ですか？

上下ではなく、確認の仕方が違います。SOC 2はSaaS事業者の統制状況をレポートとして確認しやすく、ISO 27001は情報セキュリティマネジメントシステムの認証として見られます。導入審査では、どちらか一方ではなく、対象範囲と最新性を確認します。

プライバシーマークがあればSaaSのセキュリティは十分ですか？

十分とは限りません。プライバシーマークは個人情報保護の体制を見る制度であり、クラウド基盤、可用性、脆弱性管理、APIスコープ、海外サブプロセッサの全てを直接保証するものではありません。預けるデータに応じて別の確認が必要です。

Google Workspace連携アプリではCASAを必ず確認すべきですか？

Gmail本文やDriveファイルなど、restricted scopesに関係するデータを扱うなら確認すべきです。すべてのGoogle連携でCASAが必要とは限りませんが、Googleユーザーデータに広く触れるアプリでは、OAuth審査やCASAの状況が重要な判断材料になります。

認証ロゴがあれば導入してよいですか？

ロゴだけでは不十分です。対象サービス、認証範囲、監査期間、報告書の種類、対象外条件、サブプロセッサ、データ保存場所を確認します。必要ならNDAのうえでSOC 2レポートやセキュリティ質問票の提出を依頼します。

AIツールではどの認証を重視すべきですか？

一般的にはSOC 2やISO 27001に加えて、入力データの学習利用、ログ保存、外部モデル連携、管理者設定、削除手順を確認します。Google WorkspaceやCRMと連携するAIツールでは、OAuthスコープやCASAの有無も重要です。

参考にした公式情報

SaaSやAIツールの導入審査を整理したい方へ

セキュリティ認証は、事業部、情シス、法務、営業現場で見ている論点がずれやすい領域です。ファネルAiでは、Google Workspace、CRM、AIエージェントを含む業務ツールについて、預けるデータ、必要な権限、導入前の確認項目を整理し、現場で使える運用設計まで具体化できます。

SaaS・AIツールの導入審査について相談する

メディア一覧へ戻る