「先月、取引パイプラインのステージ名が変わっている。誰が変えたのか」——CRMを全社で使い始めて半年ほど経つと、必ずこの質問が出ます。情報システム部門に問い合わせても、変更申請の記録は残っていない。現場に聞いても「自分ではない」と返ってくる。経営企画担当の執行役員として全社のCRM統制に責任を負う立場であれば、ここで答えられないこと自体が問題になります。

そして同じ問いは、監査法人からも来ます。財務報告に係る内部統制の評価では、会計数値の源流になるシステムについて「誰が何を変更できるのか」「変更された記録は残っているか」が確認されます。CRMが受注金額や契約期間を保持していれば、その対象から外れません。

本記事では、HubSpotの監査ログ（Audit Logs）で何が記録され、どこまで遡れ、どう取り出すのかを整理します。あわせて、レコード単位の変更履歴（プロパティ履歴）との役割分担と、内部統制の証跡として何を残すべきかまで踏み込みます。

HubSpotの監査ログでは何が記録されるのか？

監査ログは、HubSpotアカウント内でユーザーが行った操作を一覧・絞り込み・エクスポートできる機能です。設定画面の［アカウント管理］＞［監査ログ］から開きます。閲覧とエクスポートにはSuper Admin権限が必要で、一般ユーザーには開けません。

最初に押さえるべきなのは、記録されるのが「HubSpotユーザーによる操作」に限られる点です。ユーザーによらないプロパティの更新（たとえばフォーム送信）は、監査ログには表示されません。フォーム・トラッキングコード・外部連携が起点の更新は、監査ログではなく後述のプロパティ履歴の側で追うことになります。この切り分けを曖昧にしたまま証跡の設計を始めると、監査法人への説明の途中で破綻します。

3つのビューは何が違うのか？

監査ログの画面には3つのビューが用意されています。日常の調査で使うのは最初の1つですが、セキュリティインシデントの初動では残り2つを先に見ます。どのビューも既定の表示範囲は直近30日です。

モバイルアプリの扱いには注意が必要です。モバイルアプリにログインしたユーザーは30日間ログイン状態が維持されます。アプリを開くたびには記録されず、記録されるのはログインの都度です。「毎日使っているはずのユーザーのログイン記録が月に1件しかない」という状態は異常ではありません。

どのカテゴリーがどのプランで見えるのか？

商談で最も頻繁に問われるのがここです。監査ログはEnterprise専用機能ではありません。ログインとセキュリティアクティビティはStarterから記録されます。一方で、CRMレコードの作成・削除、プロパティ値の更新、ワークフローの変更といった、内部統制で本当に必要になるカテゴリーはProfessional以上です。

注目すべきは機能の有無ではなく、「自社が証跡として必要とするカテゴリーがどのプランから出るか」です。下表は公式ナレッジベースの対応表から、エンタープライズ導入の検討で論点になりやすい項目を抜き出したものです。

出典はHubSpot公式ナレッジベース「View and export account activity history」の対応表です。なお同じページの別の箇所には、Starter／Professionalではログインとセキュリティアクティビティで絞り込めると記載されており、対応表の記述と粒度が揃っていません。私たちがクライアントのプラン選定を支援する際は、この差分を前提に、契約前に自社ポータルまたはHubSpot担当者へ対象カテゴリーの可否を書面で確認する手順を入れています。

Enterpriseでしか得られないものは何か？

プランの差は、カテゴリーの数よりも「深さ」と「外に出せるか」に出ます。Enterpriseでしか使えないのは、詳細タブの追加メタデータ、ユーザー行動を集計するAnalyzeタブ、そしてログを機械的に取り出すAPIです。稟議で費用対効果を説明するときは、この3点を分けて書いたほうが通りやすくなります。

詳細パネルでは、Starter／Professionalでも国・地域・IPアドレス・ログインの種類・ユーザーエージェントを確認できます。Enterpriseではこれに加えて、［Details］タブの追加メタデータと、［View more information］から操作が行われたCRM上の該当箇所へ辿る導線が使えます。「どのレコードで起きたか」まで一手で特定できるかどうかは、インシデント調査の所要時間に直結します。

