kintoneアプリ設定変更の落とし穴 - アールスリーインスティテュート

公開日：2025-12-25

メリークリスマス！システム開発グループの鈴木です！

1月から始まった「1年間、毎日ブログ記事を出し続ける」という企画も、いよいよ終わりが見えてきました。そこで今回は、アプリを作り終わった後の話――つまり「保守」について書きます。kintoneは業務に合わせてアプリをどんどん作り変えていける柔軟性が魅力ですが、その反面、本番運用中のアプリ設定を触るのはやっぱり怖いですよね。特に、プラグインやJavaScript、そして弊社のノーコードカスタマイズサービス「gusuku Customine（カスタマイン）」のような追加機能を載せていると、「これ、設定変えたらどこか壊れるんじゃ…」という不安が一気に現実味を帯びます。

ということで今回は、kintoneアプリの“基本機能部分”の設定を変更したときに、追加機能（JavaScript／プラグイン／カスタマイン）がどんな影響を受けうるのかを、変更の種類ごとに「危険度」として整理してみます。あまりクリスマスっぽい話題ではありませんが、もしクリスマスにkintoneアプリをプレゼントされて（？）1月から運用開始する方がいたら、ぜひ参考にしてください。

先に結論：設定変更は「小さく見えても」壊れるときは壊れます

まず大前提として、JavaScriptやカスタマインは、kintoneの設定情報（フィールドコード、選択肢、ステータス名、一覧名、権限など）を“目印”にして動いていることが多いです。目印が変わると、迷子になります。迷子になると、動かなくなったり、間違った動きをしたりします。

なので「この変更は軽微だから大丈夫」と決め打ちするより、「どこを目印にしている機能があるか」を確認してから変更するのが安全です。以下は、その判断を少しでもしやすくするための“危険度メモ”です。☆が多いほど危険だと思ってください。（評価は筆者の独断と経験に基づきます。）

危険度評価：変更の種類ごとに見ていく

1. フィールド構成の変更（追加：☆／既存フィールドの設定変更：☆☆☆／削除：☆☆☆）

フィールドを新しく追加するだけなら、基本的には影響が出にくいです。既存のカスタマイズが「そのフィールドの存在を前提にしている」ことは通常ないので、いきなり壊れる可能性は低めです。ただし、ここで油断しがちなのが、入力必須や重複禁止などの“制約”を追加するケースです。フィールドを追加した時には、まだ既存レコードにはそのフィールドの値が入っていません。もし入力必須にしてしまうと、既存レコードを更新しようとしたときに保存できなくなることがあります。運用中のアプリでこれが起きると、現場の体感としては「突然システムが壊れた」になります。クリスマスどころではありません。

新規フィールドで忘れることが多いのが権限設計です。フィールドをグループでまとめておき、グループに権限を付与する運用にしている場合は、新しいフィールドをそのグループに入れるだけで権限の抜け漏れが起きにくくなります。

一方で、既存フィールドの設定変更は危険度が一気に上がります。特に、フィールドコードの変更は基本的に「やってはいけない系」です。プラグインやJavaScript、カスタマインの設定は、フィールド名ではなくフィールドコードを参照していることが多く、フィールドコードを変えると対象を見失って機能が止まります。可能ならフィールドコードは変えず、見た目上の名称（フィールド名）だけ変更するのが安全です。

さらに選択系フィールド（ドロップダウン、ラジオ、チェックボックス、複数選択など）は、選択肢の扱いが落とし穴です。選択肢の“追加”は影響が出にくいことが多いのですが、既存の選択肢を変更・削除すると危険です。「○○が選ばれたら××する」という条件分岐が効かなくなったり、別アプリからデータをコピーする処理で「その選択肢が存在しない」ことでエラーになったりします。

フィールド削除も当然危険です。設定変更と同様、機能が動かなくなる可能性があるだけでなく、値が完全に消えます。念のためCSV書き出しなどでバックアップを取ってから消すのが安心です。

2. 一覧・グラフ設定（追加：☆／既存の設定変更：☆☆／削除：☆☆）

