2σ Guide

ソフトウェア監査
ライセンス監査を受けたときの対応

監査通知を受けた企業が、契約、著作権、個人情報、営業秘密、IT資産管理、会計、ガバナンスを横断して、初動から和解・再発防止まで整理するための実務ガイドです。

72時間 初動で保全・範囲・窓口を固める
3段階 防御・交渉・統制改善で捉える
10項目 経営報告とSAM整備の要点
本ページは株式会社Dプロフェッションズ(医師/医療機関/弁護士/弁護士法人ではありません)が運営しています。
一般的な情報提供を目的としており医療上の助言や法律相談等を行うものではありません。
広告(PR)を掲載しています。広告は編集内容や推奨を意味しません。
Video

ソフトウェア監査 ライセンス監査を受けたときの対応

監査通知はIT棚卸しではなく、契約・知財・情報管理・経営判断が交差する危機対応です。

動画を読み込み中…
2σ GUIDE ・ VIDEO
ソフトウェア監査 ライセンス監査を受けたときの対応
監査通知はIT棚卸しではなく、契約・知財・情報管理・経営判断が交差する危機対応です。
動画の文字起こし(全文テキスト)

2σ GUIDE ・ VIDEO

  • ソフトウェア監査 ライセンス監査を受けたときの対応
  • 監査通知はIT棚卸しではなく、契約・知財・情報管理・経営判断が交差する危機対応です。

POINT 1

  • ソフトウェア監査を受けたときの全体像
  • 監査通知はIT棚卸しではなく、契約・知財・情報管理・経営判断が交差する危機対応です。
  • 無視しない、慌てて認めない、慌てて削除しない、慌ててデータを渡さない
  • 統制改善
  • この手続では、ソフトウェアが有体物の売買ではなく、一定条件の下で利用を許諾される無形資産である点が出発点になります。

POINT 2

  • ソフトウェア監査の定義と基本用語
  • 契約が根拠になる
  • 使用許諾契約、クラウド利用規約、発注書、保守契約、再販契約、M&A承継契約などを精査しなければ範囲を確定できません。
  • 著作権・差止めが絡む
  • 未許諾利用は契約違反に加え、複製権侵害、差止請求、損害賠償、刑事リスクに発展する可能性があります。

POINT 3

  • ソフトウェア監査通知を受けた直後の72時間対応
  • 1. 監査通知を受領:受領日時、送信元、回答期限を記録します。
  • 2. 正式監査かを確認:契約条項、公式監査レター、監査人の権限を照合します。
  • 3. データ提供を保留:根拠契約、範囲、取得データ、守秘義務の提示を求めます。
  • 4. 限定的に協議:権利義務を留保し、必要な範囲でスケジュールと方法を調整します。

POINT 4

  • ソフトウェア監査権条項を読む契約レビュー
  • 全端末へのツール展開
  • 取得データの一覧を開示しないまま外部送信する要求は、事前レビューと限定実行が必要です。
  • 従業員情報の一括提出
  • 氏名、メール、部署、役職、ログイン履歴をそのまま出す前に、匿名化や集計値提出を検討します。

POINT 5

  • ソフトウェア監査で問題になる法的リスク
  • 契約違反
  • 不足ライセンス、過年度利用料、保守料、監査費用、契約解除、利用停止、将来取引条件の悪化が問題になります。
  • 著作権侵害
  • 複製権侵害、差止請求、損害賠償、廃棄・削除、刑事罰が争点になり得ます。

POINT 6

  • ソフトウェア監査に備えるELP作成と社内調査
  • 企業側の実効的ライセンス状況を自ら作ることが、防御と交渉の基準になります。
  • ベンダー監査で最も重要な成果物は、企業側が自ら作成するELPです。
  • これは、保有ライセンスと実際の利用状況を照合し、過不足、解釈上の争点、証拠不足、是正済み事項を整理した表です。
  • ベンダー結果を受け身で待つのではなく、自社でELPを作ることで、過大算定、重複算定、対象外算定を検出しやすくなります。

POINT 7

  • ソフトウェア監査でベンダー別に起こりやすい論点
  • 製品の課金単位と技術構成により、監査で見られるポイントは大きく変わります。
  • ユーザー・デバイス・サーバーCAL
  • Database・Java・オプション
  • Creative CloudとBusiness User

POINT 8

  • ソフトウェア監査でベンダー・監査人と交渉する実務
  • 1. 通知受領を認める:受領確認と正式窓口を伝えます。
  • 2. 権利義務を留保する:不足、違反、侵害、損害額を認めない形で回答します。
  • 3. 根拠と範囲を求める:契約、対象法人、対象製品、対象期間、取得データ、監査人の守秘義務を確認します。
  • 4. 技術・法務レビュー:提供元、バージョン、ハッシュ値、取得項目、送信先、保存期間、業務影響を確認します。
  • 5. 提出資料を限定:必要最小限の集計値、匿名化、サンプル確認、事前レビュー権を検討します。

まとめ

  • ソフトウェア監査 ライセンス監査を受けたときの対応
  • ソフトウェア監査を受けたときの全体像:監査通知はIT棚卸しではなく、契約・知財・情報管理・経営判断が交差する危機対応です。
  • ソフトウェア監査の定義と基本用語:正式監査、任意レビュー、SAM支援では、企業側の義務と交渉余地が変わります。
  • ソフトウェア監査通知を受けた直後の72時間対応:初動の混乱を避け、証拠と交渉余地を残すことが損失拡大を防ぎます。
  • 本動画は一般的な情報提供であり、法律上の助言ではありません。記載の数値・金額・期間は目安です。個別事情で結論は変わります。
Overview

ソフトウェア監査を受けたときの全体像

監査通知はIT棚卸しではなく、契約・知財・情報管理・経営判断が交差する危機対応です。

