kintoneでJavaScriptを書いたらプラグインが邪魔した話｜困ったことと解決法をまとめる

はじめに

こんにちは。
業務改善エンジニアのこめまるです。

今回は、kintoneでJavaScriptカスタマイズを書いたときに、既存のプラグインが思った以上に邪魔をしてきた話をまとめます。

kintoneは手軽にカスタマイズできるのが魅力ですが、実際に触ってみると、

• 自分で書いたJSが効かない
• さっきまで動いていた処理が急におかしくなる
• console上ではエラーが見えにくい
• 原因が自作JSなのかプラグインなのか切り分けしづらい

ということがけっこう起こります。

特に、すでに何らかのプラグインが入っているアプリに後からJSを足す場合は、想像以上にハマりやすいです。

この記事はこんな人におすすめ

• kintoneでJavaScriptカスタマイズを書いている方
• 「JSを書いたのに動かない」「なんか変な挙動になる」で困ったことがある方
• プラグインとカスタマイズの競合を疑っている方
• 困ったときの切り分け方や解決の進め方を知りたい方

この記事では、実際に困りがちなポイントと、どうやって原因を切り分けて、どう解決していくかを整理して書いていきます。

先に結論

最初に結論を書くと、kintoneでJSがうまく動かないときは、自分のコード単体で考えないほうがよいです。

特に以下のような状況なら、プラグイン競合をかなり疑ったほうがよいです。

• 同じフィールドを触っている
• 同じ画面表示タイミングで処理している
• DOMを直接触る系のJSを書いている
• 入力制御系・表示制御系・一覧拡張系のプラグインが入っている

つまり、

「自作JSがバグっている」のではなく、
「プラグインと自作JSが同じ場所を触ってぶつかっている」

というケースが普通にあります。

なので、困ったときはまず

• プラグインを疑う
• 影響範囲を切り分ける
• DOM依存を減らす
• イベントやフィールド操作の責任を整理する

この順で見ていくと、かなり進めやすいです。

どういうときに起こりやすいか

kintoneで競合っぽい問題が起きやすいのは、だいたい以下のようなケースです。

1. 同じフィールドを複数の仕組みが触っている

たとえば、

• プラグインがフィールドの表示・非表示を制御している
• 自作JSでも同じフィールドを表示・非表示している
• プラグインが値を自動設定している
• 自作JSでも同じ値を書き換えている

といったケースです。

この状態になると、どちらが最後に効くのかという話になりやすく、見た目としては

• 一瞬表示されてすぐ消える
• 値が入ったと思ったら戻る
• 編集できるはずが編集できない

のような、かなり分かりづらい症状になります。

2. DOMを直接触っている

これはかなりハマりやすいです。

kintoneカスタマイズでは、つい

• 特定のclassを探して何かする
• ボタンの位置を変える
• 画面上の要素を直接隠す
• ラベルや並び順を見た目ベースでいじる

みたいなことをやりたくなります。

ただ、プラグイン側も同じようにDOMを触っていると、かなりぶつかりやすいです。

しかも、DOMを直接触る系は

• 画面構造の変化に弱い
• プラグインの描画後処理に弱い
• PC画面とモバイル画面で差が出やすい

という問題もあるので、競合の温床になりやすいです。

3. 一覧画面・詳細画面・編集画面で前提がズレる

同じアプリでも、

• 一覧
• 詳細
• 新規作成
• 編集

で画面の状態はかなり違います。

ここにプラグインも絡んでくると、たとえば

• 一覧では動くのに詳細では動かない
• 新規作成だけ変になる
• 編集画面だけ項目が消える

みたいなことが起きます。

このとき「たまたまその画面でバグる」のではなく、
その画面だけプラグインの影響が強く出ていることもあります。

実際に困ったこと

ここからは、実際に起きがちな「困ったこと」をパターンで書きます。

1. JSで値を入れても、あとから別の値に戻る

これはかなり典型です。

