kintoneのアプリ設定の変更履歴を残す方法 ― 変更を承認制にしてガバナンス・監査に対応（無料）

こんな方におすすめ

• kintoneのアプリ設定の変更履歴(誰が・いつ・何を・なぜ変えたか)を残したい
• アプリの設定変更を、上長や情報システム担当の承認を経てから行う運用にしたい
• アプリ管理者を少人数に絞り、現場からは「依頼」だけを受け付けたい(kintoneのガバナンス)
• 監査・内部統制・情報セキュリティの規程で、システムの設定変更の記録や承認の証跡を求められている
• チャットや口頭での設定変更の依頼が多く、対応漏れや設定ミスが心配
• 「kintone アプリ設定 変更履歴」「kintone 設定変更 承認」「kintone ガバナンス」「kintone 監査」を探している

なぜアプリ設定の変更履歴が必要になるのか

kintoneでは、アプリ管理権限を持つ人なら誰でも、フィールドの追加・必須化・選択肢の変更・一覧の作成などを その場で行えます。立ち上げ期にはこの手軽さが強みですが、アプリが業務の基幹になってくると、次のような困りごとが出てきます。

• 経緯が追えない: 「この項目が必須になったのはいつから?」「選択肢『解約』は誰が追加した?」に答えられない。
• 勝手な変更・設定ミス: アプリ管理者が増えると、相談なしの変更や、他の業務に影響する変更(フィールドの削除・コード変更)が起きる。
• 監査・内部統制で説明できない: システムの設定変更について「承認を経て行ったか」「記録はあるか」を求められても、根拠を出せない。
• 依頼が散らばる: チャット・メール・口頭で来る依頼の対応状況を、アプリ管理者が個人で抱えてしまう。

解決の方向性は、「設定変更は必ず依頼として記録し、承認されたものだけを反映する」という 変更管理(チェンジマネジメント)の仕組みを、kintoneの中に用意することです。

kintone標準機能ではどこまでできるか

• アプリ管理権限の限定: アプリのアクセス権で、設定を変更できる人を絞ることはできます。ただし、変更の「依頼」や「承認」の仕組みはありません。
• 動作テスト環境(アプリの更新前のプレビュー): 設定を変えてから「アプリを更新」するまでの間に動作を確認できますが、誰かに承認してもらう機能ではありません。
• 操作の記録: 監査ログなどで「設定が変更された」という操作を後から確認できる場合はありますが、なぜ変えたのか(依頼理由)・誰が承認したのか・変更前と変更後を、業務の記録として残すものではありません。
• 依頼用のアプリ+プロセス管理: 「設定変更依頼」アプリを作り、プロセス管理で承認フローを組むことは標準機能でできます。ただし、承認後にアプリ管理者が手作業で設定を変える必要があり、依頼内容と実際の設定がずれたり、作業を忘れたりするリスクが残ります。

つまり、標準機能だけでも「依頼と承認の記録」までは作れますが、承認された内容をそのまま確実に反映する部分が手作業になります。 ここをREST APIで自動化するのが、この記事で紹介する方法です。

JavaScript自作・他社プラグインとの比較、なぜGovAppsプラグインか

アプリ設定変更依頼プラグインは無料・広告なしで、 ソースコードをGitHubで全公開 しています。他のアプリの設定を書き換えるプラグインだからこそ、処理の中身を誰でも確認できること、 セキュリティレビューのチェックリストを公開していることを重視しています。 主な設計は次のとおりです。

• 承認者自身の権限で反映: APIトークンやパスワードを一切保存せず、完了にするアクションを実行した人の権限で反映します。対象アプリの管理権限が無ければエラーになり、ステータスは変わりません(プラグインで権限が広がることはありません)。
• 見た内容=反映される内容: 承認時に変更内容の確認ダイアログを出し、反映の直前に依頼レコードを取り直して、承認者が見ている内容と一致するかを確認します。
• 他人の作業途中の変更を巻き込まない: 対象アプリにまだ「アプリを更新」していない変更がある場合は中止します。アプリの更新に失敗したら変更を取り消します。
• 外部通信なし: kintone自身のREST APIだけを使い、外部サーバーへの通信や外部ライブラリはありません。

