kintoneのフィールド削除前に確認すること｜影響調査とチェックリスト
更新日：9月27日
無料ツールで設定の確認を始める
まず1つのアプリ内でフィールドの参照先を調べたい場合は、無料のフィールド使用状況チェッカーから始められます。フィールド使用箇所の確認手順と検出対象で、導入から結果の読み方まで確認してください。「未検出」は削除して安全という意味ではなく、外部連携や実際の業務での使用は別途確認します。
対象フィールドが承認フローで使われている場合は、プロセス管理の実行条件と作業者の確認ガイドも役立ちます。変更前の条件を記録してから、変更後の操作をテストしましょう。
「この項目、最近は誰も入力していないし、消してもよさそう。」
kintoneのアプリを整理するとき、使われていないように見えるフィールドが気になることがあります。ただ、画面で目立たない項目でも、月末の集計や外部サービスへの連携に使われているかもしれません。
変更前に確かめたいのは、入力されているかだけでなく、どこから参照され、何の業務を支えているかです。今回は、フィールドの削除や変更を検討するときの確認ポイントを整理します。
1．まず「何を変えるのか」を分ける
「項目を整理したい」という要望には、表示名を分かりやすくする、一覧から外す、フィールド自体を削除するなど、異なる変更が含まれます。目的に合った変更を選びましょう。
変更したいこと | 最初に確認すること |
表示名を変える | 利用者の操作説明や帳票との表記が一致するか |
一覧の表示項目から外す | その一覧で確認・判断する業務に支障がないか |
フィールドコードを変える | 計算式、カスタマイズ、外部連携で参照していないか |
フィールドを削除する | 保存データと参照元への影響を確認できているか |
例えば「一覧が横に長くて見づらい」なら、まずは一覧の表示項目を見直す方法を検討できます。データそのものをなくす必要があるのか、目的に立ち返ることが大切です。
2．削除すると、その項目のデータも失われる
フィールドの削除は、入力欄だけを消す操作ではありません。kintone公式ヘルプでは、フィールドを削除すると、そのフィールドに登録されたデータも削除されると案内されています。グループやテーブルの削除では、内部のフィールドとデータにも影響します。詳しくは「フィールドを削除する」を確認してください。
また、削除したフィールドとデータは復旧できません。削除前に書き出したCSVがある場合は、フィールドの追加とCSVの読み込みによってデータを再登録する方法がありますが、元の設定や連携まで自動的に戻るわけではありません。公式ヘルプ「誤って削除したフィールドを復旧できますか？」も事前に確認しておきましょう。
「今は入力していない」項目でも、過去の集計や問い合わせ対応に必要な履歴が残っていることがあります。必要な保存期間や参照用途を、業務担当者に確認します。
3．アプリの内側と外側、両方の参照元を調べる
対象のフィールド名とフィールドコードを控えたら、確認先を3つに分けると整理しやすくなります。
同じアプリの設定：計算式、一覧、グラフ、通知、アクセス権、プロセス管理など
ほかのアプリ：ルックアップ、関連レコード一覧、アプリアクションなど
カスタマイズ・外部連携：JavaScript、プラグイン、帳票出力、データ連携など
kintoneには、特定の設定で参照されているフィールドの削除を制限する仕組みがあります。ただし、それだけで外部のプログラムや業務上の用途まで確認できたと判断しないようにしましょう。
フィールドコードは、計算式やAPIでフィールドを指定するための文字列です。コード変更時に計算式内の参照が自動で変わる場合でも、外部のコードやサービスの設定まで追従するとは限りません。公式ヘルプ「フィールドコードとは」を確認し、連携先は個別に調べます。
確認メモの例
対象 | 確認内容 |
案件管理の「旧顧客番号」 | 通常入力では未使用。過去データの照合で使っていないか確認 |
月次帳票 | 帳票テンプレートと出力処理を担当者が確認 |
外部連携 | フィールドコードで検索し、取得・更新処理を確認 |
判断 | 未確認の参照先がある間は削除を保留 |
※上記は架空の例です。検索して見つからなかった場合も、検索対象に含めていないファイルや管理画面がないか確認します。
4．テストと「戻すための準備」を先に決める
影響先が分かったら、変更内容、確認方法、作業日時、担当者を決めます。テスト用の環境・データで、普段の操作から連携先の処理まで一連の流れを確かめましょう。
新規登録・編集・検索・一覧表示が想定どおりか
計算・通知・承認などの結果が変わっていないか
帳票の出力や外部連携が最後まで完了するか
管理者以外の利用者でも、必要な操作ができるか
月末処理など、普段は動かない処理を確認したか
設定の記録、必要なデータの保管、カスタマイズの変更前ファイルをそろえ、「問題が出たら誰が何を戻すか」も決めておきます。CSVだけでアプリ全体を元どおりにできると考えず、対象データと設定に合った復旧方法を確認してください。
変更を進める順序
① 目的と変更内容を明確にする |
↓ |
② 参照元と業務への影響を確認する |
↓ 不明な点があれば確認・保留 |
③ データ保管・復旧準備・テストを行う |
↓ |
④ 関係者と合意して本番へ反映する |
↓ |
⑤ 通常業務と定期処理の結果を確認する |
5．変更の理由を、次の担当者にも残す
変更が終わったら、対象フィールド、変更理由、確認した参照先、実施日、担当者を記録します。今回は削除を見送った場合も、「何が未確認で、誰に確認するか」を残しておくと、次の見直しにつながります。
6．コピーして使えるフィールド変更の確認記録
対象フィールドごとに、次の項目をコピーして記入します。確認結果は「確認済み・未確認・対象外」に分け、根拠となる設定画面や資料の場所も残しましょう。
対象：アプリ名・URL／フィールド名／フィールドコード
変更内容と理由：何を変え、どの業務上の問題を解決するか
参照元：同じアプリ／ほかのアプリ／カスタマイズ・外部連携
確認結果：確認状況／根拠となる資料／確認者／確認日
保管と復旧準備：必要なデータ／設定・ファイルの保管先／復旧手順
テスト：通常操作／権限別の操作／月末などの定期処理／結果
未確認事項：確認先／担当者／確認期限
最終判断：実施・保留／判断理由／合意した担当者／実施予定日
「参照が見つからない」と「業務で使っていない」は分けて記録します。調査対象に含まれていない連携や、担当者への確認が残る場合は、未確認事項として扱います。
7．AppInsightを影響調査の下準備に使う
アプリやフィールドが多く、参照関係の洗い出しに時間がかかる場合は、Nest Recのkintoneアプリ構成・依存関係の解析ツール「AppInsight」を調査の下準備に活用できます。
対象アプリの構成と依存関係を解析し、変更したいフィールドの参照元を確認する。
検出された参照を手がかりに、設定やカスタマイズの該当箇所を調べる。
業務担当者への確認、外部連携の調査、テスト結果を上の確認記録にまとめる。
解析結果だけで「削除して安全」と判断することはできません。動的な参照、外部JavaScriptファイル、プラグイン内部など、検出できない参照があり得ます。利用状況も確認対象の期間・データの範囲に限られるため、過去の履歴や年次処理の必要性は別途確認してください。
まとめ：削除前に確認結果と判断理由をそろえる
変更前の最終チェック
整理の目的と、変更する範囲が明確になっている
過去データを残す必要性を確認した
アプリ内・ほかのアプリ・外部連携の参照元を調べた
必要なデータの保管と復旧手順を確認した
通常操作と定期処理のテストを行った
関係者への連絡と変更履歴の記録方法が決まっている
フィールドの整理は、項目数を減らすだけでなく、業務とアプリの関係を見直す機会にもなります。まずは1項目を選び、「なぜ作ったのか」「どこで使うのか」を確かめるところから始めてみてください。
担当者の交代に備えて情報を残す方法は、前回の記事「kintone担当者の引き継ぎ、何を残せばいい？」でも紹介しています。
コメント