import ColumnDownloadCTA from '@/components/columns/ColumnDownloadCTA' import ColumnContactCTA from '@/components/columns/ColumnContactCTA'
こんにちは、株式会社TIMEWELLの濱本です。
エンタープライズAIガバナンス連載の第2弾です。前回は経済産業省のAI事業者ガイドラインを軸に「日本の社内ルールをどう設計するか」に踏み込みました。今回はその続編として、グローバルで実際に監査が走り、契約書のチェック項目に書かれてしまう三つの規格、SOC 2 Type II、ISO/IEC 27001:2022、ISO/IEC 42001:2023、そして米国発のNIST AI Risk Management Framework 1.0を取り上げます。
正直なところ、AIの利活用が進むほど、社内の法務やセキュリティ部門から「うちのAIはSOC2に通るのか」と詰められる場面が増えました。聞くたびに私が思うのは、AIを既存の監査基準にそのまま当てはめると必ずどこかで歪むということです。AIは確率的に動き、出力が毎回ぶれ、訓練データが見えにくい。従来の決定論的なシステムを前提に作られた基準では拾いきれない論点が出てきます。
この記事では、四つの規格をAIの目で読み直し、どこをどう統制すべきかを実務目線で整理します。読み終えたとき、自社のAI監査要件を経営層と話せる解像度になっていることが目標です。
ISO/IEC 42001:2023 が登場した意味
2023年12月、ISO（国際標準化機構）とIEC（国際電気標準会議）が共同で発行したISO/IEC 42001:2023は、世界初のAIマネジメントシステム（AIMS：AI Management System）認証規格です。これまでAIガバナンスといえば、企業ごとの自主基準やNIST AI RMFのような任意ガイダンスが中心でした。そこに「第三者認証で対外的に証明できる」ものさしが加わったというのが、この規格の最大の意味です。
構造は他のISOマネジメントシステム規格と似ています。本文の要求事項に加えて、Annex Aに38のコントロールが9カテゴリに分かれて並び、Annex Bにそれぞれの実装ガイダンスが添えられています。9カテゴリの中身は、A.2のAIポリシー、A.3の内部組織、A.4のリソース、A.5の影響評価、A.6のAIシステムライフサイクル、A.7のデータ、A.8のシステム情報、A.9の利用、A.10の第三者関係です。Annex AはISO 27001のAnnex Aと同様、絶対実装の義務リストではなく、Statement of Applicability（適用宣言書、SoA）でリスクに応じて選択する参照集合という位置づけになっています。
認証プロセスは、ISO 17021に従ってStage 1（書面・設計レビュー、1〜2日）とStage 2（実地・運用評価、1〜3週間）の二段階で進みます。発行後は3年間有効で、年次のサーベイランス監査を経て再認証されます。Schellmanなど主要な認証機関の公開情報を見ると、既存でISO 27001を持っている組織なら4〜6ヶ月、ゼロから組み立てる場合は6〜12ヶ月が現実的な目安です。
私がこの規格を読んでいて印象的だったのは、いわゆる「AIの公平性」「説明責任」を抽象的な理念で終わらせず、影響評価、データ来歴、ライフサイクル管理、第三者関係といった監査可能な単位に分解しているところです。AWSやMicrosoftがいち早く取得し、エンタープライズの調達条件に組み込みつつあるのも、この監査可能性を評価しているからだと感じます。日本でも2026年に入ってから、AI受託開発やSaaSのRFP（提案依頼書）で「ISO 42001取得計画を提示せよ」という要求を見るようになりました。
SOC2 Trust Service Criteria のAI評価ポイント
SOC 2は、米国公認会計士協会AICPAが管理するTrust Service Criteria（TSC）に基づく監査報告で、Security、Availability、Processing Integrity、Confidentiality、Privacyの5原則で評価されます。Type Iが一時点の設計評価、Type IIが通常6〜12ヶ月にわたる運用評価で、エンタープライズが取引先に求めるのは事実上Type IIです。
率直に言うと、現時点のTSCにはAI専用の章は存在しません。AICPA Auditing Standards Boardは2025年にSOC 1ガイドを改訂し、Points of Focusに新興技術と新たな脅威の観点を取り込みました。SOC 2側でも記述基準とPoints of Focusのリフレッシュが進み、Bakerやforvis MazarsなどBig 4まわりのコメントを総合すると、2026年の監査現場ではAIガバナンスを既存の5原則の中で再解釈する流れが定着しつつあります。
監査人がAIに対して保証を出す方法には、知っておくべき大原則がひとつあります。「監査人はAI出力そのものに保証を出さない、AIを取り巻く統制に保証を出す」というものです。AIは確率的に振る舞い、同じ入力でも出力がぶれます。従来の決定論的なソフトウェアを前提にした「再現性のあるテスト」ではフィットしないため、Schellmanや個別事務所の解説でも、ハルシネーション率の閾値、信頼度キャリブレーション指標、出力検証アーキテクチャといった新しい統制プリミティブを定義する必要があると指摘されています。
実務では、5原則を次のように読み替えるとAIにフィットします。Securityは訓練データと推論ログのアクセス制御、APIキーとモデル重みの保護に拡張します。Availabilityはモデル提供サービスのSLAだけでなく、推論失敗時のフォールバック設計まで含めます。Processing Integrityは入力検証・出力検証・人間の監督ポイントを設け、ハルシネーションが業務影響を与えない設計にします。Confidentialityでは、社内データがプロンプトとしてベンダー側に送られていないか、ログに機密情報が混入していないかを確認します。Privacyではデータ主体からの同意、削除請求への対応、訓練データへの個人情報混入リスクを点検します。これらを既存のTSCコントロールに紐づけ、レポートのSection 4に追記する企業が増えています。
ISO27001 ANNEX A をAIに当てはめる
ISO/IEC 27001:2022は、ISMSの国際認証規格として依然としてエンタープライズの土台です。2022年版でAnnex Aは大きく整理され、それまでの114コントロール14ドメインから93コントロール4テーマへと再編されました。テーマは組織的（37）、人的（8）、物理的（14）、技術的（34）の四つで、新設された11コントロールにはA.5.7 Threat Intelligence、A.5.23 Cloud Services、A.5.30 ICT Readiness、A.7.4 Physical Security Monitoring、A.8.9 Configuration Management、A.8.10 Information Deletion、A.8.11 Data Masking、A.8.12 Data Leakage Prevention、A.8.16 Monitoring、A.8.23 Web Filtering、A.8.28 Secure Codingが並びます。
AI特化のコントロールはまだ27001:2022に明文化されていません。それでもこの93コントロールは、AIに引き寄せて読むとかなり多くを覆えます。たとえばA.8.10のInformation Deletionは、訓練に使ったデータの削除責任やモデルからの「忘却」要求への対応に直結します。A.8.11のData Maskingは、プロンプトに乗ってしまう個人情報の匿名化に効きます。A.8.16のMonitoringは、推論ログとプロンプトログの収集・分析の規律になります。A.5.23のCloud Servicesは、SaaSのLLMやベクトルDBを使うときの責任分界の明確化に使えます。A.8.25のSecure Developmentは、敵対的サンプルへの耐性テストや赤チーム演習を組み込む形で拡張するのが定石です。
ISMS.onlineやAdvisera、CSAなど主要なISO解説メディアの2026年初の論調も、この方向性で一致しています。「2026年の見立てとしては、ISO 27001を情報セキュリティの土台に置き、その上にISO 42001をAIガバナンスのレイヤーとして積む構成が標準になる」というのが共通見解です。私もこの整理に賛成で、TIMEWELLとして顧客に提案する際もまず27001のギャップ分析から始め、その上で42001のSoAを作るアプローチを取っています。
ちなみに、ISO 27002の次の改訂、もしくはAnnex Aの追補で、AI特化コントロールが追加されるのではないかという観測がGRC Solutionsなど複数の専門家から出ています。ここはもう少し動向を見る必要がありますが、先回りしておきたいなら、Annex Aの既存コントロールを「AIの目」で読み替え、内規に追記しておくのがおすすめです。
組織にAIを導入する5つのフェーズ で書いたとおり、内規を整えるタイミングはAI導入の初期、すなわちフェーズ1〜2が理想です。あとから直すと、すでに動いているシステムに監査要件を足すことになり、コストが跳ね上がります。
ISO 42001 の必須統制：モニタリング、データ、事故対応
Annex Aの38コントロールのなかから、私が「これは外すと監査で確実に詰まる」と感じている領域を三つ挙げます。モニタリング、データ管理、インシデント・事故対応の順で書きます。
モニタリングの軸はA.6（AIシステムライフサイクル）とA.8（AIシステム情報）に集中しています。求められているのは、運用フェーズに入ったAIモデルの性能、バイアス、誤検知率、ハルシネーション率を継続的に観測し、閾値を超えたら是正処置を発動する仕組みです。これは従来のMLOpsダッシュボードの延長で実現できますが、監査では「観測項目を誰がいつ承認したか」「閾値を変更した記録は残っているか」までセットで問われます。観測値そのものより、変更管理と承認の証跡のほうが詰められやすいのが実務の感覚です。
データ管理の軸はA.7（データ）です。AIにとってデータはコードに近い存在で、来歴（データプロベナンス）、品質、ラベリング、同意、削除、再学習の各段階で統制が必要です。とくに生成AIでは、訓練に使ったデータが意図せず出力に染み出す問題があるため、データ分類、機微情報の除外、合成データへの差し替え、記録保持期間の明確化を統制セットとして組むのが現実解になります。NISTのGenerative AI Profile（NIST AI 600-1、2024年7月発行）も、Confabulation（confabulation：もっともらしいが事実でない出力）と情報整合性の論点をかなり丁寧に扱っており、こちらの記述を42001のSoAの根拠資料に引いている例も増えました。
インシデント・事故対応の軸はA.5（影響評価）とA.9（利用）に分散しています。AI特有の事故とは、誤情報による業務判断の誤り、差別的出力、機微データの漏えい、プロンプトインジェクションによる権限逸脱などです。従来のセキュリティインシデント対応プロセス（NIST SP 800-61的なもの）に、「モデル起因の誤動作」と「データ起因の出力品質低下」のクラスを足すイメージで整備するのがおすすめです。私たちの体感では、この事故対応プロセスを書ききれていない企業が一番多く、ISO 42001のStage 2監査で指摘されやすい領域です。
ZEROCKの設計でも、ここは初期から監査可能性を意識しています。プロンプトと出力の全ログ、変更履歴、承認フロー、フォールバック動作、データ削除の証跡を「あとから繋ぎ足す」のではなく、最初からプラットフォームに組み込む設計にしました。監査要件に追われてから機能を足すのは、本当にしんどいからです。
NIST AI Risk Management Framework との整合
NIST AI Risk Management Framework 1.0は、米国国立標準技術研究所NISTが2023年1月26日に公開した自主ガイダンスです。中核はGOVERN、MAP、MEASURE、MANAGEの4機能で、GOVERNが横串、残り三つがリスクの特定・測定・対応の縦串になります。ISO 42001とよく混同されますが、性格はかなり違います。NISTは強制力のない柔軟な枠組み、ISO 42001は認証可能なマネジメントシステム規格。NIST自身もこの違いを認めたうえで、両者をクロスウォーク（対応表）として公開しており、AIRC配下の「NIST_AI_RMF_to_ISO_IEC_42001_Crosswalk.pdf」が一次資料になります。
実務での使い分けは、私はいつも「NISTがWhatとWhy、ISO 42001がHow」と説明します。リスクを洗い出すならNISTのGOVERN/MAP/MEASUREの観点が網羅的で使いやすく、運用と監査に落とすならISO 42001のAnnex Aコントロールに紐づけて文書化するのがスムーズです。2024年7月に追加されたGenerative AI Profile（NIST AI 600-1）は、CBRN（化学・生物・放射性物質・核）情報、confabulation、危険な推奨、データプライバシー、情報整合性、有害バイアスといったGenAI固有の論点を扱い、ISO 42001のSoAの裏付け文書として手堅く使える構成になっています。
EU AI Act、英国のAIアシュアランスロードマップ、シンガポールのAI Verifyなど各国の基準もNIST AI RMFやISO 42001と概念がかなり重なります。いきなり全部追いかけるより、NIST AI RMFをベースに自社のリスクフレームを作り、その上でISO 42001で監査可能化、必要に応じてEU AI ActやSOC 2のレポートに落とし込む順序が、コスト面でも一番現実的だと考えています。
ちなみに、AIアシュアランスを担うのは誰かという議論も2026年に入って活発になりました。Journal of Accountancyの2025年11月号は「CPAs as AI system evaluators（AIシステム評価者としての公認会計士）」という特集を組み、SOC 2監査人がAI評価の実質的な担い手になりつつあると論じています。会計士、セキュリティ専門家、データサイエンティストの三者が交差する仕事になっており、社内のCISO・データ責任者・法務がそれぞれ役割を持つ体制づくりが、これからの認証取得の鍵になります。
まとめ：監査に耐えるAIをどう設計するか
四つの規格を駆け足で見てきました。整理しておくと次のとおりです。
- ISO/IEC 42001:2023は世界初のAIマネジメントシステム認証規格。Annex Aの38コントロール／9カテゴリで、AIガバナンスを監査可能な単位に分解した
- SOC 2 Type IIにはAI専用章はまだないが、5原則をAIに合わせて読み替える運用が2026年の主流。AICPAは2025年にPoints of Focusを更新済み
- ISO/IEC 27001:2022は93コントロール／4テーマの情報セキュリティ基盤。AI特化コントロールはまだ無いが、A.8系コントロールはAI運用にそのまま効く
- NIST AI RMF 1.0はGOVERN／MAP／MEASURE／MANAGEの4機能。ISO 42001とのクロスウォークが公式公開されており、二段構えで運用するのが現実解
実務で動き出すときの優先順位を一言で言えば、「ログと変更管理から始めること」です。AIの出力を完璧に制御することは現時点では誰にもできません。けれど、入出力ログ、訓練データの来歴、モデル変更履歴、人間の監督ポイントを最初から監査可能な形で残すことは、いますぐ着手できます。ここを押さえておけば、SOC 2でもISO 42001でも、求められた瞬間に説明資料を出せる体勢に近づきます。
連載第3弾では、これらの統制をどう実装に落とし込むか、ZEROCKの設計と監査ログ機能を題材にした具体的な手順に踏み込む予定です。社内で「AIガバナンスを誰が担うか」で議論が止まっている方は、CISO・データ責任者・法務・経営の役割分担からまず線を引き直してみてください。そこが決まらないと、規格の話は永遠に空回りします。
参考文献
[^1]: ISO. 「ISO/IEC 42001:2023 — AI management systems」https://www.iso.org/standard/42001 [^2]: NIST. 「NIST AI RMF to ISO/IEC FDIS 42001 Crosswalk」https://airc.nist.gov/docs/NIST_AI_RMF_to_ISO_IEC_42001_Crosswalk.pdf [^3]: AICPA & CIMA. 「SOC 2 — SOC for Service Organizations: Trust Services Criteria」https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2 [^4]: Schellman. 「What to Expect in the ISO 42001 Certification Process」https://www.schellman.com/blog/iso-certifications/iso-42001-certification-processs [^5]: NIST. 「Generative AI Profile (NIST AI 600-1)」https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf [^6]: Baker Tilly. 「Evolving SOC 2 reports for AI controls」https://www.bakertilly.com/insights/ai-controls-for-soc-2-reports [^7]: Microsoft Learn. 「ISO/IEC 42001:2023 Artificial Intelligence Management System Standards」https://learn.microsoft.com/en-us/compliance/regulatory/offering-iso-42001