たとえば、自作JSであるフィールドに値をセットしたのに、画面を見ると別の値になっているケースです。

最初は「自分の代入処理が間違っているのかな」と思いがちですが、実際には

• プラグイン側でも同じフィールドを更新している
• 別イベントで後から上書きされている
• フィールドの自動計算や変換処理が入っている

ということがあります。

このときの見方

• どのフィールドが書き換わっているかを確認する
• そのフィールドを触るプラグインがないか見る
• イベント発火のたびに console.log() で値を追う

解決法

• 同じフィールドを複数箇所で更新しない
• 値設定の責任を「JS側」か「プラグイン側」どちらかに寄せる
• どうしても共存させるなら、対象フィールドを分ける

1つのフィールドに複数のロジックを集めすぎない
これだけでも、かなり事故が減ります。

2. 表示・非表示の制御が思った通りにならない

これも多いです。

たとえば、

• JSでは表示したはずなのに見えない
• 一瞬表示されるけど、あとで消える
• 条件によって出し分けたいのに固定される

というケースです。

このときは、表示制御系のプラグインが同じフィールドを触っていることが多いです。

解決法

• まず、そのフィールドの表示制御をプラグインが持っていないか確認する
• 表示制御はなるべく1箇所に寄せる
• JSとプラグインで分担するなら、対象フィールドを分ける
• DOMの display:none ではなく、可能な範囲でkintone側の正式な操作に寄せる

ここで大事なのは、

見た目を隠す処理 と kintoneとしての表示制御 は同じではない

ということです。

画面上で消えたように見えても、裏で状態がズレていると、後で別の不具合につながりやすいです。

3. ボタンや追加UIが出たり出なかったりする

自作JSでボタンやメッセージ領域を追加したときに、

• 出る画面と出ない画面がある
• リロードすると二重に出る
• 位置が崩れる
• プラグインのUIと重なる

ということがあります。

これは、DOM追加のタイミングや、再描画のされ方が影響していることが多いです。

解決法

• 同じ要素を何度も追加しないようにする
• 追加前に既存要素の存在確認をする
• 画面ごとのイベントを分けて考える
• DOMの特定classに強く依存しすぎない

たとえば、ボタン追加処理は「毎回追加」ではなく、
なければ作る くらいの作りにしておくと安定しやすいです。

4. プラグインを入れたら急に自作JSが効かなくなった

これは一番わかりやすい症状です。

「昨日までは動いていたのに、プラグインを入れたらダメになった」なら、かなり高確率で影響があります。

ただ、ここでありがちなのが、
プラグインが悪いのではなく、両方が同じ前提に立っているケースです。

つまり、

• どちらも同じ場所にUIを出そうとしている
• どちらも同じフィールドを必須/非必須っぽく扱っている
• どちらも同じイベントで動こうとしている

ということです。

解決法

この場合は、まず感情を捨てて切り分けます。

手順

1. プラグインを一時的に外して再確認する
2. 自作JSを外してプラグイン単体でも確認する
3. どちらを入れたときに崩れるかを見る
4. 影響が出る画面を特定する
5. 触っているフィールドとイベントを洗い出す

これをやるだけで、だいぶ前に進みます。

「とりあえずコードを直す」の前に、
何と何がぶつかっているかを見つける のが先です。

切り分けのやり方

ここはかなり重要なので、手順でまとめます。

1. まずはアプリを複製して検証する

本番アプリや利用中アプリでそのまま試すと、余計に見えづらくなります。

そのため、まずは複製したアプリで

• プラグインあり
• プラグインなし
• 自作JSあり
• 自作JSなし

を試せる状態を作るのがおすすめです。

これだけで、かなり冷静に見られます。

2. 何の画面で起きるかを固定する

「なんか変」と言っても、画面が違えば原因も違います。

なので、まずは以下を固定します。

• 一覧画面か
• 詳細画面か
• 新規作成画面か
• 編集画面か

