SaaSが増えるたびに監査ログの確認作業も増え、どこから手をつけるべきかわからなくなっている——そんな状況に置かれている情シス担当者は少なくありません。Google WorkspaceやMicrosoft 365、Slack、Salesforceなど、企業内で20種類以上のSaaSを導入するケースが当たり前になった今、監査ログの管理はオンプレミス時代とは次元が異なる複雑さを持ちます。

J-SOXへの対応、ISMS認証の維持、セキュリティインシデント発生時の原因究明と、監査ログを適切に取得・保管しなければならない理由は年を追うごとに増えています。それにもかかわらず、各SaaSの管理画面を個別に開いてログをエクスポートする手作業を繰り返しているケースがほとんどです。

本記事では、主要8種類のSaaSにおける具体的なログ取得手順から、SOX・ISMS対応に必要な保存期間の要件、複数SaaSを一元管理するための実践的なアプローチまでを体系的に解説します。情シス担当者として監査ログ管理の仕組みを整えたい方に向けた内容です。

監査ログとは？SaaS時代の情シスが知るべき基本知識

監査ログは、システムやサービス上で発生したあらゆる操作を記録したデジタル証跡です。内部統制・セキュリティ対応・コンプライアンス維持の3つの観点から、情シス担当者が日常的に管理すべき対象です。

監査ログの定義と4要素

監査ログとは、「いつ・誰が・どこから・何をしたか」という4要素を時系列で記録したログのことです。ユーザーのログイン・ログアウト、ファイルの閲覧・編集・削除、権限の変更、管理者操作といったイベントが記録の対象となります。

混同されやすいログとして、アクセスログと操作ログがあります。アクセスログはWebサーバーへのリクエスト記録に特化しており、誰がどのページを閲覧したかを把握するものです。操作ログはシステム上で行われた操作全般を記録しますが、「誰が」という情報を必ずしも含むとは限りません。監査ログはこれらより包括的な概念であり、証跡としての信頼性・完全性が特に求められます。

なぜSaaS環境で監査ログ管理が難しいのか

オンプレミス環境では、監査ログを自社サーバーに集約できました。SaaS環境ではそのアプローチが通用しません。各ベンダーのクラウドインフラ上でログが生成・保管されるため、企業側が直接サーバーにアクセスしてログを取得する方法はそもそも使えないからです。

SaaS固有の難しさは3点に集約されます。第一に、SaaSごとにログの取得方法・エクスポート形式・保存期間がまったく異なること。第二に、プランによって取得できるログの詳細度に差があること。そして第三に、20種類以上のSaaSを抱える企業では、全サービスのログを手動で確認する工数が現実的な限界を超えることです。

たとえば、Microsoft 365のE1プランでは監査ログの保存期間が90日ですが、E5プランでは1年、拡張オプションを使えば最大10年まで保持できます。プランによってこれだけ差があるにもかかわらず、把握せずに運用を続けると、内部統制の要件を満たせないまま監査を迎えることになります。

監査ログを取得する3つの目的と法的根拠

監査ログは「何かあったときのため」という漠然とした理由で取得するものではありません。具体的な法的根拠と業務上の必要性に基づいて収集・管理することで、取得範囲と保存期間の設定も明確になります。

内部統制・コンプライアンス対応

上場企業においては、J-SOX（金融商品取引法に基づく内部統制報告制度）への対応が義務付けられています。J-SOXでは「ITに係る業務処理統制」の整備・運用状況を評価することが求めらており、システムへのアクセス履歴や操作履歴がその評価証拠として機能します。

「誰がいつどのシステムにアクセスし、何を操作したか」を証明できる監査ログは、内部統制評価の根拠資料となります。経営者評価でも外部監査人による評価でも、監査ログの整備状況は確認対象です。SaaS環境では特に、財務系SaaSやCRM・ERPへのアクセス管理ログが重視されます。