プラグインでの実現方法

今回は、変更対象のアプリとして「契約管理」(契約名・契約先・契約金額・契約区分)を用意し、 別に「アプリ設定変更依頼」アプリを作ってアプリ設定変更依頼プラグインを追加しました。

1. 依頼用のアプリを作り、プラグインを追加して設定画面で「保存」を押す
   依頼に必要なフィールド(対象アプリ・対象フィールド・変更内容・依頼理由・反映結果・反映日時など)と依頼の入力欄が自動で作成され、 プロセス管理(未申請 →[申請する]→ 承認待ち →[承認する]→ 完了)がONになります。手動でのフィールド作成は不要です。
2. プロセス管理の承認経路(作業者)を設定する
   「承認待ち」の作業者を、アプリ管理者や情報システム担当にします。承認する人には、変更対象アプリのアプリ管理権限が必要です。 承認後に依頼内容を書き換えられないよう、レコードのアクセス権もあわせて設定しておくと安心です。

3. 依頼者がレコードを追加して依頼する
   対象アプリをアプリ名で検索し、フィールドを「フィールド名(フィールドコード)」で選び、変更内容を選びます。 選べる変更内容は、フィールドの種類に合わせて自動で絞り込まれ、現在の設定も表示されます。今回は「契約名を必須にする」依頼を、依頼理由つきで作成しました。

4. 一覧の作成も依頼できる
   「こういう一覧がほしい」という依頼は、対象アプリの一覧画面で絞り込み・並べ替えをして、そのURLを貼り付けて「変換」を押すだけです。 URLの条件が、フィールドコードの絞り込み条件・並び順に変換されます。

実行結果: 承認すると対象アプリに自動で反映され、変更履歴が残る

依頼者が「申請する」を実行し、承認者が「承認する」を押すと、変更内容の確認ダイアログが表示されます。 「反映する」を押すと、承認者の権限で対象アプリの管理権限を確認したうえで設定を変更し、アプリの更新(運用環境への反映)まで自動で行われます。

反映が終わるとステータスが「完了」になり、依頼レコードに反映結果(変更前・変更後)と反映日時が記録されます。 対象アプリを開くと、「契約名」が必須項目になり、別の依頼で追加した契約区分「解約」も選べるようになっていました。

依頼アプリに「変更履歴」という一覧を作っておくと、アプリ設定の変更履歴(変更管理台帳)として、 どのアプリの・何を・誰の依頼で・なぜ変えたか、承認済みか(ステータス)・いつ反映されたかを一覧で確認できます。 監査で設定変更の経緯を聞かれたときも、この一覧を絞り込んだりCSVに書き出したりして答えられます。 ステータスの履歴から、誰が承認したかも確認できます。

あわせて確認したいポイント

• 承認経路を必ず設定する: プロセス管理で作業者を設定していないステータスでは、レコードを閲覧できる全員がアクションを実行できてしまいます(kintoneの仕様)。
• 承認者にはアプリ管理権限が必要: 反映は承認者の権限で行います。権限が無い場合はエラーになり、ステータスは変わりません。
• 選択肢の名前変更・削除の影響: 名前の変更は、既存レコードの値や一覧・グラフの絞り込み条件も新しい名前に変わります。削除した選択肢は既存レコードに値として残ります(依頼画面と確認ダイアログで警告します)。
• フィールドコードの変更・削除は影響が大きい: そのフィールドを使っているJavaScript・プラグイン・計算式・一覧の条件に影響します。
• 対象外の設定: 計算式・ルックアップ・関連レコード一覧・アクセス権・プロセス管理の設定などは、このプラグインでは変更できません。

対応するプラグイン

あわせて見たい記事・解決策ページ

あわせて検討したいkintone関連サービス

by 合同会社Pons kintoneオフィシャルパートナー