ソフトウェア監査、またはライセンス監査とは、ソフトウェアベンダー、権利者団体、販売代理店、第三者監査人などが、企業のソフトウェア利用状況が契約、使用許諾条件、著作権法上の権利に適合しているかを確認する手続です。対象は端末に入ったアプリだけでなく、SaaS、クラウド、ミドルウェア、開発ツール、データベース、仮想化環境、サーバーOS、CAD、ERP、BI、セキュリティ製品などに広がります。

この手続では、ソフトウェアが有体物の売買ではなく、一定条件の下で利用を許諾される無形資産である点が出発点になります。日本法上もプログラムの著作物は保護対象であり、複製、インストール、配布、利用形態によっては契約違反や著作権侵害の問題が生じ得ます。経済産業省のソフトウェア管理ガイドラインも、管理責任者、管理規則、監査、教育、管理台帳といった基本事項を示しています。

次の重要ポイントは、ソフトウェア監査対応をどの順番で見るべきかを表しています。監査通知直後に何を止め、何を確認し、何を後の交渉に残すかを理解することが重要であり、ここから「初動で防御線を引き、事実と契約で交渉し、最後に統制を改善する」という読み取りができます。

無視しない、慌てて認めない、慌てて削除しない、慌ててデータを渡さない

監査通知直後は、真正性、契約上の監査条項、対象範囲、証拠保全、窓口一本化、秘密保持、個人情報、営業秘密、利用権と利用実態の照合を先に整えます。

次の一覧は、監査対応を3つの局面に整理したものです。各局面の目的が異なるため、読者は「いま自社がどの局面にいるか」と「その局面で先に決める事項は何か」を読み取ると、対応の優先順位を誤りにくくなります。

Stage 01

防御

通知の真正性、契約上の根拠、対象法人・製品・期間、監査人の権限、証拠保全、データ提供の制限を確認します。

Stage 02

交渉

ELPを自社で作成し、ベンダー算定、価格、保守料、対象外項目、旧契約の利用権、和解条項を検証します。

Stage 03

統制改善

監査後は、SAM、購買統制、ID管理、教育、内部監査、M&A時の確認、契約更新時の監査条項交渉へ移します。

注意このページは一般的な情報提供です。実際の義務や対応方針は、監査通知、契約条項、利用実態、対象国、ベンダー、グループ会社の範囲で変わる可能性があります。
Section 01

ソフトウェア監査の定義と基本用語

正式監査、任意レビュー、SAM支援では、企業側の義務と交渉余地が変わります。

ソフトウェア監査は、契約上許諾された利用範囲と実際の利用実態を照合する手続です。実務では、ライセンスレビュー、コンプライアンス検証、Software License Review、License Compliance Verification、SAMレビューなど複数の呼称が使われます。ただし、名称だけでは法的性質は決まりません。

正式な監査権に基づく通知なのか、営業部門やパートナーによる自主棚卸しの依頼なのかで、回答期限、提供すべきデータ、監査ツールの扱い、交渉上の立場は変わります。Microsoft、Oracle、Adobe、Autodeskなどの主要ベンダーも、各社の利用規約や公式情報で監査・検証の仕組みを説明しています。

次の用語表は、監査通知を読んだ直後に混同しやすい概念を整理しています。用語の意味を取り違えると、購入済みの権利、実際の使用量、監査人が求めるデータの範囲を誤るため、各語が何を指し、どの判断に効くかを確認してください。

用語実務上の意味監査対応での重要性
ソフトウェアライセンス権利者が一定条件の下でソフトウェア利用を許諾する契約上の権利購入したから自由に使えるという誤解を防ぐ基礎概念です。
使用許諾契約 / EULA利用者が従うべき使用条件台数、ユーザー数、地域、法人範囲、仮想化、バックアップ条件を確認します。
エンタイトルメント契約、発注書、請求書、証書、管理ポータル上の利用権の総称実利用との照合に不可欠です。
デプロイメント実際のインストール、配備、設定、割当、稼働状態インストール済み、未使用、削除済み、休眠端末を区別します。
Usage起動、ログイン、CPU利用、機能利用、API利用、アクセス権限などSaaS、クラウド、従量課金、機能別ライセンスで重要です。
ELPEffective License Position。保有権利と利用実態を照合した実効的ライセンス状況ベンダー算定を検証する企業側の基準表になります。
SAMSoftware Asset Management。ソフトウェア資産管理予防、棚卸し、内部統制、コスト最適化の中核です。
True-up不足分を補正購入すること解決方法の一つですが、範囲、価格、免責条項の確認が必要です。
Shelfware購入済みだが使われていないライセンス不足分と当然に相殺できるとは限らず、交渉・最適化の材料になります。
Audit clause監査権条項頻度、通知期間、監査人、費用負担、データ提供範囲を決めます。
Legal hold関連証拠の保存指示不適切な削除、改ざん、ログ消失を防ぎます。

次の一覧は、ソフトウェア監査が情報システム部門だけで完結しない理由をまとめたものです。契約、知財、情報管理、会計が同時に動くため、読者は自社でどの専門部門を最初から巻き込むべきかを読み取ることができます。

契約が根拠になる

使用許諾契約、クラウド利用規約、発注書、保守契約、再販契約、M&A承継契約などを精査しなければ範囲を確定できません。

著作権・差止めが絡む

未許諾利用は契約違反に加え、複製権侵害、差止請求、損害賠償、刑事リスクに発展する可能性があります。

機微情報を外部に出す

端末名、ユーザーID、ログ、クラウド設定、ネットワーク情報には個人情報、営業秘密、セキュリティ情報が含まれ得ます。

会計・経営判断に波及する

追加購入費、過年度利用料、保守料、和解金、引当、監査役・監査法人対応が必要になることがあります。

Section 02

ソフトウェア監査通知を受けた直後の72時間対応

初動の混乱を避け、証拠と交渉余地を残すことが損失拡大を防ぎます。

監査通知を受けた担当者が、法務に相談せず監査ツールを実行する、営業担当者に利用状況を口頭で説明する、古いインストールを削除する、未整理の台帳を提出する、といった行動は、後の交渉、証拠評価、個人情報保護、秘密保持に悪影響を及ぼします。

