目次
kintoneを長く使っていると、入力漏れや不整合といったデータの不備が少しずつたまっていきます。そこで考えられるのが、既存データを機械的にチェックして不備を洗い出す監査スクリプトです。
ただ、作れば終わりではありません。私たちがkintoneの実案件（匿名）で監査スクリプトを作ったところ、初版の検知結果は約8割が誤検知でした。不備として挙がったものの大半が、実は直す必要のないデータだったのです。
この記事では、誤検知が多くなった原因と、条件を詰めて運用に乗せるまでの手順、検知後の是正で守っている原則を整理します。
この記事の結論
- 監査は検知率より先に誤検知を潰す
- 誤検知は検知結果の目視分類で条件を絞って減らす
- 是正は一括更新せず、行ごとに正解値と突き合わせる
kintoneのデータ監査スクリプトとは
ここでいうデータ監査スクリプトは、kintoneのアプリに蓄積された既存レコードを条件でチェックし、「本来入っているべき値が空」「組み合わせが矛盾している」といった不備の候補を一覧にする仕組みです。
人が1件ずつ見て回るのは現実的ではないため、機械で候補を拾い、人が確認して直す——という分担になります。つまり監査の価値は、人が確認する時間をどれだけ無駄にしないかで決まります。
初版で誤検知が約8割になった原因
初版の条件は「この項目が空なら不備」のような、素直な書き方でした。ところが実際のデータには、空であっても問題ないレコードが大量に含まれていました。原因は大きく3つです。
| 誤検知の原因 | 何が起きたか |
|---|---|
| 下書きのレコード | 入力途中のものまで不備として拾った |
| 対象外のステータス | 監査の対象外の段階にあるレコードも含めていた |
| 意図的な空欄 | 業務上あえて空にしている項目を漏れと判定した |
どれも、データとしては空欄や未入力に見えます。しかし業務の文脈では正しい状態です。条件がデータの見た目だけで書かれていたことが、誤検知の根本原因でした。
誤検知を減らす条件の詰め方
誤検知は、机上で条件を考え直すだけではなかなか減りません。実際の検知結果を見ながら絞り込むのが確実です。私たちは次のサイクルを繰り返しました。
- 監査を実行する：まずは広めの条件で候補を出す
- 結果を目視で分類する：本当の不備か、誤検知かを1件ずつ仕分ける
- 誤検知のパターンを抽出する：「下書きだった」「対象外のステータスだった」など、誤検知になった理由をまとめる
- 条件を絞る：抽出したパターンを除外条件として監査に反映する
ポイントは、分類のときに誤検知の理由まで書き残すことです。理由がわかれば、同じパターンをまとめて除外できます。逆に「なんとなく違う」で済ませると、次の実行でも同じものが挙がり続けます。
このサイクルを何度か回すことで、運用に乗せられる水準まで誤検知を落としました。
判断軸：監査は検知率より先に誤検知を潰す
監査を作るとき、つい「不備を1件も漏らさないこと」を優先したくなります。しかし順序は逆です。
誤検知が多い監査結果は、担当者にとって「開いても大半はハズレの一覧」です。そうなると確認が形だけになり、結局は本当の不備も見逃されます。検知率を上げる努力は、結果が信頼できる状態になってからで十分です。
まずは「挙がったものはほぼ本当の不備」と言える状態を作る。これが、監査を現場で使い続けてもらうための前提になります。
検知後の是正の進め方：一括更新はしない
不備が見つかったら、まとめて直したくなるところです。しかし私たちは、検知後の是正で一括更新をしない方針にしています。
理由は、どれだけ条件を詰めても、検知結果に誤検知が残る可能性はゼロにならないからです。一括更新すると、正しいデータまで書き換えてしまう恐れがあります。
そこで是正は、行ごとに正解値と突き合わせてから修正します。
| 進め方 | 速さ | リスク |
|---|---|---|
| 一括更新 | 速い | 誤検知分の正しいデータを壊す |
| 行ごとに突き合わせ | 手間はかかる | 直すべきものだけを直せる |
手間はかかりますが、データを壊してから戻す手間に比べれば小さなコストです。監査の目的はデータを良くすることであり、別の不備を生まないことが前提です。
監査を定期実行に乗せるまでの流れ
誤検知が十分に減ったら、監査を定期実行にして、不備がたまる前に気づける状態にします。全体の流れは次のとおりです。
- 初版を作る：素直な条件で一度走らせ、現状を把握する
- 誤検知を潰す：目視分類と条件の絞り込みを繰り返す
- 是正の手順を決める：誰が、どう正解値と突き合わせて直すかを決めておく
- 定期実行に乗せる：信頼できる状態になってから自動で回す
いきなり定期実行にしないことが大切です。誤検知が多いまま自動化すると、ハズレの一覧が定期的に届くだけになります。なお、定期実行の仕組みやkintoneの仕様は環境やプランによって異なり、また変わるため、最新は公式で確認してください。
まとめ
- 監査スクリプトの初版は、条件がデータの見た目だけで書かれていると誤検知が多くなる
- 原因は下書き、対象外ステータス、意図的な空欄まで拾っていたこと
- 検知結果を目視で分類し、誤検知の理由をもとに条件を絞るサイクルを回す
- 判断軸は検知率より先に誤検知を潰すこと
- 是正は一括更新せず、行ごとに正解値と突き合わせる
- 信頼できる状態になってから定期実行に乗せる
よくある質問
Q. kintoneのデータ監査で誤検知が多いのはなぜ？ 監査条件が広すぎることが主な原因です。下書きのレコード、監査対象外のステータス、意図的に空欄にしている項目まで不備として拾ってしまうと、検知結果の大半が誤検知になります。まず対象範囲を絞ることが先です。
Q. 監査で見つかった不備は一括更新で直してよい？ おすすめしません。検知結果には誤検知が混ざる可能性があり、一括更新すると正しいデータまで書き換えてしまう恐れがあります。行ごとに正解値と突き合わせてから修正するのが安全です。
Q. データ監査はいつ定期実行にしてよい？ 誤検知が運用に乗せられる水準まで下がってからです。誤検知が多いまま定期実行にすると、担当者が結果を確認しなくなり、本当の不備も見逃されます。目視での分類と条件の見直しを先に繰り返します。
RENOYでは、kintoneに蓄積されたデータの監査設計から、誤検知の絞り込み、是正手順づくり、定期実行までを伴走しています。「データが荒れている気がするが、どこから手をつければいいか分からない」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。