Enterpriseではさらに、監査アナライザーアシスタントで「どのユーザーが最も頻繁にログインしているか」「最近どのデータがインポート・エクスポートされたか」といった問いを自然文で投げられます。ベータ機能で、Super Adminがオプトインして有効化します。生成AI機能であるため、入力するデータに機微情報を含めない運用ルールを先に決めてから有効化してください。

監査ログの保持期間はどれくらいか？

保持期間は「画面で遡れる範囲」「エクスポートで取り出せる範囲」「API」で別々に定義されています。ここを一本の数字だと思い込んでいると、監査対応の直前に証跡が無いことに気づきます。私たちがHubSpotの統制設計を引き受けるときは、最初にこの表を作り、保持要件との差分を埋める運用を決めてから構築に入ります。

この表で最も実務に効くのは、監査ログ画面が直近30日しか表示しないという1行です。四半期レビューも年度末の評価も、30日のウィンドウでは間に合いません。保持期間を超えた分は、HubSpotの外に出しておく以外に方法がありません。

なお、カテゴリー別の細かい制約も存在します。たとえばコミュニケーション設定のうちサブスクリプションタイプのログは、2025年4月15日以降の分のみが対象で、それ以前の変更と言語バリアントの変更は表示されません。「全部残っているはず」という前提で証跡設計を始めないでください。

保持期間を超えた分をどう残すか？

答えは単純で、定期的にエクスポートして自社の保管基盤に移すことです。問題は頻度と担当者の決め方で、ここを決めずに「必要になったら出す」と運用すると、必要になった時点で30日を過ぎています。

私たちがエンタープライズのポータルで統制設計を行う際は、監査ログの取得を四半期ではなく月次に置いています。四半期だと取得漏れが1回起きた時点で穴が空き、取り返しがつかないためです。月次であれば1回落としても次月に気づけます。

エクスポートはビューごと、または絞り込み条件ごとに［Export report］から実行でき、レポートはメールと通知センターに届きます。アカウント全体のデータ書き出しについてはコンテンツとデータのエクスポートに手順がまとまっています。

監査ログをAPIでどう取り出すか？

月次の取得を人手で回すと、担当者の異動で止まります。Enterpriseであれば、ログの取得は自動化できます。HubSpotはアカウントアクティビティAPIとして3つのエンドポイントを公開しています。

注意点として、ユーザー操作の監査ログを返すエンドポイントだけがEnterprise限定です。ログインとセキュリティの2つにはその但し書きがありません。自動取得の設計を始める前に、自社の契約で何が取れるのかをこの粒度で確認してください。

いずれもAccount activity APIのエンドポイントです。監査ログのレスポンスは、イベントID・カテゴリー・サブカテゴリー・アクション・対象オブジェクトID・発生時刻・実行ユーザー（IDとメールアドレス）という構成です。ログインのレスポンスには成否フラグ・IPアドレス・ロケーション・ユーザーエージェント・国コード・地域コードが含まれ、成功したログインだけでなく失敗したログインも返ります。

監査ログ取得エンドポイントのリファレンスはRetrieve audit logsにあり、ここではバージョン付きのパス（api.hubapi.com/account-info/2026-09/activity/audit-logs）とページングのカーソル（paging.next.after）が確認できます。期間を区切って全件を取り切る実装では、このカーソルの処理が必須です。

取得処理はどのくらいのAPI枠を使うか？

監査ログの取得は日次で回すとレコード数が多くなります。他の連携処理と同じアカウント枠を食い合うため、見積の段階で確認しておく項目です。レート制限の考え方は10秒あたりのバースト制限と1日あたりの上限の2層構造になっています。

プライベートアプリのレート制限は、Free／Starterが10秒あたり100・1日あたり250,000、Professionalが10秒あたり190・1日あたり625,000、Enterpriseが10秒あたり190・1日あたり1,000,000です。10秒あたりの制限はアプリごと、1日あたりの制限はアカウント内の全アプリで共有されます。API Limit Increaseを購入した場合は10秒あたり250となり、1日あたりの上限が1件につき1,000,000加算され、購入は最大2件までです。これらの上限は変更される可能性があります。

実装では、HubSpotのプライベートアプリを1つ作り、監査ログ取得専用のスコープだけを付与する形を推奨します。業務連携用のアプリと兼用すると、どちらの処理が枠を使い切ったのかが分からなくなります。

プロパティ履歴と監査ログは何が違うのか？