初動の原則は、無視しない、即答しない、認めない、削除しない、渡さない、窓口を一本化することです。契約上の期限がある場合の放置は不利になり得ますが、対象範囲や根拠契約が未確認のまま協力義務、不足、違反、侵害、損害額を認めることも避ける必要があります。

次の時系列は、通知受領後72時間に優先して行う確認を表しています。この順番が重要なのは、真正性確認、証拠保全、データ提供制限を先に整えないと、対象外データの提出や証跡消失につながるためです。上から順に、外部へ回答する前に社内で固める事項を読み取ってください。

0から12時間

通知の真正性と期限を確認

送信元、署名者、部署、契約番号、対象法人、対象製品、回答期限、監査人の所属、監査ツールの名称を確認します。

12から24時間

窓口を一本化し、証拠保存を指示

ベンダー、代理店、第三者監査人への個別回答を止め、契約書、注文書、台帳、ログ、端末、クラウド設定の削除・廃棄を一時停止します。

24から48時間

法務主導の対応体制を設置

IT、SAM、購買、経理、個人情報保護、情報セキュリティ、内部監査、必要に応じて外部弁護士やフォレンジック専門家を加えます。

48から72時間

範囲確認と初回返信方針を決める

監査の根拠条項、対象契約、対象製品、対象期間、取得予定データ、NDA、DPA、スケジュール調整の要否を整理します。

次の判断の流れは、監査ツール実行やデータ提出の前に確認すべき分岐を示しています。分岐ごとの意味を押さえることで、協力姿勢を保ちながら、個人情報、営業秘密、セキュリティ情報を過度に渡さない判断がしやすくなります。

初動判断の流れ

監査通知を受領

受領日時、送信元、回答期限を記録します。

正式監査かを確認

契約条項、公式監査レター、監査人の権限を照合します。

未確認
データ提供を保留

根拠契約、範囲、取得データ、守秘義務の提示を求めます。

確認済み
限定的に協議

権利義務を留保し、必要な範囲でスケジュールと方法を調整します。

次の役割表は、監査対応に関与する部門と責任の分担を整理したものです。どの情報がどの部門にあるかを可視化することで、IT部門だけ、または法務部門だけで抱え込むリスクを避け、必要な意思決定者を早めに巻き込めます。

役割主な責任
エグゼクティブスポンサー重要判断、予算承認、ベンダー上層部交渉、取締役会・監査役対応
法務責任者 / 企業内弁護士監査権条項の解釈、交渉方針、外部弁護士管理、文書化
外部弁護士契約、著作権、紛争、和解条項、訴訟リスクに関する助言
IT / 情報システムインベントリ取得、構成把握、ログ確認、削除・是正計画
SAM / ITAM担当エンタイトルメント管理、ELP作成、ライセンスメトリック解釈
購買 / 調達契約、発注書、請求書、代理店情報、更新履歴の収集
経理 / 財務予算、引当、費用処理、決裁、税務影響の確認
内部監査 / 内部統制統制不備の評価、再発防止、証跡確認
個人情報保護 / プライバシー個人データ提供、越境移転、委託先管理、DPA確認
情報セキュリティ / CISO監査ツール審査、アクセス権、外部送信、脆弱性リスク確認
デジタルフォレンジック証拠保全、ログ保全、改ざん防止、取得記録の管理
広報 / IR大規模案件、訴訟、上場会社の場合の対外説明管理

証拠保全では、契約書、注文書、請求書、ライセンス証書、メール、ベンダーポータル画面、台帳、インベントリ、端末情報、仮想環境設定、クラウドサブスクリプション設定、ID管理ログ、利用ログ、削除ログ、チケット、資産管理システム、EDRログなどを対象にします。NIST SP 800-86が示すような識別、記録、取得、完全性保持、検査、分析、報告の考え方は、訴訟や損害賠償請求に発展する場合にも役立ちます。

重要違法状態の放置は避けるべきですが、証跡を消すことも避ける必要があります。まず保全し、その後、法務・IT・SAM担当の承認に基づき、隔離、利用停止、削除、購入、再インストール、アクセス制限などを段階的に検討します。
Section 03

ソフトウェア監査権条項を読む契約レビュー

監査に協力する義務と、無制限に情報を渡す義務は同じではありません。

正式なソフトウェア監査の多くは、契約上の監査権条項に基づきます。企業側は、ベンダーが求める監査が契約で認められた範囲を超えていないかを確認する必要があります。監査権条項を精査せずにデータを提出すると、対象外法人、対象外製品、対象外期間、過度な個人情報、営業秘密まで提供してしまう危険があります。

次の表は、監査権条項で確認する軸を整理したものです。契約レビューでは、左列の観点ごとに右列の確認事項を埋めることで、どこまで応じる必要があるか、どこを交渉できるかを読み取れます。

観点確認事項
契約主体契約当事者は親会社か子会社か。海外法人、買収会社、関連会社は含まれるか。
監査対象製品、サービス、サブスクリプション、クラウド、旧バージョン、保守契約は含まれるか。
対象期間何年分の利用状況を確認できるか。過去監査済み期間は再監査可能か。
通知期間何日前通知が必要か。緊急監査や抜き打ちは認められるか。
頻度年1回までか、合理的期間に1回か、制限がないか。
監査人ベンダー従業員か、独立第三者か。守秘義務・利益相反はあるか。
方法書面レビュー、自己申告、オンサイト、リモート、監査ツール実行のいずれか。
データ範囲端末情報、ユーザー情報、ログ、ネットワーク情報、ソースコード、個人情報を含むか。
費用負担原則ベンダー負担か。不足率が一定以上なら顧客負担か。
不足時の効果追加購入、バックメンテナンス、監査費用、違約金、解除、損害賠償の規定があるか。
準拠法・紛争解決日本法か外国法か。裁判か仲裁か。言語は何か。
秘密保持監査データの利用目的、保持期間、再委託、返却・削除が定められているか。

