【質問】外部監査（IT統制）で、kintoneの変更管理ってどこまでやっていますか？
こんにちは。
社内のkintone管理を担当している古内です。
■ ご契約中のコース
スタンダードコース
■ お悩みの背景・目的
会社でIT統制の監査を受けることになり、kintoneの「設定変更の管理（誰が・なぜ・誰の承認で変えたか）」を見直しています。
現場の担当者も一覧や項目をちょこちょこ変えるので、統制と使いやすさのバランスに悩んでいます。
■ 試してみたこと
最初は、アプリ設定の「設定変更の履歴」で足りるかと思ったのですが、確認してみると次の点で足りませんでした。
・「誰が・何を変えたか」は分かるが、「なぜ変えたか」「誰が承認したか」は残らない
・表示できる件数に上限があり、変更の多いアプリは古い履歴が見られなくなっていた
・「変更を中止」した操作は履歴に残らない
そこで、
・変更申請アプリを作り、「変更前に申請 → 作業者以外が承認 → テスト → 本番反映」で運用を開始
・入力は選択式にして、なるべく手間を減らした
としてみましたが、一覧の追加などちょっとした変更まで毎回申請するのは、かなり負担になっています。
■ 譲れない条件
・監査で説明できる記録は残したい
・現場が自分でアプリを直せる、kintoneの良さはなるべく残したい
■ 教えていただきたいこと
・設定変更の承認や記録、どうしていますか？（例：申請アプリ／チャットで承認／Excelの台帳／標準の履歴だけ／特にしていない）
・軽い変更（一覧の追加・並び替えなど）も対象にしていますか？
「うちは標準の履歴で説明できた」「チャットでOKだった」「こういう指摘を受けた」など、一言だけでもとても助かります。
よろしくお願いします！
2026/09/30 14:14
6件のコメント
(新着順)
ミュートしたユーザーの投稿です。
投稿を表示先日質問させていただいた件、監査が無事に終わりましたのでご報告です。
シマさん、ポン酢さん、Pierretakechanさん、Seal777さん、ご回答ありがとうございました。
監査では、前期に回答していた内容の確認が中心で、変更管理について細かく指摘されることはありませんでした。
ただ、いただいたご意見をもとに運用を見直し、次のように変えることにしました。
■ 変更の種類で分けることにしました
・一覧の追加、項目の追加など、見た目や入力欄を増やすだけの変更
→ 専用のチャットスペースに「アプリ名／何を変えたか／理由」を報告するだけ。情報システム部が確認して「済み」のリアクションを付ける
・計算式、アクセス権、プロセス管理、プラグインなど、アプリの動きや権限が変わる変更
→ これまでどおり申請アプリで申請し、承認を受けてから変更
■ 目的は「誰が・何を・なぜ変更したか」を共有すること
Seal777さんの「理由の記録は後任への引き継ぎのため」というお話がとても腑に落ちて、承認の重さより、記録を残して共有することを優先しました。
アプリの変更で運用が変わるときは、利用している現場への周知も忘れずに、とあわせて伝えています。
■ ガバナンスはこれから
親会社でもガバナンス設計を進める予定があるので、今後はそちらに合わせていく方向です。
それまでの間は、Pierretakechanさんに教えていただいた6項目（推進体制・教育・運用ルール・開発ルール・プラグイン・異動時対応）を枠組みにして、自社の現状を整理しておき、親会社のルールが決まったときにすり合わせられるようにしておくつもりです。
みなさんのおかげで、一人で悩んでいたら出てこなかった形にたどり着けました。
本当にありがとうございました。
ミュートしたユーザーの投稿です。
投稿を表示ご返信いただき、有り難うございます。
私からの返信が遅くなり、申し訳なく存じます。
ガバナンスに関して、
合併前後では、まるで真逆になっているのが実情です。
【合併前】
ガバナンスの策定と制定は、合併前の親会社が行い、
それを子会社等のグループ企業が踏襲するという形でした。
ガバナンスは、PowerPointにまとめられ、項目としては、
・推進体制
親会社の本部、親会社の各部署とグループ企業の管理者の選任や
月１回のミーティング開催によって推進する。
・教育制度
アプリ作成する前にサイボウズ社の動画等を視聴することの義務付け
・運用ルール
利用者、アプリ管理者、kintoneシステム管理者の申請や
kintoneで扱えるデータの種類（機密性情報等)
・アプリ開発におけるルール
開発時、運用時のスペースに関するルール、スペース・アプリの命名ルール、
スペース・アプリの管理者に関するルール
・プラグイン・連携サービス
使用できるプラグイン・連携サービスの周知
・異動時対応
異動時の注意点、実施すべき事柄の取り決め
当時のガバナンスは、「不磨の大典」ではなく、適宜見直しを行い、
完成を目指すというものでした。
【合併後】
親会社（合併前の親会社とは異なります）は、ガバナンスを制定している思われますが、
弊社には、親会社からおりてきておりませんし、自主制定されておらず、
ガバナンス不在となっているのが実情です。
現在、市民開発が進んでいない状況であるので、「不幸中の幸い」ですが、
市民開発が進むと、私は、「目も当てられない」状況になるのではと危惧しております。
私は、とても遺憾であります。
私は、利用者として、合併前の方が、ストレスなく利用できておりました。
ご参考になりますでしょうか。
ミュートしたユーザーの投稿です。
投稿を表示監査で踏み込んだ変更履歴の記録が求められるのは、御社のためであって
・「誰が承認したか」→「業務遂行に必要なアプリが好き勝手にイジられてないか（←然るべき承認等を経ているか。ひいては、業務停滞のリスクを排除できてるか。）」のチェック
・「なぜ変えたか」→「そのアプリの設計思想が正しくかつ容易に後任に引き継げる状態になっているか」のチェック
ということだと思います。
もっとも前者は、他の方の仰る通り、変更のレベルなどによって申請⇔申請不要を切り替え、「このポリシーでやってます」旨、監査法人に説明すれば十分通るのでは？と考えます。
重要なのは後者で、「変更理由は、些細なものまで記録しておいた方がよい」と小生は考えます。
で、逆に些細な変更は変更内容／理由は一定の表現に絞り込めると思いますので、記録アプリに選択式フィールドを配置して、ポチポチ（自由記述一切ナシが理想）からの保存はやってもらう→カテゴライズされた変更内容（≠理由）をキーにしてそういったものは未申請カウントには入れない などとやるのはいかがでしょうか？
監査されるようなアプリを作ったことがなく、私見なので捨て置いて結構です。
ミュートしたユーザーの投稿です。
投稿を表示私は、グループ会社の会社合併で
2026年4月1日付けで消滅会社から存続会社に転籍した者となります。
kintoneに関しては、
それぞれの親会社の環境（サブドメイン）下での利用となりますが、
グループ会社であっても親会社が異なることで、運用が随分と異なります。
私自身の立場も、以前はcybozu.com共通管理者でしたが、現在は、１ユーザーです。
偉そうなことを申し上げるようで、大変に失礼ですが、
変更管理以前に、貴社のkintoneに係るガバナンスはいかようになられているのでしょうか。
構築中ということなのでしょうか。
IT統制にとっても、ガバナンスありきのように、私は考えてしまいます。
いかがでしょうか。
ミュートしたユーザーの投稿です。
投稿を表示活用が進むと突き当たる問題で、正解がなく難しいですよね。
まず大事なことは、何を守るかという点を明確にすることではないかなと思います。
・フィールドの追加・修正・削除
・一覧やグラフの追加・修正・削除
・アクセス権の修正
・通知の修正
・カスタマイズやプラグイン設定の修正
それぞれ違ったリスクがあり、リスクをどれだけ許容するのかというのは組織によって変わってきます。ここが整理ができていることを示すのは監査においてとても重要な部分となります。
kintoneは細かい開発権限の設定ができませんので、本格的にやろうとすると外部サービスの利用が必要となったりします。外部サービスが必要になった時の予算獲得にも必要な情報となるかなと思います。
ミュートしたユーザーの投稿です。
投稿を表示こんにちは！
弊社はkintone作成・変更・削除については申請をもらって作業していますが、軽微な変更（ドロップダウンの項目追加など）は申請は不要でアプリの主管している部署がOKであれば変更しています。
ただ、権限の変更などについては申請をもらっています。
市民開発は最近はじめたので本番運用までいってませんが、今のところ主管している部署がOKであれば申請は不要としてます。