「同じ取引先のはずなのに検索してもレコードが出てこない」「CSVで会員マスタと突合しようとしたら、件数が合わない」——kintoneを長く運用していると、こうした違和感に心当たりがある方は多いのではないでしょうか。原因の多くは、電話番号のハイフンの有無、全角と半角の混在、カナ表記のばらつきといった「表記ゆれ」です。
一括で直したい気持ちはよく分かります。ただしkintoneのCSV読み込みには、直そうとしてかえってデータを壊してしまう仕様があります。この記事では、表記ゆれが起きる理由と実害を整理したうえで、事故らずに直すための手順と、直した後に再発させない運用の考え方を解説します。
なぜkintoneのデータは表記ゆれるのか
表記ゆれの多くは、悪意のない普通の運用の積み重ねから生まれます。
1つ目は入力者の違いです。同じ「電話番号」でも、ある担当者は「03-1234-5678」、別の担当者は「0312345678」と入力します。全角英数字で入力する人、半角で入力する人が混在するのも同じ理由です。
2つ目は移行データです。ExcelからCSVで一括インポートしてkintoneを立ち上げたアプリでは、元のExcelファイルにあった表記ゆれ（「株式会社」と「㈱」、「様」と「御中」など）がそのまま持ち込まれます。kintoneのCSV読み込みは列の値をそのまま登録するため、取り込んだ時点で表記が統一されるわけではありません。
3つ目は運用年数です。担当者の交代や入力ルールの空白期間を経るほど、表記のパターンは増えていきます。表記ゆれは「誰かのミス」というより、複数人が長期間使うデータベースに構造的に発生する現象だと捉えたほうが、対処もしやすくなります。
表記ゆれが引き起こす実害
表記ゆれを放置すると、具体的に3つの実害が発生します。
| 実害 | 具体的に起きること |
|---|---|
| 検索漏れ | 「株式会社」で検索しても「㈱」表記のレコードがヒットせず、対応漏れや二重架電が発生する |
| 重複データ | 同一の取引先・顧客が表記違いで複数レコードとして存在し、集計や与信管理が不正確になる |
| 外部連携の突合失敗 | CSV連携やAPI連携で、表記が完全一致しないレコードが「別物」として扱われる |
3つ目の突合失敗は、kintoneの仕様上避けられない部分があります。CSV読み込みで既存レコードを更新する際は、更新キーに指定したフィールドの値がファイルとアプリで完全に一致して初めて、そのレコードが更新対象と認識されます。裏を返せば、更新キーに使っているフィールドに表記ゆれがあると、同じ相手のはずのレコードが「一致しない別レコード」として扱われ、更新のつもりが新規レコードとして追加されてしまいます。
実際の案件でも、更新キーの表記ゆれが原因でCSV読み込みが「GAIA_RE10」というエラーコード（更新キー値の重複）で止まるケースがあります。kintone CSV読み込みエラーを事前に防ぐ方法でも触れたように、表記ゆれで本来同じはずの値が2種類の文字列として登録され、更新キーとして重複してしまうために起きる現象です。エラーコードが出た場合は、更新キーに指定しているフィールドの表記から確認すると原因を特定しやすくなります。
まず知っておきたい危険 — CSV一括修正で「空欄が既存値を消す」仕様
表記ゆれに気づくと、CSVを書き出して一括で直し、また読み込んで済ませたくなります。ここに、知らずに手を出すと危険な仕様があります。
kintoneのCSV読み込みで既存レコードを更新する場合、フィールドに対応づけた列のセルが空欄だと、そのフィールドの登録済みの値は空または初期値で上書きされます。「電話番号だけ直したいから、他の列は空のままでいい」という感覚でCSVを作ると、電話番号以外のフィールドが軒並み空になってしまうということです。
この事故を避ける安全策は、CSV読み込み画面のフィールド対応づけにあります。値を変えたくないフィールドは、対応づけの選択肢で「（指定しない）」を選びます。「（指定しない）」に設定したフィールドは、読み込みを実行しても登録済みの値が更新されません。直したいフィールドだけを対応づけ、それ以外はすべて「（指定しない）」にする——これが一括修正時の基本の型です。
もう1つ注意したいのが、途中で気づいて止めた場合の挙動です。CSV読み込みの「読み込みを中止する」ボタンは、読み込み処理の実行中だけ表示・操作できます。処理が完了してしまうと中止操作自体ができなくなり、しかも中止した場合でも、中止する前に処理済みだったレコードはそのまま登録された状態で残ります。つまり「間違いに気づいたら実行を取り消して元に戻す」というロールバックは期待できません。
ここでつまずいたら、無料相談で画面を見ながら一緒に確認できます。
安全な直し方の原則 — 検知と修正を分け、1件ずつ確認して反映する
前章の仕様を踏まえると、表記ゆれの修正は「一括で機械的に直す」のではなく、次の3ステップで進めるのが安全です。
①検知: どのフィールドの、どのレコードに、どんな表記ゆれがあるかを洗い出します。件数が少なければ一覧画面での目視確認、多い場合は次章のプラグインなどの支援ツールを使います。
②確認: 洗い出した候補が本当に修正すべきものかを人の目で判断します。「㈱」と「株式会社」のように明らかに同一のものもあれば、実際に社名が違う会社を誤って同一視してしまう可能性もあるため、機械的な自動置換に丸投げしないことが重要です。
③個別反映: 確認が済んだものから反映します。件数が少なければkintoneの画面から直接編集するのが最も安全です。件数が多い場合にCSVを使うなら、前章の「対応づけを直したいフィールドだけに絞る」方法を徹底します。REST APIで更新する場合も同じ考え方が使えます。kintoneのレコード更新APIは、更新用のパラメータに指定しなかったフィールドは更新されず、既存の値がそのまま保持される仕様です。対象フィールドだけを指定して更新すれば、他の項目を巻き込む心配がありません。
実案件では、こうした一括修正をAPI経由で行う際に、APIトークンを「レコード取得・更新のみ」に絞って発行することがあります。トークンの権限を必要最小限にしておけば、スクリプトに誤りがあった場合の影響範囲も限定できます。
プラグインで検知→個別修正を効率化する
原則は分かっても、レコード数が数百件を超えると「検知」の工程を目視だけで進めるのは現実的ではありません。ここを効率化する選択肢の1つが、表記ゆれの検知に特化したプラグインです。
自社で提供している「pullie データ表記ゆれクリーナー」（¥5,980・買い切り）は、レコード一覧画面を開くと、表記ゆれの可能性があるセルに「ゆれ」バッジと修正候補の値を表示します（最大2,000件を走査）。対応する整形ルールは、全角半角統一などの基本整形、電話番号、郵便番号、フリガナの4種類で、電話番号と郵便番号はハイフンありに統一するか、なしに統一するかを選べます。対応フィールドは文字列（1行）とリンクフィールドです。
このプラグインの修正操作は、候補ごとに表示される「この値に修正」ボタンを押す1件ずつの個別適用のみで、ボタン1つですべてを一括置換する機能はありません。これは前章で触れた「確認してから個別に反映する」という安全な進め方と相性の良い設計です。検知は機械に任せつつ、最終判断と反映は1件ずつ人の手で行えます。処理はブラウザ内で完結し、レコードのデータが外部に送信されることもありません。
もちろん、Excelで一覧を目視しながら手作業で洗い出す方法でも原則的な進め方は同じです。件数や運用体制に応じて、検知の手段だけを効率化するイメージで検討するとよいでしょう。
再発防止 — 入力ルールと運用の見直し方
表記ゆれを直しても、入力の仕組みを変えなければ同じ状態にまた近づいていきます。ここで押さえておきたいのは、kintoneの標準機能でできることの範囲です。
文字列（1行）フィールドの設定項目は、フィールド名の表示設定、自動計算、必須項目、値の重複禁止、文字数、初期値、フィールドコードといった項目にとどまり、半角英数字のみ・カナのみといった文字種の制限や、正規表現によるフォーマットチェックの項目は見当たりません。つまり「電話番号は半角数字とハイフンのみ」といった入力ルールを、標準機能だけで強制することはできないということです。
なお、値の重複を禁止する設定を有効にすると、そのフィールドの最大文字数が64文字までに制限される点も、更新キーとして使うフィールドを設計する際には覚えておくとよい制約です。
標準機能で入力時点のフォーマットを縛れない以上、再発防止は次の2段構えで考えることになります。1つは運用ルールの明文化です。「電話番号はハイフンあり」「会社名は正式名称を入力する」といった基準をチーム内で共有し、新しく入力する人にも伝わる状態にします。もう1つは、入力形式そのものを自由記述から選択式に変える方法です。kintone顧客管理アプリの作り方とテンプレート設計で例示しているように、都道府県や部署名のように選択肢が限定できる項目であれば、ドロップダウンやルックアップによるマスタ選択式にすることで、表記のゆれそのものが構造的に起きにくくなります。どちらも地道な取り組みですが、一度直したデータを再びゆるませないための土台になります。
表記ゆれは、放置すれば検索漏れや連携ミスとしてじわじわ業務を圧迫しますが、「検知と修正を分ける」「1件ずつ確認して反映する」という原則さえ守れば、事故のリスクを抑えながら着実に整えていけます。まずは自分のアプリで、更新キーに使っているフィールドから確認してみてください。