契約上、監査に合理的に協力する義務があるとしても、ベンダーが求めるあらゆる情報を無条件に提出する義務を意味するとは限りません。監査目的に必要かつ相当な範囲に限定するよう求めることが重要です。

次の一覧は、特に慎重な検討が必要な要求をまとめたものです。これらは情報漏えい、営業秘密の流出、対象外監査、価格交渉への流用につながりやすいため、読者は該当する要求が出ていないかを確認してください。

全端末へのツール展開

取得データの一覧を開示しないまま外部送信する要求は、事前レビューと限定実行が必要です。

従業員情報の一括提出

氏名、メール、部署、役職、ログイン履歴をそのまま出す前に、匿名化や集計値提出を検討します。

ソースコードや顧客情報

監査目的を超える情報は、営業秘密、顧客契約、セキュリティ上の制約を確認します。

グループ全社の一括対象化

契約上対象外の海外子会社、買収会社、委託先まで取り込まれないよう対象法人を限定します。

対象外製品の調査

契約で監査対象に含まれない製品・サービスまで調査が拡大していないかを確認します。

営業利用の懸念

監査結果を販売提案、価格交渉、別製品の営業活動に使わない条件を求めます。

交渉軸目的外利用禁止、データ最小化、匿名化・仮名化、集計値提出、サンプル確認、監査人限定、再委託制限、監査終了後の削除証明を検討します。
Section 05

ソフトウェア監査に備えるELP作成と社内調査

企業側の実効的ライセンス状況を自ら作ることが、防御と交渉の基準になります。

ベンダー監査で最も重要な成果物は、企業側が自ら作成するELPです。これは、保有ライセンスと実際の利用状況を照合し、過不足、解釈上の争点、証拠不足、是正済み事項を整理した表です。ベンダー結果を受け身で待つのではなく、自社でELPを作ることで、過大算定、重複算定、対象外算定を検出しやすくなります。

次の一覧は、ELP作成を4つの作業に分けたものです。どの資料を集め、どの利用実態を照合し、どの争点を交渉材料にするかが重要なので、読者は自社に欠けている作業を読み取ってください。

1

エンタイトルメント調査

マスター契約、EULA、注文書、請求書、ライセンス証書、契約番号、ベンダーポータル、保守契約、アップグレード権、ダウングレード権を集めます。

権利情報
2

利用実態調査

端末、サーバー、仮想化基盤、クラウド、SaaS、コンテナ、VDI、リモートデスクトップ、開発・検証・DR環境、退職者PC、休眠VMを確認します。

利用情報
3

データ正規化

製品名の表記揺れ、旧社名、エディション違い、バンドル製品、試用版、ビューア、ランタイム、プラグイン、更新プログラムを分類します。

誤検出対策
4

照合と争点整理

インストール済みだが未使用、旧バージョン利用権、検証環境、バックアップ、関連会社利用権、海外購入、M&A後の主体ずれを整理します。

交渉資料

次の表は、利用実態調査で集めるデータを対象別に整理したものです。監査は端末だけでなく、サーバー、ID、SaaS、クラウド、ネットワーク、開発環境まで広がるため、自社の取得漏れを見つけるために使います。

データ
端末インベントリPC名、資産番号、OS、インストール済みソフトウェア、最終起動日
サーバー情報物理サーバー、仮想マシン、クラスタ、CPU、コア、メモリ、ホスト構成
ID・ユーザー情報割当ユーザー、退職者、共有ID、サービスアカウント、権限グループ
SaaS利用状況アクティブユーザー、最終ログイン、機能利用、API利用、ゲストユーザー
クラウド利用サブスクリプション、リージョン、インスタンス、Bring Your Own License設定
ネットワーク・ログライセンスサーバー接続、同時利用数、チェックアウト履歴
開発・検証環境CI/CD、ビルドサーバー、テスト環境、ステージング環境
バックアップ・DRコールドスタンバイ、ホットスタンバイ、複製、スナップショット

次の表は、照合時に典型的に争点になる項目をまとめたものです。ベンダーの検出結果と自社の契約・利用権の間に差が出やすいため、読者は各項目が不足額の増減にどう効くかを確認してください。

争点確認する内容
複数バージョン同一端末に複数バージョンが存在するが、同時利用されていない可能性を確認します。
退職者・異動者SaaSアカウントや端末割当が残っていないかを確認します。
未使用インストールインストール済みでも実行ログがないものを区別します。
旧バージョン権利旧バージョン利用権、ダウングレード権、スイート製品の利用権を確認します。
特例環境テスト、災害対策、バックアップ環境の特例を確認します。
仮想化VM、ホスト、クラスタ全体のどれがライセンス対象かを確認します。
関連会社・海外関連会社利用権、海外購入ライセンス、日本法人利用の可否を確認します。
M&A後のずれ契約主体と利用主体の不一致、承継資料の有無を確認します。
Section 06

ソフトウェア監査でベンダー別に起こりやすい論点

製品の課金単位と技術構成により、監査で見られるポイントは大きく変わります。

同じソフトウェア監査でも、Microsoft、Oracle、Adobe、Autodesk、SaaS、OSSでは、調査すべき利用実態が異なります。ユーザー単位、デバイス単位、CPU・コア単位、オプション機能、管理パック、外部委託先利用、クラウド移行、共有アカウント、SBOMなど、製品ごとの監査論点を分けて考える必要があります。

次の比較一覧は、ベンダー・製品類型ごとの典型論点を整理しています。どの製品で何が過大算定や不足指摘につながりやすいかを見分けることで、調査の深掘り先を読み取れます。

Microsoft

ユーザー・デバイス・サーバーCAL

Microsoft 365、Office、Windows Server、SQL Server、CAL、Azure Hybrid Benefit、RDS、VDI、Power Platform、Dynamicsで、退職者アカウント、共有ID、仮想化、クラウド移行時の二重利用が論点になります。

Oracle

