kintone変更履歴完全ガイド|確認方法・監査ログとの違い・「誰が見たか」の残し方【2026年版】

kintone変更履歴完全ガイド 確認方法・監査ログとの違い・「誰が見たか」の残し方【2026年版】

本記事は、kintoneの構築・カスタマイズやプラグイン開発の実務経験を持つ筆者が、kintoneに残る「履歴」の仕様と運用上の落とし穴を、公式ヘルプの記載と現場での検証をもとに整理したものです。

この記事を読むと、次のことが分かります。

  • レコードの変更履歴をどこで確認し、何が記録されるのか
  • バージョン番号が飛ぶ理由、保存期間、非表示にする方法とその副作用
  • 変更履歴とプロセス管理の「ステータスの履歴」、監査ログの役割の違い
  • kintone標準では「誰がレコードを見たか」が残らないこと、その埋め方

「このレコード、誰がいつ書き換えたのか」を後から追う場面は、案件管理でも顧客台帳でも必ず出てきます。kintoneはそこに強い一方、履歴の種類が3つに分かれていて、それぞれ見る場所も権限も違います。まずは全体像を押さえてから、個別の仕様に入ります。

kintoneに残る「履歴」は3種類

kintoneの履歴は、大きく次の3つに分かれています。似た名前ですが、記録されるものも、見られる人も別物です。

kintoneの履歴は変更履歴・ステータスの履歴・監査ログの3種類で、レコードを誰が閲覧したかは標準では記録されない

履歴の種類分かること見られる人
レコードの変更履歴いつ・誰が・どのフィールドを変更したかレコードを見られる人
ステータスの履歴いつ・誰が・どのステータスへ進めたかレコードを見られる人
監査ログ削除・書き出し・ファイルDLなどの操作cybozu.com共通管理者のみ

そして、この3つのどこにも入っていないものが1つあります。レコードを「開いて読んだ」という事実です。後半で詳しく触れます。

レコードの変更履歴を確認する

もっとも使う頻度が高いのが、レコード単位の変更履歴です。

表示する場所

レコードの詳細画面を開き、右側のコメント欄にある[変更履歴]アイコンをクリックします。変更日時の新しいものから順に並び、そのレコードがいつ誰によって作成され、どこが変更されたかをバージョンごとに追えます。

コメント欄と同じ場所に切り替え表示される形なので、初めて触る方は「どこにあるのか分からない」と迷いがちです。アイコンの位置だけ最初に共有しておくと、社内からの問い合わせが減ります。

過去のバージョンに戻す

戻したいバージョンの[このバージョンに戻す]をクリックし、確認メッセージを読んで[戻す]を押せば、その時点の内容に復元されます。誤って上書きしたときの救済手段として実用的です。

ただし、いくつか戻せないものがあります。

  • プロセス管理のステータスや作業者は、過去のバージョンに戻せません
  • 編集権限のないフィールドの値も戻せません

注意:過去のバージョンに戻す操作自体も、新しい変更履歴として記録されます。「戻したこと」も証跡に残るので、監査対応の観点ではむしろ好都合です。

バージョン番号が飛ぶ(欠番になる)のはなぜか

変更履歴のバージョン番号を見ると、3の次が5になっているなど、欠番が出ることがあります。壊れているわけではありません。公式ヘルプによると、次のケースで欠番が生じます。

  • 何も変更せずに保存した
  • 自分に閲覧権限がないフィールドを、他のユーザーが変更した
  • 削除されたフィールドの変更

2番目が実務では厄介です。フィールドのアクセス権を絞っているアプリでは、見ている人によって履歴の見え方が変わります。「私の画面では履歴が抜けている」という相談は、たいていこれが原因です。

変更履歴の保存期間・非表示・書き出し

サジェストでよく見かける疑問をまとめて片付けます。

保存期間の設定はない

