SOC 2とISO27001は何が違うのか — AIサービスの調達審査でどちらを見るか

AIセキュリティ実務ガイド 編集部

なぜこの2つが並べて出てくるのか

生成AIサービスの導入を検討すると、ベンダーから「SOC 2 Type II を取得済み」「ISO27001認証取得」といった資料が出てきます。どちらもセキュリティに関する第三者の評価ですが、証明している内容が違うため、片方があればもう片方は不要という関係ではありません。

調達審査の現場では「両方あるから安心」「片方しかないから不安」といった判断になりがちです。しかし本来見るべきなのは、その証明が自社の懸念をカバーしているかです。

証明の性質が違う

ISO27001は「情報セキュリティを管理する仕組み(ISMS)を作り、回している」ことの認証です。仕組みの存在を示します。

SOC 2は、ベンダー自身が定義した統制目標に対して、監査人が検証した報告書です。とくに Type II は、一定期間(通常6〜12か月)にわたって統制が機能していたかを検証します。運用の実績を示します。

この違いから、実務上の含意が出てきます。

• ISO27001があっても、個別の統制がどう運用されたかは分からない
• SOC 2があっても、それはベンダーが選んだ統制項目についての評価

調達審査で本当に見るべきは「適用範囲」

認証や報告書の有無より重要なのが、**スコープ(適用範囲)**です。

大企業のISO27001認証が、実際には特定の事業部やデータセンターのみを対象にしている例は珍しくありません。導入しようとしているAIサービスが、その範囲の外にある可能性があります。

確認すべきことは3つです。

1. 認証書・報告書に記載された適用範囲に、対象サービス名が含まれているか
2. 有効期限は切れていないか(ISO27001は3年ごとの更新、SOC 2は報告対象期間がある)
3. SOC 2の場合、Type I か Type II か(Type I はある時点の設計評価のみ。運用実績は含まれない)

3つめは特に見落とされます。Type I は「設計上はできている」という評価で、実際に守られていたかは検証されていません。

どちらもAI固有のリスクは対象外

ここが最も重要な点です。ISO27001もSOC 2も、AI固有のリスクを評価する枠組みではありません。

どちらも情報セキュリティ一般(アクセス管理、暗号化、インシデント対応など)を対象としており、次のような論点は含まれていません。

• 入力したデータがモデルの学習に使われるか
• モデルの提供元が別会社の場合、その会社の統制はどうなっているか
• 出力の誤り(ハルシネーション)による業務影響をどう扱うか
• モデルの更新によって挙動が変わったとき、誰がどう検知するか

したがって、認証があることを確認したうえで、AI固有の論点は契約書と個別のヒアリングで詰める必要があります。

AIのマネジメントシステムを対象にした規格としては ISO/IEC 42001 があり、2023年に発行されています。ただし取得しているベンダーはまだ限られるため、現時点では「あれば加点」程度の位置づけになります。

稟議に書くときの整理

社内説明では、次の順序で書くと論点がずれにくくなります。

1. ベンダーの第三者評価: 何を取得しているか、適用範囲に対象サービスが含まれるか
2. AI固有の確認事項: 学習利用の有無、データの保存期間、再委託先、リージョン
3. 自社側の統制: 誰が使えるか、何を入力してよいか、記録をどう残すか

1だけで判断すると、2と3が抜け落ちます。逆に1を軽視すると、ベンダーの基礎的な管理体制を確認しないまま契約することになります。

2と3の具体的な確認項目は、生成AI導入セキュリティチェックリストにまとめています。

まとめ

• ISO27001は仕組みの認証、SOC 2は運用実績の監査報告書。性質が違うので代替関係にはない
• 有無より適用範囲を見る。対象サービスが範囲外なら意味がない
• SOC 2は Type II かどうかを確認する。Type I は設計評価のみ
• どちらもAI固有のリスクは対象外。学習利用・再委託・リージョンは契約で個別に確認する