Database・Java・オプション

Processor、Named User Plus、管理パック、オプション有効化、CPU・コア計算、仮想化基盤の範囲、関連会社利用、M&A後の契約主体が争点になりやすいです。

Adobe

Creative CloudとBusiness User

Teams/Enterprise、Acrobat、Document Cloud、外部委託先、共有端末、旧永続版、部署異動・退職者アカウント、個人版の業務利用を確認します。

Autodesk / CAD

設計系ソフトと旧バージョン

ネットワークライセンス、単一ユーザーサブスクリプション、設計外注先、プロジェクト終了後の残存インストール、ビューアと編集版の区別が重要です。

SaaS / Cloud

ID・ログ・外部共有

割当ユーザー、最終ログイン、API、ストレージ、ゲストユーザー、外部共有、ロボットアカウント、部門ごとのシャドーITが問題になります。

OSS

SBOMとコピーレフト

M&A、IPO、顧客監査、セキュリティ監査、輸出管理、OSSライセンス違反通知、ソースコード開示要求で問題化しやすい領域です。

SaaSでは、割り当てられているが使っていないアカウントでも課金対象またはライセンス消費対象になることが多く、共有アカウントや外部委託先の利用が禁止されている場合もあります。OSSでは、商用ベンダー監査とは異なり、顧客監査やM&Aの表明保証、製品出荷、知財保証に影響する可能性があります。

Section 07

ソフトウェア監査でベンダー・監査人と交渉する実務

初回返信、範囲限定、監査ツール、情報共有ルールを分けて設計します。

最初の返信は後の交渉の基礎になります。丁寧に協力姿勢を示しつつ、法的権利・義務の認否を留保し、範囲確認を求めます。避けるべきなのは、不足分の購入、全面委任、監査ツール即時実行、グループ全社の対象化などを、事実確認前に受け入れる表現です。

次の判断の流れは、初回返信から監査ツール実行可否までの検討順を表しています。重要なのは、事実確認、法的責任、価格交渉を混同しないことです。上から順に、外部へ出す前に社内承認を要する事項を読み取ってください。

監査人対応の判断順序

通知受領を認める

受領確認と正式窓口を伝えます。

権利義務を留保する

不足、違反、侵害、損害額を認めない形で回答します。

根拠と範囲を求める

契約、対象法人、対象製品、対象期間、取得データ、監査人の守秘義務を確認します。

ツール要求あり
技術・法務レビュー

提供元、バージョン、ハッシュ値、取得項目、送信先、保存期間、業務影響を確認します。

書面調査中心
提出資料を限定

必要最小限の集計値、匿名化、サンプル確認、事前レビュー権を検討します。

監査範囲を限定する軸は複数あります。次の表は、範囲が曖昧なまま調査を始めると調査負荷と請求額が膨らむため、どの軸で対象を絞るべきかを読み取るための一覧です。

限定軸確認する範囲
法人契約当事者、国内子会社、海外子会社、買収会社、JV、委託先
地域日本、APAC、EMEA、米国、クラウドリージョン
期間現在時点、過去1年、過去契約期間、監査済み期間の除外
製品特定製品、関連コンポーネント、旧バージョン、バンドル製品
環境本番、開発、検証、DR、バックアップ、教育、評価、研究
データインストール、利用ログ、ユーザー情報、サーバー情報、契約情報
方法自己申告、サンプル確認、監査ツール、第三者レビュー、オンサイト

次の表は、監査ツール実行前の確認事項を整理しています。ツールは強力な証拠にもなり、重大な情報漏えいリスクにもなるため、どの項目が未確認なら実行を保留するべきかを読み取ってください。

確認事項具体例
提供元・バージョン監査人が指定する正規ツールか、ハッシュ値や実行権限が確認できるか。
取得データ一覧ソースコード、顧客情報、秘密情報、個人情報が含まれないか。
送信先・暗号化外部通信、プロキシ設定、保存場所、保存期間、暗号化方式を確認します。
検証環境限定されたサンプル環境で取得結果と業務影響を確認します。
セキュリティ影響システム負荷、EDRやセキュリティツールとの競合、脆弱性リスクを確認します。
事前レビュー権取得結果をベンダー送信前に企業側が確認できるか。
終了後削除監査終了後の返却、削除、削除証明を求められるか。

情報共有では、口頭説明を避け、原則として文書で回答します。事実、仮定、法的見解、交渉提案を分け、不明点は不明と記載し、監査人からの指摘には根拠資料と計算式を求めます。営業担当者と監査担当者の役割を分けるよう求めることも重要です。

Section 08

ソフトウェア監査の不足ライセンス算定を検証する

監査結果の表は客観的に見えても、前提条件で結論が大きく変わります。

ベンダー算定は、製品名の解釈、対象端末、対象ユーザー、対象期間、仮想化環境、旧契約の利用権、移行権、過去購入履歴、割引、保守料、税金、為替、代理店取引、地域制限の解釈によって変わります。したがって、結果をそのまま受け入れるのではなく、算定根拠と計算式を確認します。

次の表は、不足ライセンス算定で検証すべき典型項目を整理したものです。左列の項目は請求額を押し上げやすい前提であり、右列の確認を通じて重複、対象外、旧権利、価格条件を読み取ることが重要です。

検証項目確認する内容
インストール数と利用数インストール済みだが未使用、休眠端末、削除済み端末を区別します。
端末数とユーザー数同じ利用を二重計上していないかを確認します。
対象外資産退職者、廃棄端末、休眠VM、評価版、無料コンポーネント、ビューアを除外できるか確認します。
バンドル・スイートバンドル製品の一部が別製品として重複算定されていないかを確認します。
旧権利旧バージョン利用権、ダウングレード権、アップグレード権、移行権を反映します。
関連会社利用権契約上のAffiliate、Authorized User、Territoryの定義を確認します。
特例環境開発、検証、バックアップ、DR環境の特例があるかを確認します。
契約時点最新契約ではなく、対象期間に適用される契約のメトリックを使っているか確認します。
価格条件現在価格ではなく、契約上の価格、割引、通貨、税金、保守料を確認します。

