Contentful Audit Logs 実践解説: JSON から読み解く監査ログの構造と活用ポイント

Contentful Audit Logs 実践解説: JSON から読み解く監査ログの構造と活用ポイント

Contentful が提供する Audit logs 機能について、実際の JSON データをもとに構造と特徴を整理しました。Update イベントやエラー時の記録方法、actor 情報の粒度などを確認し、監査やセキュリティ対応での活用ポイントをまとめています。
#Contentful
越井 琢巳 (Koshii Takumi)越井 琢巳 (Koshii Takumi)
facebookのロゴhatenaのロゴtwitterのロゴ
2025.08.19

はじめに

本記事では、 Contentful が提供する Audit logs 機能について、実際に出力された JSON データを確認し、その構造や特徴を整理します。公式ドキュメントの記載は機能概要や利用手順にとどまることが多く、実際のデータがどのような形式で出力されるかを具体的に把握する機会は限られています。そこで本記事では、 JSON の実例を取り上げ、どのように読み解けるかを段階的に示します。これにより、読者が自らの環境でログを扱う際の理解を助けることを目的とします。

Contentful とは

Contentful は、クラウドベースのコンテンツ管理プラットフォームです。 API を通じてコンテンツを柔軟に管理できることから、 Web サイトやモバイルアプリケーションなど多様なチャネルに対応できます。エンタープライズ用途においては、多数のユーザーが同時にエントリを更新するケースが想定されるため、変更履歴や監査証跡の管理は欠かせません。そのために提供されている機能が Audit logs です。

Audit logs の有効化方法については こちらの記事 を参考にしてください。

対象読者

  • Contentful を利用しているエンジニアや管理者
  • システム監査やセキュリティ対応に携わる情報システム担当者
  • JSON データを直接扱い、ログ解析を行う必要がある技術者

参考

JSON の構造を確認する

ログの全体像

Contentful の Audit logs は JSON 形式で出力されます。ひとつひとつの要素は「イベント」を表しており、ユーザーや API による操作が発生するたびに記録されます。 JSON のトップレベルには複数のイベントが配列として格納され、それぞれのイベントが操作内容を詳細に記録しています。

各イベントは概ね以下の情報を持ちます。ひとつのイベントを見ることで「誰が」 「いつ」 「どのリソースに」 「どのような操作をしたのか」を把握できます。

  • 操作の種類 (例: Update、Create)
  • 操作が行われた時刻
  • 操作主体 (ユーザーまたは API クライアント)
  • 操作対象 (エントリやスペースなどのリソース)
  • HTTP リクエストとレスポンスの内容
  • 付随するメタデータ

主なフィールド

実際の JSON から、典型的な Update イベントを抜粋した例を以下に示します。顧客データや内部 ID はすべて **** にマスクしています。

{
  "activity_name": "Update",
  "activity_id": 3,
  "category_uid": "6",
  "class_uid": "6001",
  "type_uid": "600103",
  "time": "2025-07-15 23:39:06.688",
  "actor": {
    "type": "User",
    "id": "****"
  },
  "http_request": {
    "http_method": "PATCH",
    "url": {
      "path": "/spaces/****/environments/master/entries/****"
    }
  },
  "http_response": {
    "code": 200
  },
  "web_resources": [
    {
      "type": "Entry",
      "uid": "****"
    }
  ],
  "metadata": {
    "version": "1.3.0",
    "uid": "****"
  }
}

この抜粋に沿って主要なフィールドを解説します。

  • activity_name: 操作の種類を示します。ここでは Update が記録されています。
  • time: 操作が行われた時刻が ISO 形式で記録されています。
  • actor: 操作を行った主体です。 type は User または App などが入り、 id にはユーザー ID やクライアント ID が格納されます。
  • http_request: 実際に送信された HTTP リクエストの情報です。どのメソッド (PATCH、PUT など) が、どの API パスに対して呼ばれたかが記録されています。
  • http_response: リクエストに対する応答コードです。正常時は 200、異常時は 4xx や 5xx が格納されます。
  • web_resources: 操作対象となったリソースです。ここでは Entry が対象であり、 uid にエントリ ID が格納されています。
  • metadata: ログイベントそのものの識別子など、付随する情報です。

イベントを読み解く

Update イベントの典型例

先に取り上げた Update イベントについて、もう少し詳しく見てみましょう。 Update イベントは既存の Entry が編集された場合に発生します。

{
  "activity_name": "Update",
  "time": "2025-07-15 23:38:47.120",
  "actor": {
    "type": "User",
    "id": "****"
  },
  "http_request": {
    "http_method": "PATCH",
    "url": {
      "path": "/spaces/****/environments/master/entries/****"
    }
  },
  "http_response": {
    "code": 200
  },
  "web_resources": [
    {
      "type": "Entry",
      "uid": "****"
    }
  ]
}

このイベントからは次のことがわかります。

  • PATCH リクエスト が master 環境の特定 Entry に対して実行されている。
  • 操作は特定ユーザー (id: ****) によるものである。
  • レスポンスコードは 200 であり、正常に更新が反映されている。