セキュリティインシデントの調査・原因究明

不正アクセスや情報漏洩などのセキュリティインシデントが発生した際、監査ログは「何がいつ起きたか」を遡及的に調査する手段となります。ログがなければ、被害範囲の特定も再発防止策の立案も、第三者への説明もできません。

SaaS環境では、退職者アカウントの削除漏れによる不正アクセスや、共有リンクを通じた意図しない情報公開など、オンプレミスでは考えにくかったインシデントが発生しやすくなっています。日常的な監査ログの収集と保管がインシデント対応の前提条件です。

ISMS・ISO27001認証の取得・維持

ISO27001の管理策A.12.4では、「ログ取得と監視」が明示的に求められています。ユーザー活動・例外事象・障害・情報セキュリティイベントを記録したログを取得・保護し、定期的にレビューすることが管理策として位置づけられています。

ISMS認証の取得・維持審査では、「取得すべきログを定義しているか」「実際にログを収集できているか」「定期的にレビューしているか」「改ざん防止措置を講じているか」の4点が主な確認事項となります。

参考: ISMS クラウドセキュリティ対応ガイドライン（IPA）

【SaaS別】監査ログの取り方・具体的な手順

各サービスの取得手順を正確に把握することが、SaaS環境での監査ログ管理の第一歩です。情シス担当者が日常的に管理する主要8種類のSaaSについて、具体的な操作手順を整理しました。

Google Workspace の監査ログ取得手順

Google Workspaceの監査ログは、Google 管理コンソールから取得します。管理者権限を持つアカウントで admin.google.com にアクセスし、左側メニューの「レポート」から「監査と調査」を選択します。

取得できる監査ログの種類は次の4つです。

• 管理者活動ログ: 管理者によるユーザー追加・削除・権限変更などの操作
• Googleドライブ監査ログ: ファイルの作成・編集・共有・ダウンロード・削除
• Gmailログ: メール送受信・転送設定の変更
• ログイン監査ログ: ログイン成功・失敗・不審なログイン

ログはCSVまたはJSON形式でエクスポートでき、BigQueryへの連携にも対応しています。保存期間はイベントの種類によって異なり、管理者活動ログとドライブ・Gmailログはいずれも180日間が標準です。無料版では一部ログが取得できないため、有料プランの契約状況を事前に確認してください。

参考: Google 管理コンソールヘルプ（監査ログ）

Microsoft 365 の監査ログ取得手順

Microsoft 365の監査ログはMicrosoft Purviewコンプライアンスポータルから取得します。compliance.microsoft.com に管理者でサインインし、左メニューの「監査」を選択します。日時範囲・活動の種類・ユーザーを指定して検索し、結果をCSVでエクスポートできます。

PowerShellを使った一括取得も可能です。以下のコマンドで対象期間の監査ログを取得できます。

PowerShell

Search-UnifiedAuditLog -StartDate "2026-01-01" -EndDate "2026-03-31" -ResultSize 5000


プランによって保存期間が大きく異なる点は、J-SOX対応を検討する際に特に重要です。

7年間の保存が求められる場合は、E5プランの拡張監査機能とAzure Storageへのアーカイブを組み合わせる必要があります。

参考: Microsoft Purview 監査ソリューションの概要（Microsoft Learn）

Slack の監査ログ取得手順

Slackの監査ログ機能はエンタープライズグリッドプランに限定されており、プロプランやビジネスプランでは監査ログAPIにアクセスできません。導入プランを事前に確認することが必要です。

エンタープライズグリッドプランであれば、Slack Audit Logs APIを通じてログを取得できます。ユーザーのログイン・ログアウト、チャンネルの作成・削除・アーカイブ、ファイルの共有・ダウンロード、メッセージの削除・編集、ワークスペースの設定変更などが取得対象です。APIレスポンスはJSON形式で返されるため、SIEMツールやデータレイクへの連携が比較的容易に行えます。