古いライセンスでは、請求書や証書が見つからないことがあります。次の一覧は、証拠不足を補う代替資料を示しています。提出する資料にも営業秘密や個人情報が含まれる場合があるため、必要最小限の範囲でどの資料が立証に使えるかを読み取ってください。

Purchase

購入履歴

代理店・リセラーからの購入履歴再発行、会計システムの固定資産・費用処理履歴、発注申請、検収書を確認します。

Portal

ベンダー情報

ベンダーポータルの契約履歴、保守更新請求書、ライセンスキー、契約更新時の数量表を確認します。

Evidence

社内証跡

メール、チケット、プロジェクト資料、過去監査時の確認書、ライセンスサーバー履歴を確認します。

不足が認められる場合でも、将来利用するための正規ライセンス購入と、過去の未許諾利用に対する和解金・損害賠償・保守料は法的性質が異なります。税務、会計、契約、稟議上も区別が必要になる場合があるため、支払名目、会計処理、契約効果、秘密保持、違反認定の扱いを分けて確認します。

Section 09

ソフトウェア監査の和解・是正合意で検討する条項

単に見積書に署名するだけでは、将来請求やデータ利用リスクが残ります。

監査が終了し、不足分の購入や和解を行う場合、合意書またはクロージャーレターで対象範囲、追加請求の遮断、不認容、監査データの扱い、将来監査、再発防止を検討します。購入の事実が、著作権侵害、契約違反、故意、過失、損害額の承認を意味しないように整理することもあります。

次の一覧は、和解・是正合意で残しやすい論点を表しています。各項目は後日の追加請求、同一期間の再監査、データの営業利用、過度な継続監督を防ぐために重要であり、読者は合意文書にどこまで反映されているかを読み取ってください。

対象範囲の特定

対象法人、製品、バージョン、地域、期間を明記し、対象外の法人・製品・期間の扱いを確認します。

追加請求の遮断

対象範囲について、追加請求、損害賠償、監査費用、バックメンテナンス、解除を行わない旨を検討します。

不認容条項

支払いまたは購入が、違反、侵害、故意、過失、損害額の承認を意味しないことを明記します。

監査データの扱い

利用目的を監査・和解履行に限定し、営業利用、別製品監査、第三者提供を制限します。

将来監査の制限

一定期間の再監査猶予、同一対象期間の再監査禁止、合理的通知、営業時間内、業務妨害回避を検討します。

再発防止義務

社内ポリシー、SAMツール、教育、定期棚卸し、退職者アカウント管理、購買統制を導入します。

和解時には、関連会社、代理店、権利者団体からの同一事実に基づく請求をどう扱うかも確認します。監査人、再委託先、海外拠点の保管データまで返却・削除・削除証明の対象に含めるかは、個人情報と営業秘密の観点から重要です。

Section 10

ソフトウェア監査後の原因分析とSAM・ITAM体制

監査対応の目的は請求を減らすことだけでなく、同じ問題を繰り返さない統制改善です。

不足の原因は、個人のミスだけではなく、統制の欠落であることが少なくありません。現場がクレジットカードでSaaSを契約する、部署単位の購入が全社台帳に登録されない、退職者・異動者のアカウント解除が遅れる、プロジェクト終了後も開発・検証環境にソフトウェアが残る、M&A後に契約を統合しない、といった原因を分類します。

次の表は、原因分析で確認する統制領域を整理したものです。個人責任の追及に偏らず、どの仕組みが不足していたのかを読み取ることで、再発防止策を具体化できます。

分類確認事項
ガバナンスソフトウェア管理責任者が明確か。経営層がリスクを認識しているか。
ポリシー使用許諾契約、個人購入、無料版、OSS、SaaS、外部委託利用の規程があるか。
購買統制発注前に法務、IT、購買がライセンス条件を確認しているか。
台帳契約、数量、期限、割当、利用実態が一元管理されているか。
技術統制インベントリ収集、ID管理、退職者処理、ライセンスサーバー制御があるか。
教育現場、開発者、設計者、海外拠点にライセンス教育があるか。
監査定期的な内部監査、サンプル調査、是正記録があるか。
M&A買収、事業譲渡、会社分割時にライセンス承継を確認しているか。
契約管理更新期限、監査条項、利用範囲、価格条件を管理しているか。

SAMは、ライセンス違反を避けるだけの守りの仕組みではありません。未使用ライセンスの削減、重複購買防止、SaaSアカウント最適化、セキュリティパッチ管理、旧バージョン把握、M&A統合、クラウドコスト管理、内部統制強化にもつながります。

次の一覧は、最小限整えるべきSAMプロセスを順番に示しています。成熟した体制を一度に作るのは難しいため、読者は自社で先に着手すべき基盤と、監査後の改善項目を読み取ってください。

1

ポリシー

ソフトウェア利用、購入、インストール、SaaS契約、OSS利用、外部委託利用の規程を整備します。

規程
2

責任者

IT、法務、購買、経理、各事業部の責任分担を定めます。

体制
3

承認経路

購入前にライセンス条件、個人情報、セキュリティ、予算を確認します。

購買
4

台帳

契約、数量、期限、利用者、デバイス、部署、費用負担を一元管理します。

記録
5

インベントリ

端末、サーバー、クラウド、SaaS、ライセンスサーバーの利用実態を定期取得します。

実態
6

照合

保有権利と利用実態を定期的に照合し、ELPを更新します。

ELP
7

是正

不足、過剰、休眠、違反可能性を処理し、記録を残します。

改善
8

教育

現場、開発者、設計者、管理職、海外拠点に実務教育を行います。

周知
9

内部確認

内部監査部門または第三者が定期的にサンプル調査を行います。

確認
10

改善

結果を購買、契約、ID管理、退職者処理、M&Aプロセスへ反映します。

継続

