kintone のアクセス権が広げられたとき、誰が気づくのか
2026年10月5日
先に、この記事だけ結論が違うことを書いておきます。 当サイトの他の記事では「kintone 側に痕跡が残らない」話をしてきましたが、 アプリ設定の変更は監査ログに残ります。 残らないのではありません。問題は別のところにあります。
残ることは、残る
cybozu.com には監査ログがあり、公式ヘルプによれば次が記録されます。
- 操作を行ったユーザーのログイン名
- 操作を行ったサービスの名称
- 機能の名称や種別
- ユーザーが行った操作
- 操作の結果
「操作の結果、変更された設定値」が出力される場合があるとも書かれています。 つまり「誰がアクセス権を変えたか」は、調べれば分かります。 レコードコメントの削除とはここが違います。
では何が問題なのか
3つあります。どれも仕様の欠陥ではなく、監査ログという仕組みの性質です。
- 見られるのは cybozu.com 共通管理者だけ
- 公式ヘルプの対象読者は「cybozu.com共通管理者」です。 アプリ管理者や現場の担当者は、自分のアプリの設定がいつ誰に変えられたかを 自分では確認できません。
- 誰も毎日は見ていない
- これは kintone の問題ではなく運用の問題です。 監査ログは「何かあったときに調べるもの」であって、 毎朝めくるものではありません。 見に行くきっかけがなければ、変更は起きたまま放置されます。 そして、アクセス権が広がったことに気づくきっかけは、たいてい事故です。
- 6週間を超えると、ひと手間かかる
- 公式ヘルプは「6週間未満の監査ログを閲覧する手順」と 「6週間以上前の監査ログをダウンロードする」を分けて説明しています。 古い変更を追うには、まずダウンロードする必要があります。
そして、記録があっても元には戻らない
ここが核心です。公式ヘルプには「操作の結果、変更された設定値」の記載はありますが、 変更前の値についての記載はありません。
仮に「10月1日に、担当者Aがアプリ12のレコードのアクセス権を変更した」と分かったとして、 それだけでは元に戻せません。 戻すには「変更前にどういう設定だったか」が要るからです。 記録があることと、元に戻せることは別の問題です。
これは復元全般に共通する構造です。 レコードでも、コメントでも、設定でも、 「前の状態を別の場所に持っている」以外に戻す方法はありません。
アプリ設定は1か所にない
もうひとつ、実装してみて分かったことがあります。 「アプリの設定」は17か所に散らばっています。 当社が毎日取得しているエンドポイントは次のとおりです。
/k/v1/app.json アプリ基本情報
/k/v1/app/settings.json 一般設定
/k/v1/app/form/fields.json フィールド定義
/k/v1/app/form/layout.json フォームレイアウト
/k/v1/app/views.json 一覧
/k/v1/app/status.json プロセス管理
/k/v1/app/actions.json アプリアクション
/k/v1/app/reports.json グラフ
/k/v1/app/notifications/general.json 条件通知
/k/v1/app/notifications/perRecord.json レコード条件通知
/k/v1/app/notifications/reminder.json リマインダー通知
/k/v1/app/acl.json アプリのアクセス権
/k/v1/record/acl.json レコードのアクセス権
/k/v1/field/acl.json フィールドのアクセス権
/k/v1/app/customize.json JavaScript / CSS カスタマイズ
/k/v1/app/plugins.json プラグイン
/k/v1/app/adminNotes.json 管理者メモアクセス権だけで3本あります（アプリ・レコード・フィールド）。 「アクセス権を確認した」と言うとき、この3つ全部を見ているかどうかで意味が変わります。 フィールド単位のアクセス権は、見落とされやすい場所です。
レコードだけ戻しても、業務は戻らない
設定を世代として持っている理由はもうひとつあります。 フィールド定義が変わっていると、レコードを戻しても入りません。
フィールドを削除してから1週間後に「やっぱり戻したい」となった場合、 必要なのはレコードだけではなくフィールド定義のほうです。 当社はレコードと設定を同じ世代で保持しているので、 「このレコードが入っていた時点のフォーム定義」を同時に取り出せます。
当社がやっていること
- 上の17エンドポイントを毎日取得し、レコードと同じ世代に入れる
- 前の世代と突き合わせ、どのエンドポイントが変わったかを名指しで出す
- 消失系（アクセス権の変更・フィールドの削除など）が出た日だけ通知する
- 取れなかった設定は握り潰さず、理由つきで記録する。 権限不足やプランの都合で取得できないエンドポイントがあるためです。 「取れなかった」と「変わっていない」を混ぜません
3番目について補足します。差分が出た日だけ通知するのが既定ですが、 それだけだと「バックアップが死んで無音になった」のと「平穏だった」が区別できません。 そのため週に1度、何も起きなかった週も「生きている」と報告する設定を用意しています。
自社の状況を確かめる
当社では、導入前に読み取り専用で実測しています。 アプリ数・レコード総数・添付の総容量・コメントが溜まっているアプリと件数をお返しします。 書き込みは一切行いません。所要は10分ほどです。
監査ログに関する記述は サイボウズ公式ヘルプ の記載に基づいています（2026年10月時点）。 「変更前の値」については公式ヘルプに記載が見当たらない、という意味で書いており、 記録されないと断定するものではありません。仕様は変更される可能性があります。 誤りを見つけた場合は hello@tokimodoshi.com までご連絡ください。訂正します。 関連記事: 削除しても痕跡が残らない件 ／ 復元しても元どおりにならない件 ／ API リクエスト枠の話 ／ 容量と原価の話