Salesforce の監査ログ取得手順

SalesforceはCRMとして広く導入されており、顧客・商談情報という機密性の高いデータを扱うため、監査ログの管理は特に重要です。

標準機能の「設定変更履歴（Setup Audit Trail）」では過去180日間の設定変更を確認できます。設定画面から「セキュリティ」の「設定変更履歴」にアクセスし、CSVダウンロードが可能です。より詳細なユーザー操作ログが必要な場合は「イベントモニタリング（Event Monitoring）」アドオンが必要となり、ログイン履歴・APIアクセス・レポートのエクスポートなど40種類以上のイベントをHourly Log形式で取得できます。

その他主要SaaSの監査ログ取得方法

情シス担当者がよく管理する4サービスについて、取得方法をまとめます。

Box は管理コンソールから「レポート」→「エンタープライズイベント」を選択します。最大10年間のイベント履歴が保存され、ユーザーごとのファイル操作・共有設定変更・管理者操作を詳細に記録できます。

Dropbox Business は管理者コンソールの「アクティビティ」セクションから、チームメンバーの全操作履歴を確認できます。CSVエクスポートも可能ですが、ビジネスプラン以上の契約が必要です。

Zoom は管理者ダッシュボードの「レポート」から、ミーティングの開催記録・参加者情報・録画設定変更などのログを取得できます。全社的なウェビナーや重要会議の記録としてアーカイブしておく価値があります。

kintone は cybozu.com 管理画面の「使用状況確認」から、アプリの利用状況とユーザーの操作履歴を確認できます。Cybozu Garoonと組み合わせることで、より詳細なアクセス制御と監査ログ管理が可能になります。

監査ログで記録すべき項目・イベントの優先度

すべてのログを等しく管理しようとすると、確認工数が際限なく膨らみます。限られたリソースで実効性のある管理を維持するには、取得・確認すべきイベントの優先度をあらかじめ設定しておくことが必要です。

セキュリティ上、必ず記録すべき5種類のイベント

内部統制とセキュリティの両面から、優先的に記録・確認すべきイベントが5種類あります。これらを「最優先ログ」として定期レビューの対象に含めましょう。

• ログイン成功・失敗: 短時間での連続ログイン失敗はブルートフォース攻撃の兆候です。特に管理者アカウントへの不審なログイン試行は見逃せません
• ファイルの閲覧・ダウンロード・削除: 大量のファイルダウンロードや機密情報を含むファイルの外部共有は情報漏洩リスクの指標となります
• 権限変更: 管理者権限の不正付与は内部不正の典型的な手口です。変更のたびに確認できる体制を整えましょう
• 外部共有設定の変更: Google DriveやMicrosoft 365の外部共有設定が変更された場合、意図しない情報公開につながります
• アカウント作成・削除: 退職者アカウントの削除漏れや、承認なしで作成されたアカウントはセキュリティホールになります

これら5種類を基本として、自社の業務リスクに応じて追加項目を検討してください。

コンプライアンス対応で追加すべき項目

J-SOXやISMSへの対応においては、上記5種類に加えて以下の項目も記録・保管する必要があります。

• 管理者操作ログ: 特権アカウントによる操作は内部統制評価の主要確認事項です。設定変更からデータ操作まで、すべての操作を記録します
• 設定変更ログ: セキュリティポリシーや認証設定の変更は、リスク増大に直結する変更として管理が必要です
• データエクスポートログ: 顧客データや財務データのエクスポート操作は、情報漏洩リスクの観点から重点的に監視します

参考: ISMS管理策 A.12.4「ログ取得と監視」の解説（IPA）

監査ログの保存期間と改ざん防止の要件

監査ログは取得するだけでは不十分です。適切な期間保存し、改ざんされないよう保護することが求められます。準拠する法規制・基準によって要求される保存期間が異なるため、自社に適用される要件を正確に把握してください。

