kintoneのレコード番号、そのままで大丈夫？

kintone はノーコードで業務アプリを作成できるサービスです。より実体を捉えて言えば、入力フォームとデータベースが簡単に作成できるサービスとも言えます。

そして、データベースということは、レコードを特定するための一意の番号が必要になります。kintone では、レコード番号というものが自動的に割り振られます。

レコード ID も存在しますが、アプリコードを含むかどうかの違いだけで、基本的には同じと考えて良いでしょう。

本来データベースにおいて、一意となる ID はデータ間の関係を明確にするために非常に重要な役割を持ちますが、kintone ではあまり意識する必要がないように設計されているように感じます。

とはいえ、kintone の活用が進むにつれ、このレコード番号、またはデータベースのキーにあたる情報を、嫌でも意識することになります。

このページでは、kintone のレコード番号と、データベースとしての kintone をどのように活用していくかについて考えていきます。

kintone のレコード番号とは？

kintone のレコード番号は、アプリ内の各レコードに自動的に割り振られる一意の識別子です。これは、アプリ内でレコードを特定するために使用されます。

レコード番号は「アプリコード + 連番」の形式で構成されており、連番部分はレコードが作成されるたびに自動的に増加します。そして、レコードが削除されたとしても、同じ番号が再利用されることはありません。

重複しないことが保証されているため、CSV のインポートやエクスポート、REST API を使用したデータの取得や更新など、さまざまな場面で利用されます。

レコード番号のみの運用の問題点

前述した通り、kintone のレコード番号は一意であり、基本的には問題なく運用できます。しかし、「同じ番号が再利用できない」という特性が、運用上の問題を引き起こすことがあります。

レコードを誤って削除してしまった場合、そのレコード番号は再利用されません。もしバックアップを取っており、復元することができたとしても、元のレコード番号は失われます。

もしこのアプリにレコード番号の ID 以外にレコードを特定する情報がない場合、復元後のレコードは新しいレコードとして扱われ、他のアプリやプロセスとの連携が失われる可能性があります。

このような事態を避けるためには、レコード番号以外の一意の識別子を持つことが重要です。

レコード番号以外の一意の識別子を持つ

kintone のレコード番号は便利ですが、前述したような問題を避けるためには、レコード番号以外の一意の識別子を持つことが重要です。 例えば、以下のような方法があります。

一意のコードをレコード作成時に必須入力

最もシンプルに実装できる方法は、レコード作成時に一意のコードを必須入力とすることです。例えば、社員番号や商品コードなど、既に一意であることが保証されているフィールドを利用します。

kintone では、文字列１行フィールドの設定として、「重複を禁止する」オプションと、「入力を必須にする」オプションが用意されています。これらを組み合わせることで、レコード作成時に一意のコードを必須入力とすることができます。

複数のフィールドを組み合わせて一意の識別子とする

複数のフィールドを組み合わせて一意の識別子とする方法もあります。例えば、氏名と生年月日、または商品名と製造番号など、複数のフィールドを組み合わせることで、一意の識別子を作成します。

注意点として、変更され得るフィールドを組み合わせると、一意性が保証されなくなる可能性があるため、変更されないフィールドを選択することが重要です。

自動採番を利用する

kintone プラグインや JavaScript カスタマイズを利用して、自動採番を実装する方法もあります。

前述のフィールド設定で「重複を禁止する」オプションを利用することで、もしエラーが発生した場合も、想定しない番号が登録されることを防ぐことができます。