監査ログには保存期間の設定がありますが、レコードの変更履歴には保存期間や自動削除の設定は用意されていません。記録機能を有効にしている限り、履歴はアプリに残り続けます。

裏を返せば、履歴はディスク使用量を消費します。公式ヘルプでも、変更履歴が有効なアプリでは「変更履歴内にも添付ファイルが保存されています」と明記されています。添付ファイルを頻繁に差し替えるアプリほど、見えない容量が積み上がるわけです。

記録機能を無効にする(=変更履歴を非表示にする)

変更履歴そのものをオフにできます。手順はこうです。

  1. レコード一覧画面で歯車アイコン(アプリを設定)をクリック
  2. 「その他の設定」から「高度な設定」を開く
  3. 「レコードの変更履歴を記録する」のチェックを外す
  4. 保存して[アプリを更新]

重要:無効にすると、そのアプリのレコードの変更履歴が削除されます。あとで有効に戻しても、消えた履歴は復活しません。運用中のアプリで軽い気持ちで触る設定ではありません。

消えないものもあります。レコードの作成日時・作成者の情報は保持され、記録機能を再び有効にしたときに変更履歴欄に表示されます。プロセス管理のステータス変更履歴も「ステータスの履歴」側に残ります。

無効化が推奨される場面もあります。公式ヘルプは、APIでレコード更新を定期的に実行する場合について「変更履歴の記録機能を無効にすることを推奨します。有効にしていると、ディスク使用量が急増する場合があります」としています。外部システムと毎日同期しているアプリなどが該当します。

CSVには書き出せない

ここが標準機能の分かりやすい壁です。レコードの書き出しで選べるのはフィールドの値で、変更履歴を書き出す項目はありません。レコードのコメントは書き出し機能があるのに、変更履歴にはないという非対称になっています。

REST APIも同様で、公開されているAPIにレコードの変更履歴を取得するものは用意されていません(2026年7月時点)。

つまり、変更履歴を「一覧で並べたい」「集計したい」「監査資料として提出したい」なら、標準機能だけでは届きません。1レコードずつ画面を開いて目視する前提の機能だと割り切るのが現実的です。

履歴を業務データとして扱いたいとき

変更内容をフィールドに書き出してしまえば、一覧表示・絞り込み・CSV書き出しといったkintoneの機能がそのまま使えます。この考え方で作ったのがクイック履歴ビュー for kintoneです。

保存のたびに「いつ・誰が・どのフィールドを何から何に変えたか」を文字列(複数行)フィールドへ自動で記録し、詳細画面には時系列の表として表示します。記録対象フィールドや保存件数の上限を絞れるので、ログが無制限に膨らむのも防げます。GASや外部サービスは使いません。無料で配布しています。

プロセス管理の「ステータスの履歴」

プロセス管理を使っているアプリでは、ステータスの変更が変更履歴とは別枠で記録されます。「未処理→処理中→完了」を、いつ誰が進めたかを追える履歴です。

先に触れたとおり、変更履歴の記録機能を無効にしてもステータスの履歴は残ります。承認フローの証跡だけは確実に残したい、というケースでは重要な性質です。

JavaScriptカスタマイズからは kintone.app.record.getStatusHistory(offset, limit) で取得できます。作業日時の降順で、作業日時・作業者・ステータス名が返り、1回で最大100件です。ダッシュボードに「各案件が今の工程に入って何日経ったか」を出したいときなど、この履歴が使えます。プロセス管理そのものの設計はkintoneのプロセス管理の解説記事にまとめています。

監査ログ(管理者向け)

3つめが監査ログです。アプリ単位ではなく、cybozu.com全体の操作記録です。

確認方法と権限

画面右上の設定アイコンからcybozu.com共通管理を開き、監査ログの[閲覧とダウンロード]を選びます。モジュールやアクションで絞り込んで閲覧し、CSVでダウンロードもできます。