「誰がいつ何を変えたか」を追う機能はHubSpotに2系統あります。ここを取り違えたまま証跡設計を進めると、監査人への提出物が噛み合いません。監査ログがアカウント全体を横断する時系列の操作記録であるのに対し、プロパティ履歴は1レコードの1項目について値の変遷を見るものです。

違いは粒度だけではありません。監査ログはユーザー操作だけを記録しますが、プロパティ履歴はワークフロー・インポート・連携・AIエージェントなど、ユーザー以外の変更元も記録します。「フォーム送信で上書きされた」「連携が値を書き戻した」という調査は、監査ログでは成立しません。

プロパティ履歴は何件まで残るのか？

ここが設計上の落とし穴です。プロパティ履歴は無制限ではなく、オブジェクトごとにリビジョン数の上限があります。上限を超えると古い値から消えるため、長期の証跡には使えません。

コンタクトのプロパティは最大45リビジョン、会社・取引・チケット・カスタムオブジェクトのプロパティは最大20リビジョンです。この上限はHubSpot内での変更とAPI経由の変更の両方を含みます。

この数字は、ライフサイクルステージやスコアのように頻繁に書き換わる項目では数か月で埋まります。契約金額や契約期間のように会計数値の源流になる項目であれば、変更のたびに外部へ書き出すか、後述のプロパティ変更イベントで別建ての記録を持たせるかの判断が要ります。これらの上限値も変更される可能性があるため、設計時に最新の記載を確認してください。

変更元はどこまで分かるのか？

プロパティ履歴の［Source］列には、値を更新したツール・ユーザー・プロセスが入ります。手動編集であればユーザーのプロフィール名とメールアドレスが表示され、カスタムエージェントによる変更であればエージェント名と作成者が表示されます。

変更ソースには、CRM UI・一括操作・インポート・ワークフロー・連携・カスタムエージェント・カスタマーポータル・マルチアカウント管理による接続先アカウントなど、多数の値が定義されています。証跡の読み解きでは、この一覧を手元に置いておくと説明の精度が上がります。

復元についても覚えておく価値があります。プロパティ履歴の行にカーソルを合わせると［Restore］が表示される場合があり、表示されるのは変更ソースがCRM UIの編集・インポート・ワークフローのときだけです。一括での巻き戻しについては、直近14日のCRMの変更を戻す機能が案内されています。

ワークフローやリストの変更履歴はどこを見るか？

自動化の設定変更は、監査ログのワークフローカテゴリーにも載りますが、実務の原因調査では各ツールの履歴機能のほうが速く答えに辿り着きます。使い分けの目安は、「誰が変えたか」は監査ログ、「何がどう変わったか」は各ツールの履歴です。

ワークフローについては、リビジョン履歴で変更内容・変更日時・変更したユーザーを時系列で確認でき、特定のリビジョンへ戻せます。実行側の記録は登録履歴で、履歴データは6か月保存されます。1日あたりの成功ログの上限は100,000件で、超過すると成功ログと情報ログはその日の残り時間は保存されず、エラーログは引き続き表示されます。

リストの条件変更はセグメントのバージョン比較、キャンペーンの変更はキャンペーンアクティビティ履歴で追えます。コンテンツ側についてはCMS content audit APIが用意されており、公開操作の記録を機械的に取得できます。

内部統制・J-SOX対応で何を証跡として残すか？

ここからは制度側の話です。CRMの監査ログをどこまで残すべきかは、ツールの機能ではなく自社の評価範囲で決まります。判断の起点になるのは金融庁の基準であり、HubSpotの仕様はその要件に対する充足状況として整理するのが順序です。

企業会計審議会が2023年4月7日に公表した「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準の改訂について（意見書）」では、ＩＴに係る全般統制の具体例として「システムの開発、保守に係る管理」「システムの運用・管理」「内外からのアクセス管理などシステムの安全性の確保」「外部委託に関する契約の管理」が挙げられています。CRMの権限設定・ログイン管理・設定変更の記録は、このうちの運用管理とアクセス管理に直接対応する領域です。

同じ意見書には、ＩＴを高度に取り入れた情報システムについて「システムの仕様によっては、ＩＴを利用して実施した手続や情報の変更等が適切に記録されないことがあり、そのような場合には、事後の検証が困難となるとの問題が生じうる」という記述があります。監査ログの保持期間を自社の評価サイクルに合わせて延ばす作業は、この一文への対応そのものです。