法規制・基準別の保存期間要件

保存期間の要件は準拠する基準によって異なります。下表を参考に、自社に該当する要件を確認しましょう。

上場企業においては、J-SOXの観点から7年間の保存が実務上の基準となっています。多くのSaaSは標準で90日〜1年しかログを保存しないため、別途アーカイブ手段が必要です。

参考: 日本セキュリティ監査協会 サイバーセキュリティ対策マネジメントガイドライン

SaaSの保存期間の限界と補完方法

SaaSの標準ログ保存期間は、法的要件を満たすには不十分なケースがほとんどです。Google Workspaceは最大180日、Microsoft 365のE1プランは90日であり、J-SOXの7年要件とは大きなギャップがあります。

参考: Google Workspace 監査ログの保持期間（管理者ヘルプ）

このギャップを埋める方法として、3つのアプローチが現実的です。

外部ストレージへのアーカイブは、AWS S3やAzure Blob Storageなどへ定期的にログをエクスポートして長期保管するアプローチです。コストを抑えながら大容量を保管できますが、定期エクスポートの自動化とモニタリングの仕組みを別途整備する必要があります。

SIEMとの連携は、Splunk・Microsoft Sentinel・IBM QRadarなどのツールを導入し、複数SaaSから自動収集・長期保管する方法です。リアルタイム分析や異常検知機能も備えており、セキュリティ運用の高度化につながります。ただし導入・運用には専門知識とコストが必要です。

SaaS管理プラットフォームの活用は、後述するアプローチです。SIEMより導入ハードルが低く、情シス2〜3名体制の企業でも運用しやすい選択肢となります。

改ざん防止のための3つの対策

監査ログの証拠能力を確保するには、改ざんされていないことを証明できる仕組みが必要です。以下の3つを組み合わせることを推奨します。

WORM型ストレージの活用では、一度書き込んだデータを上書き・削除できない仕組みを活用します。AWS S3のObject LockやAzure Blob StorageのImmutable Storageがこれに該当し、監査ログの改ざん防止に有効です。

ハッシュ値による整合性検証は、ログデータのSHA-256ハッシュ値を定期的に記録し、後から「この時点のログと現在のログが一致するか」を検証する方法です。ログが改ざんされた場合でも、ハッシュ値の不一致から検出できます。

別環境へのリアルタイム転送は、ログを生成したシステムとは分離した環境にリアルタイムで転送・保管する方法です。元システムへの不正アクセスでログが消去されるリスクを軽減でき、管理者権限を持つ人物による内部不正対策としても有効です。

参考: J-SOX実施基準（金融庁） / ISMS 管理策A.12.4 解説（IPA）

複数SaaSの監査ログを一元管理する方法

SaaS導入数が増えるほど、監査ログ管理の負荷は増大します。20種類以上のSaaSを抱える企業では、一元管理の仕組みを構築することが情シスチームの継続的な運用を支える前提条件になっています。

手動管理の限界

手動による監査ログ管理がどこで限界を迎えるか、具体的に考えてみましょう。20種類のSaaSを管理している場合、毎月の監査ログ確認だけで各サービスへのログイン・エクスポート・集計という作業が20回発生します。

各SaaSで取得できるログの形式もバラバラです。CSV・JSON・独自フォーマットが混在するため、横断的な分析も困難です。「退職者がどのサービスにいつアクセスしたか」を調べるためだけに、複数の管理画面を渡り歩く必要が生じます。担当者が異動・退職した際に、各SaaSのログ取得手順ナレッジが引き継がれないリスクも現実的な問題です。

SaaS管理 課題

SIEMとの連携

SIEMは複数のシステム・サービスからセキュリティ関連のログを集約し、リアルタイムで分析・監視するためのプラットフォームです。Splunk・Microsoft Sentinel・IBM QRadarなどが代表的なツールとして知られています。