アクセスできるのはcybozu.com共通管理者の権限を持つ人だけです。アプリ管理者では見られません。「履歴を確認したいので監査ログを見せてほしい」と現場から依頼が来たときは、まずここで詰まります。

保存期間は6週間〜10年、初期値は3年

保存期間は共通管理の設定で6週間から10年間の範囲で指定でき、初期値は3年間です。内部統制の要件がある会社では、まずこの値が要件に合っているかを確認してください。

なお、大量のデータ追加・更新・削除をAPIで頻繁に繰り返すと監査ログが多く記録され、ディスク使用量に影響します。保存期間を短くすることで使用量が減る場合がある、という案内も公式ヘルプに出ています。

記録されるのは「データが動く操作」

アプリのレコード操作について、監査ログに記録されるアクションは次のようなものです。

アクション内容
Record delete / bulk deleteレコードの削除・一括削除
Record export / Comment exportレコード・コメントのファイル書き出し
Record import started / finishedレコードのファイル読み込み
Record file upload / download添付ファイルのアップロード・ダウンロード

削除、書き出し、読み込み、ファイルのアップロードとダウンロード。情報が外に出たり消えたりする操作が中心です。持ち出し調査には確かに役立ちます。

監査ログでも「見たこと」は分からない

そして、ここが本題につながります。公式ヘルプの監査ログ一覧に、レコードを閲覧した・詳細画面を開いたというアクションは含まれていません。一覧画面を表示しただけの操作も対象外です。

添付ファイルをダウンロードすれば残ります。CSVに書き出せば残ります。しかし、画面で読んだだけなら、どの履歴にも足跡は付きません。

kintone標準では「誰が読んだか」が残らない

3種類の履歴を並べると、抜けている部分がはっきりします。

知りたいこと標準で分かるか
誰が値を変えたか分かる(変更履歴)
誰が工程を進めたか分かる(ステータスの履歴)
誰が削除・書き出したか分かる(監査ログ・共通管理者のみ)
誰が読んだか分からない

これが問題になるのは、レコードを「伝達手段」として使っているときです。社内通達、規程の改定、朝礼連絡、クレーム情報の共有、マニュアルの周知。書いた側は「読んでもらえたか」を知りたいのに、kintoneは何も教えてくれません。

現場では、だいたい次のような工夫で乗り切ろうとします。

コメントに「確認しました」と書いてもらう。 一番手軽ですが、書き忘れが起きます。人数が多いとコメント欄が「確認しました」で埋まり、肝心のやり取りが埋もれます。コメント運用の勘所はコメント機能の使い方の記事にまとめました。

「確認済」チェックボックスを置く。 読んだ人がチェックする方式です。1人が担当するレコードなら成立しますが、全員分の既読を残すにはユーザーごとのフィールドが必要で、20人いれば破綻します。

通知の既読状態で判断する。 kintoneの通知の既読は、あくまで本人の画面上の状態です。発信者側が「誰が読んだか」を集計できるものではありません。

チェックの押し忘れを人に頼る運用は、結局「読みましたか」と聞いて回る作業に戻ります。記録するかどうかを人の判断に委ねている限り、抜けはなくなりません。

閲覧の履歴を自動で残す:既読チェック for kintone

そこで作ったのが既読チェック for kintoneです。レコードの詳細画面を開いた瞬間に、ログインユーザーを自動で既読記録するプラグインです。読む人は何も操作しません。

導入前と導入後で、サイドバーはこう変わります。

既読チェック導入前のkintoneレコード詳細画面 — サイドバーはコメントと変更履歴だけで、誰が読んだかは分からない

導入前は、サイドバーにコメントと変更履歴しかありません。誰が目を通したのかは、どこを探しても出てきません。

既読チェック導入後のkintoneレコード詳細画面 — サイドバーに「既読」タブが追加され、氏名・初回既読・最終既読・既読回数の一覧が表示される