この整理をしないまま見ると、話が散りやすいです。

3. 触っているフィールドを洗い出す

次に、

• 自作JSが触っているフィールド
• プラグインが触っていそうなフィールド

を一覧にします。

これをやると、かなり見えてきます。

特に、以下が重なっていたら要注意です。

• 表示制御対象
• 値の自動設定対象
• 必須っぽい扱いをしている項目
• 参照/計算に使っている項目

4. consoleでログを出す

シンプルですが強いです。

たとえば、

• イベントが本当に発火しているか
• その時点の値が何か
• どの分岐に入ったか

をログで出すだけでも、かなり状況が見えます。

console.log('編集画面表示イベント');
console.log('対象フィールドの値:', record.sample_field.value);

こういうログを、要所だけでも入れておくと、
「そもそも自分のJSが動いていないのか」「動いたあとで壊されているのか」が分かりやすくなります。

解決の考え方

ここからは、私が実際に「こう考えると直しやすい」と感じたポイントです。

1. 役割を分ける

一番大事なのはこれです。

• 表示制御はどっちが担当するか
• 値設定はどっちが担当するか
• UI追加はどっちが担当するか

を曖昧にしないことです。

プラグインと自作JSが共存するときは、
同じ責務を両方に持たせないのが基本です。

2. DOM操作を減らす

kintoneでは、見た目を直接いじるより、
まずは「正式に触れる範囲」で解決できないか考えたほうが安定します。

DOM直操作が必要な場面もありますが、
それをやるほどプラグインとの競合確率は上がる印象です。

なので、

• まずはレコード値ベースで解決できないか
• フィールド制御で済まないか
• UI追加だけで済まないか

を先に考えるのがおすすめです。

3. スマートに直そうとしすぎない

競合を見つけたとき、つい「うまく順番調整して両方動かせないか」と考えがちです。

もちろんそれで解決できることもありますが、
保守を考えると、けっこう危ないです。

なぜなら、後で

• プラグイン設定変更
• 別のカスタマイズ追加
• kintone画面差分
• 他担当者の改修

でまた崩れやすいからです。

そのため、個人的には

無理に共存させるより、責務を整理して片方に寄せる

ほうが結果的に安定しやすいと感じています。

4. 「便利そうだからプラグイン追加」を少し慎重にする

これは少し運用寄りの話です。

kintoneは便利なプラグインが多いので、つい足したくなります。
ただ、あとから自作JSを積んでいく前提なら、

• このプラグインは何を触るのか
• 画面制御に入るのか
• 値更新に入るのか
• 今後の拡張とぶつからないか

は意識したほうがよいです。

特に、見た目も値もイベントも触る系のプラグインは便利な反面、競合しやすい印象があります。

困ったときの進め方まとめ

最後に、私ならこう進める、という流れをまとめます。

困ったときの進め方

1. まずプラグイン競合を疑う
2. アプリ複製で再現環境を作る
3. どの画面で起きるか固定する
4. 触っているフィールドを洗い出す
5. 自作JS単体 / プラグイン単体 / 両方で比較する
6. consoleログで「動いていない」のか「後で壊される」のかを切り分ける
7. 最終的には責務を分けて設計し直す

まとめ

kintoneでJavaScriptを書いたときにハマる原因は、必ずしも「自分のコードミス」だけではありません。

特に、既存プラグインが入っているアプリでは、

• 同じフィールドを触る
• 同じ画面タイミングで処理する
• DOMを直接いじる
• UI制御と値制御が重なる

といった条件が重なることで、かなり分かりづらい不具合になります。

ただ、見方を整理すると、対処しやすくなります。

• まず競合を疑う
• 切り分ける
• 役割を分ける
• 無理な共存を減らす

このあたりを意識するだけでも、だいぶ楽になります。

同じように「kintoneでJSを書いたら、なんかプラグインとぶつかってしんどい……」となっている方の参考になればうれしいです。