各SaaSのAPIと連携して監査ログをリアルタイムで収集・一元保管できるため、手動エクスポートの手間は大幅に削減されます。異常なアクセスパターンを自動検知するルールを設定することで、セキュリティインシデントの早期発見にも貢献します。ただし、導入・運用にはセキュリティの専門知識と相応のコストが伴います。大企業やセキュリティ専任チームを持つ企業には適していますが、情シス担当者が2〜3名という中堅企業では導入ハードルが高いのが実態です。

SaaS管理プラットフォームによる一元化

情シス2〜3名体制の企業が現実的に監査ログを一元管理するうえで最も導入しやすいのが、SaaS管理プラットフォームの活用です。

SIEMがセキュリティ分析に特化しているのに対し、SaaS管理プラットフォームはアカウント管理・コスト管理・アクセス権限管理を総合的に扱います。APIを通じて主要SaaSと連携し、ユーザーのアカウント状態・権限変更・操作履歴を1つの管理画面で確認できるため、各SaaSの管理画面を個別に開く手間が削減されます。

ジョーシスのプラットフォームを活用することで、Google Workspace・Microsoft 365・Slackなど複数種類のSaaSのアクセス権限変更履歴やアカウント操作ログを自動収集し、一元的に確認できます。各SaaSの管理画面を個別に開いて月次でログを手動確認していた状態から、1つの画面で横断的にアクセス権限の変動を把握できる状態に変わります。内部統制対応の証跡としても活用でき、SOX監査・ISMS審査への対応工数が削減されます。

SaaSアクセス管理とは

アクセス権限 棚卸し 方法

参考: ログ管理システム比較（digi-mado.jp）

監査ログの運用体制の作り方

監査ログは取得して終わりではありません。収集・確認・報告を継続するサイクルを構築することで、初めて内部統制やセキュリティ対策としての実効性が生まれます。

管理の4ステップ

効果的な監査ログ運用は、収集・保存・レビュー・報告の4つのフェーズで構成されます。

Step1は収集対象SaaSと取得項目の定義です。自社で導入しているSaaS全体を棚卸しして、監査ログの取得対象となるサービスを一覧化します。各サービスで取得すべきイベント種別を定義しますが、「全ログを取得する」という方針は工数的に成立しません。セキュリティ上重要なイベントを優先的に取得対象とする設計が現実的です。

Step2は保存先・保存期間・アクセス権限の設計です。ログの保存先を決定し、法規制要件に基づいた保存期間を設定します。同時に、ログデータへのアクセス権限を設計して、改ざん・削除ができる人物を必要最小限に絞ることが重要です。

Step3は定期レビュースケジュールの設定です。日次・週次・月次の3段階でレビューを設計します。日次では特権アカウントの操作ログや不審なログイン試行をアラートで確認し、週次では権限変更ログを確認、月次では全体のアクセス動向レポートを作成するサイクルが一般的です。

Step4は内部監査・外部審査への対応方法の準備です。J-SOX評価やISMS審査に向けて、どのログをどのように提出するかのフォーマットを事前に整えておきましょう。審査直前に「どこからログを取得するか」で慌てないよう、日常的な運用の中で監査対応可能な状態を維持することが大切です。

情シス2〜3名体制での現実的な運用

人員が限られる中で監査ログ管理に実効性を持たせるには、自動化と優先順位付けの2点が鍵になります。

全ログを目視確認することは現実的ではありません。まず、異常なアクセスパターン（深夜のログイン・短時間での大量ダウンロードなど）を自動検知するアラートを設定し、問題が疑われるものだけを人が確認する仕組みを作ります。確認の優先順位は「特権アカウントの操作ログ」「退職者アカウントの残存確認」「外部共有設定の変更」の3点を最優先とすることを推奨します。

月次レポートはテンプレートを作成して定型化しておきましょう。担当者が変わっても同じ品質の運用が継続でき、ISMS内部監査や外部審査の際の証跡としても活用できます。