評価サイクルに対して何をいつ取るか？

制度側の要求と、HubSpot側の30日という制約を突き合わせると、取得のカレンダーが決まります。年度末にまとめて対応しようとすると、その時点で9か月分の記録が失われています。

私たちがエンタープライズのクライアントと証跡の運用を組むときは、取得物を「毎月取るもの」「四半期で取るもの」「変更発生時に取るもの」の3層に分けています。層を分けないと、すべてを月次で取ることになり運用が続きません。

ユーザー権限履歴は全製品・全プランで利用でき、Super Admin権限があれば権限名・追加／削除の別・更新者・変更日を確認でき、直近90日分をエクスポートできます。四半期の権限棚卸しでは、現在の権限一覧だけでなくこの履歴も併せて保管してください。「期中に一時的に権限が付与され、戻された」という事実は、現在の一覧には残りません。

ベンダー側のアクセスはどう確認するか？

見落とされやすいのが、HubSpotの従業員が自社ポータルに入った記録です。既定でHubSpotの従業員には限定的なアクセス権があり、サポート対応などのために入ることがあります。委託先の管理を問われたときに答えられる必要があります。

Starter・Professional・EnterpriseのSuper Adminは、直近90日のHubSpot従業員ログインをエクスポートできます。各ログインには、タイムスタンプと所属部門が含まれます。部門はEngineering、Account Management、Services、Customer Support、Sales、Product/User Experienceなどに分かれます。EnterpriseのSuper Adminは、さらに監査ログ上で従業員が行った操作内容まで確認できます。

自社ポータルのセキュリティ水準そのものはセキュリティヘルスで点検できます。90日間ログインしていないユーザーは非アクティブと見なされ、2要素認証はStarter・Professional・Enterpriseのすべてで必須です。権限設計そのものの考え方はユーザー権限ガイドが出発点になります。

個人データの取り扱いとどう整合させるか？

監査ログの長期保管は、個人データの保存期間に関する方針と衝突することがあります。ログには氏名・メールアドレス・IPアドレスが含まれるため、保管先と保管期間を決めずに「とりあえず全部残す」とすると、別の指摘を受けます。

個人情報保護委員会の個人情報の保護に関する法律についてのガイドライン（通則編）は、安全管理措置の考え方を定めた一次情報です。あわせて、経済産業省とIPAが公表しているサイバーセキュリティ経営ガイドライン、中小企業向けではありますが実務的なIPAの中小企業の情報セキュリティ対策ガイドラインも、ログの取得・保管の社内規程を作るときの参照先になります。

HubSpot側では、非アクティブなコンタクトの自動削除をデータ保持ポリシー設定から構成できます。削除されたコンタクトはごみ箱から90日以内なら復元でき、その後は完全に削除されます。HubSpot自体の個人データの取り扱いはHubSpot Product Privacy Policyに定められています。

1,000名規模で監査ログ運用を立ち上げるには何から決めるか？

最後に、設計の順序を示します。機能を一通り理解したあと、多くのプロジェクトが止まるのは「誰が見るのか」が決まっていないためです。監査ログはSuper Adminしか開けません。全社で数名しかいないSuper Adminに、月次の証跡取得という定常業務を背負わせる設計は破綻します。

私たちがこの工程を支援するときに最初に確定させるのは、次の3点です。順番にも意味があります。1点目が決まらないと2点目の粒度が決められません。

1. 評価範囲：どのオブジェクトのどのプロパティが財務報告に影響するかを先に特定する。全項目を証跡の対象にしない
2. 取得物と頻度：1点目で特定した範囲に対し、監査ログ・権限履歴・プロパティ履歴のどれを、どの頻度で、どこへ保管するかを表にする
3. 役割分担：取得の実行者、保管先の管理者、監査対応時の提出責任者を別の人に割り当てる。Super Adminに3役を兼ねさせない

通知の設定も立ち上げ時に済ませておきます。Super Adminは監査ログの通知として、1日に多数のエクスポートが記録されたときの通知と、ユーザーの管理者権限が削除されたときの通知を有効化できます。この2つは、インシデントの初動を早める効果が最も大きい設定です。