導入後は、コメント・変更履歴と同じ並びに「既読」タブが増えます。押すと同じ場所に既読者の一覧が開き、氏名・初回既読・最終既読・既読回数を新しい順で確認できます。標準のタブと同じ場所・同じ見た目なので、使い方の説明がほとんど要りません。

既読と編集を分けて数える

閲覧の記録でつまずきやすいのが、編集操作との混同です。編集画面を開いたり保存したりするたびに既読回数が増えると、数字が実態から離れていきます。

そこで既読チェックでは、カウントを次のように分けています。

操作既読回数編集回数
詳細画面を開く+1変化なし
編集画面を開く/キャンセル変化なし変化なし
編集して保存変化なし+1

既読としてカウントするのは詳細画面での閲覧だけです。編集して保存した回数と最終編集日時は、別項目として同じパネルに表示します。「読んだ人」と「手を入れた人」を混ぜずに把握できます。

レコード本体を汚さない

既読情報をレコードのフィールドに書き込む作りにすると、既読を記録するたびにレコードが更新され、更新者と更新日時が書き換わり、変更履歴が既読記録で埋まります。ここまで見てきた変更履歴が、本来の目的で使えなくなってしまいます。

そのため既読チェックは、対象レコードには一切書き込みません。既読・編集のログは、同じスペース内に自動生成する「既読チェック管理」アプリへ分離して保存します。保管アプリは設定画面のボタンでワンクリック作成でき、同じスペースの複数アプリで1つを共有できます。

既読チェック for kintone の設定画面 — 保管アプリの自動作成ボタンと、既読ログ管理者(ユーザー・組織・グループ)の指定

設定するのは「保管アプリ」と「既読ログ管理者」の2つだけです。既読状況の閲覧は全員に開き、記録の編集・削除は指定した管理者だけに絞るアクセス権を自動で設定します。GASや外部サービスは使わずkintone内で完結し、ゲストスペースにも対応しています。

こんな使い方に向きます。

  • 社内通達・規程改定・朝礼連絡を、読んだかどうか聞かずに把握したい
  • クレームや事故情報を、関係者が目を通したか確認したい
  • マニュアルや手順書が、実際に参照されているかを知りたい

基本機能は無料です。製品ページからダウンロードできます。

目的別・履歴の使い分け

最後に、目的から逆引きできる形で整理します。

やりたいこと使うもの
値の変更を追う・戻すレコードの変更履歴(標準)
承認・工程の進みを追うステータスの履歴(標準)
削除や持ち出しを調べる監査ログ(共通管理者)
変更履歴を一覧・CSVで扱うクイック履歴ビュー
誰が読んだかを残す既読チェック
削除したレコードを復元する削除レコード復元

変更履歴は「戻す」ための機能で、削除されたレコードそのものを復元する機能ではありません。誤削除への備えはkintoneのバックアップの記事で別に扱っています。

まとめ

  • 変更履歴はレコード詳細画面の右側、コメント欄の[変更履歴]アイコンから確認する
  • 過去のバージョンに戻せるが、ステータス・作業者と編集権限のないフィールドは戻らない
  • バージョンの欠番は異常ではない(無変更保存、権限のないフィールドの変更など)
  • 変更履歴に保存期間の設定はなく、無効化すると既存の履歴が削除される
  • 変更履歴はCSVに書き出せず、取得用のREST APIも公開されていない
  • 監査ログは共通管理者のみ・保存期間6週間〜10年(初期値3年)・CSV出力可
  • どの履歴にも「誰が読んだか」は残らない。必要なら既読チェックで補う

履歴まわりは「あるはずだと思っていたものが無い」で計画が崩れやすい領域です。監査対応や周知の証跡が要件に入っている場合は、設計の早い段階でどこまで残るかを確認しておくと安全です。

自社の運用に合う形が判断しづらいときは、お問い合わせからご相談ください。無料で配布しているプラグインはプラグイン一覧にまとめています。

参考

← ブログ一覧に戻る