新規契約・更新契約では、監査条項を交渉することも重要です。年1回以下、合理的通知、営業時間内、業務妨害なし、対象契約・製品・期間の限定、独立第三者、目的外利用禁止、返却・削除、原則ベンダー費用負担、合理的期間内のTrue-up、関連会社・海外拠点・委託先・クラウド・DR環境の権利範囲、M&A時の移転・承継条項を検討します。

Section 11

ソフトウェア監査対応の実務チェックリストと文面例

初動、ベンダー確認、社内資料、和解時の確認を一つの実務線で整理します。

監査対応では、初動で確認する事項、ベンダーに質問する事項、社内で収集する資料、和解時に確認する事項を分けて管理します。次の表は、各場面で漏れやすい項目を整理したもので、読者は自社の対応状況を左から右へ確認できます。

場面確認する項目
初動受領日時、通知者、真正性、法務・IT・購買・経理・個人情報保護・セキュリティ共有、窓口一本化、監査権条項、対象法人・製品・期間・地域、期限延長、証拠保存、削除・廃棄停止、監査ツール保留、NDA・DPA、社内調査計画、外部専門家の要否
ベンダーへの質問法的根拠、対象範囲、監査人、守秘義務、取得データ、個人情報・営業秘密・セキュリティ情報の含有、保管国、再委託先、利用目的、返却・削除、算定方法、価格、反論・再計算の手続
社内資料契約書、EULA、製品別条件、注文書、請求書、証書、ベンダーポータル、ライセンスキー、購買台帳、固定資産台帳、インベントリ、ユーザー割当、退職者リスト、利用ログ、仮想化・クラウド構成図、M&A資料、外部委託契約、過去監査結果
和解時対象範囲、支払額、購入数量、対象製品、追加請求遮断、不認容、監査データの返却・削除・削除証明、秘密保持、公表禁止、関連会社・代理店・権利者団体からの請求遮断、将来監査、会計・税務、取締役会・監査役・監査法人報告

監査通知への初回返信例

件名 ― ライセンス監査通知に関する確認

貴社からの通知を受領しました。当社は本件を適切に確認するため、社内の法務、IT、購買、情報セキュリティ担当を含む対応体制を設けています。

まず、監査の根拠となる契約、対象法人、対象製品、対象期間、監査方法、取得予定データ項目、監査人の守秘義務、データ保管場所および保管期間をご提示ください。

当社は必要な範囲で合理的に協力する意向ですが、この返信は、契約違反、ライセンス不足、著作権侵害、損害額その他の事実または法的責任を認めるものではありません。

監査ツールの実行またはデータ提供については、取得データ、個人情報、営業秘密、情報セキュリティ上の影響を確認した上で、別途協議させてください。

社内向け証拠保存通知例

件名 ― ソフトウェアライセンス監査に関する関連資料保存のお願い

当社は、特定ソフトウェアに関するライセンス監査通知を受領しました。関係部門は、対象製品に関する契約、発注、請求、インストール、利用ログ、端末、サーバー、クラウド、ユーザー割当、社内申請、メール、チケット、台帳等を削除・変更・廃棄しないでください。

通常の業務運用であっても、関連するログ、端末、仮想マシン、アカウント、ライセンスキー、契約資料の削除・廃棄が予定されている場合は、事前に法務部およびIT資産管理担当に連絡してください。

本件について外部のベンダー、代理店、監査人から連絡を受けた場合は、個別に回答せず、指定窓口へ転送してください。

Section 12

ソフトウェア監査対応でよくある質問

回答は一般的な制度説明です。個別の契約・利用実態で結論は変わります。

Q1. 監査通知を無視してもよいか。

一般的には、正式な監査通知を放置すると、契約上の協力義務違反、契約解除、訴訟、差止請求、交渉上の不利益につながる可能性があります。ただし、正式監査か、任意のSAM支援か、営業連絡かによって対応は変わります。真正性と根拠契約を確認した上で、権利義務を留保して回答することが考えられます。具体的な対応は、通知文面と契約資料を整理したうえで弁護士等の専門家へ相談する必要があります。

Q2. 不正インストールを見つけたらすぐ削除すべきか。

一般的には、違法状態を放置することは避けるべきとされていますが、監査通知後に証拠保存なく削除すると、事実関係を説明できなくなる可能性があります。まずインストール状況、利用状況、原因、期間を記録し、その後に利用停止、隔離、削除、正規ライセンス購入などを検討します。具体的な順序は、証拠関係と契約条項で変わるため、専門家へ相談する必要があります。

Q3. ベンダー指定の監査ツールは必ず実行しなければならないか。

一般的には、契約条項によって判断が変わります。監査協力義務がある場合でも、取得データ、個人情報、営業秘密、セキュリティ、業務影響を確認しないまま実行するとリスクが高まる可能性があります。取得データ一覧、送信先、保管期間、NDA、DPA、削除証明を確認し、必要に応じてサンプル環境で検証することが考えられます。

Q4. 不足がある場合、すぐに見積書どおり購入すべきか。

一般的には、ベンダー算定を検証する前に購入すると、対象外数量や過大算定を受け入れてしまう可能性があります。数量、対象期間、対象法人、旧契約の利用権、ダウングレード権、休眠端末、退職者、仮想化、価格、保守料を確認する必要があります。購入する場合も、追加請求遮断、不認容、監査データ削除、秘密保持を含む合意を検討します。

Q5. 小規模企業でも同じ対応が必要か。

一般的には、規模に応じて簡素化できますが、基本原則は同じです。小規模企業ほど、契約書、請求書、台帳が散在しやすく、担当者が一人で対応してしまう可能性があります。最低限、経営者、IT担当、法務担当または外部専門家が関与し、通知の真正性、契約根拠、対象範囲、提出データを確認する必要があります。

Q6. 海外子会社が監査対象に含まれる場合はどうするか。