権限の付与・剥奪を複数ユーザーへ展開する運用では、他ユーザーとしてのログインがどう記録されるかも確認しておいてください。代理ログインは調査の有力な手段であると同時に、それ自体が統制上の論点になります。2要素認証の適用状況とあわせて、四半期の棚卸し項目に入れることをおすすめします。

よくある質問

導入検討と運用立ち上げの現場で実際に受ける質問のうち、本文の流れに収まらなかったものを挙げます。

監査ログはEnterpriseでないと使えませんか？

いいえ。ログイン・セキュリティアクティビティ・CRMレコードの閲覧・コンテンツアクティビティはStarterから記録されます。CRMオブジェクトの作成削除、プロパティ値の更新、ワークフローの変更はProfessional以上です。ユーザー操作の監査ログをAPIで取得する機能はEnterprise限定です。

フォーム送信で値が書き換わった場合、監査ログで追えますか？

追えません。ユーザーによらないプロパティの更新は監査ログに表示されません。この調査はレコードのプロパティ履歴で行い、［Source］列の値から変更元を特定してください。

30日より前のログを後から取り出すことはできますか？

監査ログ画面の表示範囲は直近30日です。過去に遡って取り出す手段についての記載は、公式ドキュメント上で確認できませんでした。保持要件が30日を超える場合は、期間内に定期的にエクスポートして自社側に保管する運用が前提になります。

証跡として監査ログとプロパティ履歴のどちらを提出すべきですか？

目的が違うため、両方を別々の用途で使います。「権限を持つ者が誰で、どの統制上重要な設定を変更したか」は監査ログ、「個別の取引金額がいつ誰によっていくらから変わったか」はプロパティ履歴です。後者はリビジョン数の上限があるため、長期保管が必要な項目は定期エクスポートを併用してください。

プロパティ履歴のリビジョン上限に達するとどうなりますか？

コンタクトは45、会社・取引・チケット・カスタムオブジェクトは20というリビジョン上限を超えると、古い履歴から保持されなくなります。頻繁に更新されるプロパティでは早く到達するため、対象項目を絞ったうえで、重要な項目はプロパティ履歴のエクスポートを定期実行してください。

誤って削除されたレコードは復元できますか？

できます。監査ログのCRMオブジェクトカテゴリーでDeleteアクションを絞り込み、該当行から復元を実行します。復元できるのは削除から90日以内です。期限を過ぎた分は復元できないため、削除権限の設計そのものを見直す必要があります。

監査ログの取得を外部ツールへ自動連携したいのですが、何から用意しますか？

Enterpriseであることを確認したうえで、監査ログ取得専用のプライベートアプリを1つ作り、必要なスコープだけを付与してください。業務連携用のアプリと兼用すると、1日あたりのAPI上限をどの処理が消費したのかを切り分けられなくなります。アクセストークンはHubSpot外の秘密情報管理の仕組みで保管し、コードや設定ファイルに平文で置かないでください。

監査アナライザーアシスタントに機微なデータを渡しても問題ありませんか？

AI機能で有効化したデータ入力やプロンプトには、機微情報を含めないでください。利用する場合は、どのデータを対象にするかを事前に定義し、生成AI機能の設定をアカウント側で管理したうえで運用してください。

HubSpotの従業員が自社データを見たかどうかを確認できますか？

確認できます。Super Adminであれば、設定＞セキュリティ＞ログインの［Allow Access］からHubSpot従業員のアクセス履歴をCSVでダウンロードできます。範囲は直近90日で、各ログインのタイムスタンプと従業員の所属部門が含まれます。Enterpriseでは監査ログ上で操作内容まで確認できます。

監査ログの設計は、機能の有無ではなく「自社の評価範囲に対して、どの記録を、どれだけの期間、誰が保管するか」を決める作業です。私たちはHubSpotの認定エリートパートナーとして、エンタープライズのCRM統制設計とデータガバナンスの構築を支援しています。評価範囲の切り出しから運用カレンダーの作成までご相談いただけます。お問い合わせはこちらからご連絡ください。

本記事に記載した保持期間・エディション要件・API仕様・上限値は、HubSpot公式ナレッジベースおよび開発者ドキュメントの2026年10月23日取得時点の記載に基づいています。仕様は変更される可能性があります。