一覧やグラフの追加は、基本的に他機能への影響は出にくいです。ですが、増やしすぎると保守が地味にしんどくなります。たとえば「この一覧は誰が使うの？」「このグラフ、もう見てないよね？」が積み重なると、整理するタイミングが永遠に来ません。

既存の一覧・グラフの変更も、フィールドほど致命的ではないケースが多いです。ただし、一覧名を変えると「特定の一覧に自動遷移する」ようなカスタマイズをしていた場合に動かなくなることがあります。削除も同様で、参照している先がなくなるので、カスタマイズが失敗する可能性があります。つまり“一覧名や一覧そのものを、どこかで目印にしていないか”は一度疑っておくと安全です。

3. アクセス権（☆☆☆）

アクセス権は、変更の影響範囲が広いので危険度は高めです。特に権限を絞る方向の変更は要注意です。人が画面から触れなくなるだけでなく、他アプリからREST APIで参照・更新している処理にも影響が出ます。現場の感覚としては「昨日まで動いてた連携が止まった」になりがちで、原因が権限変更だと気づくまで時間がかかることがあります。

また、新しい人や組織に権限を付与する方向でも油断できません。「見えるようになった」こと自体は良いのですが、想定外の操作ができてしまう（あるいは逆に必要な操作ができない）という形で問題が出ることがあります。なので権限変更は、必ず“実際の利用者ロールでの動作確認”をしてから本番に入れるのがおすすめです。

4. プロセス管理（☆☆☆）

プロセス管理は、そもそも業務フローに直結するので、カスタマイズ有無に関わらず影響が大きい領域です。さらに、ステータス名を変更すると、そのステータス名を条件にしているカスタマイズが動かなくなる可能性があります。ステータス自動変更や一括承認のような仕組みをカスタマイズで作っていた場合、目印が変わった瞬間に止まります。
プロセス管理は“設定変更＝業務変更”になりやすいので、技術面の影響調査に加えて、運用面の合意形成もセットで考えるのが大事です。

5. 通知（追加：☆／既存の設定変更：☆／削除：☆）

通知は、基本的に他機能へ悪影響を出すことは少ないので危険度は低めです。むしろ怖いのは逆で、カスタマイズによって意図せず通知条件が満たされてしまい、通知が飛びまくるケースです。現場の方の受け止めは「なんか通知がうるさい」になり、最終的に通知が見られなくなる、という悲しい結末を迎えがちです。

通知は増やしすぎると価値が下がるので、本当に必要なものに絞るのがおすすめです。

余談：影響調査のやり方（“検索”が一番強い）

設定変更の影響調査で、私がまずやるのは「変更対象の名称で検索する」ことです。

JavaScriptなら、コードエディタでプロジェクト全体を開いて、変更前のフィールドコードや選択肢、ステータス名などで検索します。こうしておけば、どの処理がどの目印に依存しているかが見えます。

カスタマインの場合は、設定内容をExcelでダウンロードできる「ドキュメントを書き出し」機能が便利です。このExcelを開いて、変更前の名称（フィールドコード、選択肢、ステータス名など）で検索すると、「どこで使っているか」を洗い出しやすくなります。変更前にこれを一度出力しておくと、保守作業の安心感がかなり変わります。

まとめ：危険度は参考値。でも“確認してから変える”は絶対

今回は、kintoneアプリの基本設定を変更したときのリスクを、変更の種類ごとに危険度として整理してみました。フィールドコード変更や選択肢変更、アクセス権、プロセス管理などは、特にカスタマイズに影響が出やすいです。

ただし、ここまで書いておいてなんですが、最終的には「どんな小さな変更でも、カスタマイズとの兼ね合いで意図しない動作が起きる可能性はある」と思っています。だからこそ、影響がないかを“先に”調べてから変更する。これが保守の基本であり、いちばん効く安全策です。

年末はバタバタしがちですが、こういうときほど落ち着いて、変更前の棚卸しとテスト環境での検証を挟んでいきましょう。クリスマスの日に本番障害をプレゼントしないために！

（それでは、よいクリスマスを！）

投稿者プロフィール

すずき: kintoneがメインのエンジニアです。空き時間の半分を合気道に使います。