つまり、このイベントは「特定ユーザーがエントリを編集し、それが正常終了した」ことを表しています。運用上は、誰がどのエントリをいつ編集したかを追跡する際に利用できます。

エラー発生時のイベント

正常なレスポンスコード以外が記録される場合もあります。以下は http_response.code が 500 となっている例です。

{
  "activity_name": "Update",
  "time": "2025-07-15 23:04:09.831",
  "actor": {
    "type": "User",
    "id": "****"
  },
  "http_request": {
    "http_method": "PATCH",
    "url": {
      "path": "/spaces/****/environments/master/entries/****"
    }
  },
  "http_response": {
    "code": 500
  }
}

この場合、ユーザーはエントリの更新を試みましたが、サーバー側でエラーが発生しています。監査の観点では、エラーが誰によって、どのリソースに対して、いつ発生したのかを確認することができます。また、システム運用の観点では、頻発する 500 エラーがないかを監視することにより、 API 側の不具合や不正なリクエストの兆候を早期に検知できます。

イベントの連続性を確認する

Audit logs を詳細に確認すると、数秒間隔で連続する PATCH イベントが記録されていることがあります。以下は一連の例です。

[
  {
    "time": "2025-07-15 23:38:26.390",
    "http_request": { "http_method": "PATCH" },
    "http_response": { "code": 200 }
  },
  {
    "time": "2025-07-15 23:38:40.624",
    "http_request": { "http_method": "PATCH" },
    "http_response": { "code": 200 }
  },
  {
    "time": "2025-07-15 23:38:47.120",
    "http_request": { "http_method": "PATCH" },
    "http_response": { "code": 200 }
  }
]

このような連続記録は、管理画面からの編集操作を保存する際に複数回の PATCH が発生していることを示している可能性があります。監査や調査の際には、単発の操作ではなく「ひとまとまりの更新作業」として解釈する必要があります。特に、不正アクセスや操作ミスの調査を行う際には、イベントを単体で切り取るのではなく、時間的な連続性を考慮することが重要です。

実際に検証して見えた特徴と運用上の注意点

Contentful の Audit logs を実際に確認した結果、いくつかの特徴と運用上のポイントが見えてきました。

  • Update イベントは複数回記録される
    単一のエントリ更新でも PATCH が連続して出力される場合があります。監査では「操作のまとまり」として解釈することが重要です。

  • actor 情報の粒度に注意
    actor には User か App が記録されます。API 経由の場合はクライアント ID となるため、実際の利用者を追跡するには対応関係を運用側で把握しておく必要があります。

  • エラーイベントはシグナルになる
    500 系や 400 系のコードも記録されるため、誰がどのリソースに対して失敗したのか確認できます。頻度や傾向をモニタリングすれば、不正操作やシステム不具合の兆候を早期に捉えられます。

  • metadata.uid の活用
    イベントごとにユニークな識別子が付与されるため、外部の監査基盤に取り込む際のキーや、重複排除・時系列整理に有効です。

  • ログの限界を理解する
    Audit logs は監査証跡に特化しており、アプリケーションの詳細なデバッグには向きません。用途を「不正・誤操作の追跡」と割り切って活用するのが現実的です。

まとめ

Contentful の Audit logs は、ユーザーやアプリによる操作を JSON 形式で詳細に記録し、監査証跡として活用できる仕組みです。実際に検証した結果、以下のような特徴が確認できました。

  • 操作は「誰が」 「いつ」 「どのリソースに」 「何をしたか」が明確に分かる形で残る
  • エラーも含めてイベントが記録されるため、不正操作やシステム障害の兆候を把握できる
  • 同一操作で複数のイベントが連続記録されるなど、実運用上の解釈が必要

一方で、Audit logs はあくまで監査用であり、デバッグや細かな差分追跡には向きません。用途を明確に切り分けた上で、監査やセキュリティ対応の基盤として活用することが重要です。

この記事をシェアする

facebookのロゴhatenaのロゴtwitterのロゴ

関連記事

Contentful Content Preview 機能チュートリアル実践 - Next.js での実装例Contentful Content Preview 機能チュートリアル実践 - Next.js での実装例
Contentful バックエンドアプリの構築チュートリアル実践 - イベント通知によるリアルタイム処理Contentful バックエンドアプリの構築チュートリアル実践 - イベント通知によるリアルタイム処理
Zendesk アクションフロー × Amazon Bedrock (Claude) × Contentful による AI カスタマーサポートの構築Zendesk アクションフロー × Amazon Bedrock (Claude) × Contentful による AI カスタマーサポートの構築
Contentful App Framework チュートリアル検証 - Create a custom app 編Contentful App Framework チュートリアル検証 - Create a custom app 編
クラスメソッドの白いロゴ
Facebookのロゴ
Xのロゴ
YouTubeのロゴ

© Classmethod, Inc. All rights reserved.