一般的には、契約主体、関連会社定義、地域制限、現地法、データ越境移転、現地従業員情報、現地ベンダー契約を確認する必要があります。日本本社が一括回答する場合でも、海外法人の権限、現地法務、現地IT、現地個人情報規制の確認が重要です。海外監査人にデータを渡す場合、個人情報保護法上の外国にある第三者提供や委託の整理が必要になる可能性があります。

Q7. 社内の誰がリーダーになるべきか。

一般的には、法務または企業内弁護士が全体統制を担い、IT/SAM担当がデータ収集を担う体制が望ましいとされています。ただし、組織規模、製品の専門性、海外拠点の有無、請求額、訴訟リスクによって必要な体制は変わります。経営判断が必要な場合は、CLO、CFO、CIO、CISO、監査役、取締役会の関与を検討します。

Q8. 監査対応を外部弁護士に依頼する意味は何か。

一般的には、監査範囲、契約解釈、著作権侵害リスク、回答文書、和解条項、証拠保存、交渉戦略を一貫して管理しやすくなる点に意味があります。特に高額請求、海外ベンダー、複数国、権利者団体、訴訟可能性、上場会社、内部不正が絡む場合は、早期に専門家へ相談する必要性が高まります。

Section 13

ソフトウェア監査の経営報告・失敗事例・結論

高額化・長期化・訴訟化の可能性がある場合は、経営層と監査役への報告が必要です。

ソフトウェア監査が高額化、長期化、訴訟化、社会的信用問題化する可能性がある場合、経営層、取締役会、監査役への報告が必要になります。報告では、感情的な責任追及ではなく、事実、リスク、金額、対応方針、再発防止を整理します。

次の表は、経営層・取締役会へ報告する項目を整理したものです。報告の目的は責任追及ではなく、予算、和解、外部専門家、情報提供、再発防止の意思決定を進めることにあるため、左列ごとに右列の情報を準備する必要があります。

報告項目内容
監査通知の概要通知日、ベンダー、対象製品、対象法人、対象期間
契約上の根拠監査条項、協力義務、期限、費用負担
初動対応窓口、証拠保存、外部専門家、スケジュール
暫定リスク不足可能性、金額レンジ、訴訟・差止・業務停止リスク
データ提供リスク個人情報、営業秘密、越境移転、セキュリティ
調査結果エンタイトルメント、利用実態、争点、原因
交渉方針不足認否、和解範囲、価格、条項、スケジュール
会計・税務影響引当、費用計上、予算、監査法人対応
再発防止策SAM体制、購買統制、教育、内部監査
決裁事項予算、和解、外部専門家、取締役会承認要否

次の比較一覧は、監査対応で起こりやすい失敗と改善策をまとめたものです。失敗の共通点は、早く片付けようとして範囲、証拠、責任、価格を混同する点にあります。読者は自社の初動ルールに不足がないかを読み取ってください。

Case 01

IT担当者が単独で監査ツールを実行

対象外製品、個人情報、営業秘密、古い端末、海外拠点データまで送信されるおそれがあります。改善策は、法務、セキュリティ、個人情報保護担当を含むツール実行前承認です。

Case 02

監査前にソフトウェアを削除

証拠隠滅の疑い、利用期間不明、内部調査不能につながります。改善策は、削除前にスクリーンショット、ログ、端末一覧、利用者確認、削除承認記録を残すことです。

Case 03

契約主体を確認せずグループ全社で回答

対象外法人まで監査範囲が広がる一方、本来対象の関連会社を漏らすと虚偽回答と疑われる可能性があります。改善策は対象法人マトリクスの作成です。

Case 04

営業提案と監査結果を混同

高額な包括契約やクラウド移行提案と、監査上の不足額を混同すると合理的な解決を見失います。改善策は、事実認定、法的責任、将来調達戦略を分けることです。

結論として、ソフトウェア監査を受けたときの対応で最も重要なのは、監査をベンダーに言われたとおりにデータを出す作業と捉えないことです。監査通知を受けたら、法務主導で体制を作り、監査権を確認し、対象範囲を限定し、証拠を保全し、エンタイトルメントと利用実態を照合し、ベンダー算定を検証し、必要な是正を行い、和解または終了確認で将来リスクを遮断します。

監査後は、ソフトウェア管理責任者、管理規則、台帳、内部監査、教育、購買統制、SaaSアカウント管理、M&A時のライセンスデューデリジェンス、契約更新時の監査条項交渉へ移行します。企業法務の観点では、防御、交渉、統制改善の三段階を守ることが、不要な支払い、業務停止、情報漏えい、訴訟、信用低下を防ぐ実践的な方法です。

Reference

参考資料

公的機関、標準、主要ベンダーの公開資料を中心に整理しています。

法令・公的機関

  • e-Gov法令検索「著作権法(昭和四十五年法律第四十八号)」
  • 特許庁「著作権侵害への救済手続」
  • 経済産業省「ソフトウェア管理ガイドライン」
  • 個人情報保護委員会「個人情報の保護に関する法律についてのガイドラインに関するQ&A」
  • 個人情報保護委員会「外国にある第三者に個人データの取扱いを委託する場合は」

標準・実務資料

  • BSA|ザ・ソフトウェア・アライアンス「ソフトウェアライセンスの不備が誘発するリスクと対策」
  • 一般財団法人日本情報経済社会推進協会「SAMユーザーズガイド―導入のための基礎―」
  • 日本規格協会「ISO/IEC 19770-1:2017/Amd 1:2024 追補1―情報技術―ITアセットマネジメント―第1部―ITアセットマネジメントシステム―要求事項―気候変動対応」
  • National Institute of Standards and Technology「SP 800-86, Guide to Integrating Forensic Techniques into Incident Response」

主要ベンダー資料

  • Microsoft「ライセンス監査 FAQ - マイクロソフト ボリューム ライセンス」
  • Microsoft「製品ライセンス条件 - マイクロソフト ボリューム ライセンス」
  • Oracle日本「LMS FAQs」
  • Adobe「General Terms of Use」
  • Autodesk「Genuine Autodesk | Audits」