監査ログ管理ポリシーの策定

監査ログ運用を組織として継続するには、ポリシーとして文書化することが欠かせません。ポリシーに記載すべき項目は以下のとおりです。

• 取得対象SaaSと取得イベント種別（どのサービスの何を記録するか）
• 保存場所と保存期間（どこに何年間保存するか）
• アクセス権限（誰がログデータにアクセスできるか）
• レビュースケジュール（いつ・誰が・どのように確認するか）
• 異常検知時の対応フロー（インシデント発生時のエスカレーションルート）
• 年次見直しのスケジュール（サービス追加・変更時の更新タイミング）

このポリシーを全社で共有・運用することで、担当者の異動や退職があっても監査ログ管理体制を継続できます。

IT内部統制とは

ITガバナンスとは

参考: ISO27001内部監査 実施ガイド（JIPDEC）

ジョーシスで実現するSaaS監査ログの一元管理

分散した監査ログ管理の課題を解決するアプローチとして、SaaS管理プラットフォームであるジョーシスの活用が挙げられます。複数SaaSのログ確認に追われる状態を変えるための実践的な手段です。

ジョーシスのプラットフォームはAPI連携によってGoogle Workspace・Microsoft 365・Slackなど複数種類のSaaSとリアルタイムで連携します。各SaaSで発生したアカウント操作・権限変更・利用状況の変化を1つの管理画面で横断的に確認できるため、個別の管理画面へのログイン・エクスポート作業が不要になります。

SaaS導入数の増加とともに「誰がどのサービスにアクセスできるか」の把握が困難になり、退職者アカウントの削除漏れや過剰な権限付与が見えにくくなっていたケースが多くあります。ジョーシスを導入することで、全SaaSのアクセス権限を一元的に可視化・管理できる状態になり、権限変更の履歴も時系列で確認できるようになります。

SOX監査やISMS審査の際に必要な「誰がいつどのSaaSにアクセスし、何の権限を持っているか」という証跡も、ジョーシスの管理画面から効率的に取り出すことが可能です。複数種類のSaaSにまたがるアクセス権限の履歴を一括で確認・出力できるため、監査対応の工数が削減されます。

日常的な監査ログ確認・アカウント管理をジョーシスのプラットフォームが担うことで、情シス担当者はセキュリティポリシーの改善や内部統制強化といった本来注力すべき業務に時間を使えるようになります。

SaaS管理プラットフォームとは

SaaSガバナンス 強化 方法

まとめ

SaaS環境における監査ログ管理は、取得方法・保存要件・一元管理の仕組みという3つの軸で整備することが求められます。それぞれの要点を確認しましょう。

取得方法については、各SaaSで操作手順・エクスポート形式・保存期間が異なります。まず自社で使用するSaaSを棚卸しし、各サービスの取得手順と保存期間を把握することが出発点です。

保存期間の要件はJ-SOX（7年）・ISMS（1年以上）・PCI DSS（1年）など準拠する基準によって異なります。多くのSaaSの標準保存期間はこれらを下回るため、外部アーカイブや専用ツールによる補完が必要です。改ざん防止には、WORM型ストレージ・ハッシュ値検証・別環境への転送を組み合わせることが有効です。

複数SaaSの一元管理については、情シス2〜3名体制ではSaaS管理プラットフォームが現実的な選択肢です。SIEMと比べて導入・運用ハードルが低く、アクセス権限管理と監査ログ確認を同一画面で行えます。

まず取り組べきアクションとして、「自社SaaSの棚卸しと各サービスのログ取得手順の整理」「保存期間ポリシーの策定」「優先確認イベントの定義（特権アカウント操作・外部共有変更など）」の3点から始めることをお勧めします。ジョーシスのプラットフォームを活用することで、これらの課題を一元的に解消し、監査対応と日常運用の両立が可能になります。