一意とは

とりあえず「一意」の定義をChatGPTにきいてみました。

「一意（いちい）」は、
“ただ一つに決まっていて、ほかに同じものがない” という意味の言葉です。

よく使われる場面の例：

一意に決まる
→ 条件から答えが 唯一つだけ確定すること。
（例：ID が一意に割り当てられている＝同じ ID を持つ人がいない）

一意性
→ データベースなどで、重複が存在しない性質のこと。

つまり、
「一意」＝ “唯一で重複しない・迷いなく決まる” というニュアンスです。

だそうです。

なお英語でいうとUniqueになります。

kintone上でみられる一意なもの

kintone上でも、一意な性質を示す値は様々な箇所で見かけます。

なお、代表的なもので言うと

アプリID
レコード番号
などが挙げられます。

例えば様々なフィールドに「値の重複を禁止する」オプションがあります。
これを有効にするというのは、言い方を変えるとすなわちフィールドの値が一意であることが保証できるということになります。

また、例えば帳票には一般的に鑑（かがみ）と呼ばれる部分と、明細と呼ばれる部分があるとされますが、鑑にある帳票のID（請求書であれば請求書番号や請求書IDと呼ばれるもの）が帳票１つ１つを一意に指すため、これは一意であると言え。またそれらの明細についても、帳票のIDと明細行の番号をセットにすれば、明細１つ１つを一意に指すため、一意であると言えます。

※上の図でいうと、請求書No.となっている「S-25-0001」が帳票を一意に示し、更に請求書No.「S-25-0001」と明細No.「1」や「2」を組み合わせたものが一意な帳票の明細を示します。

この例が示すように、一意を示す値のセットは「１つのフィールドだけで一意となる」ケースと、「複数のフィールドを組み合わせて一意となる」ケースがあるということがわかります。

kintone上で使える一意なもの

さて、ここからはkintoneの基本機能や、カスタマインでのカスタマイズの結果として、実際に使える様々な「一意」を見ていきましょう。

レコード番号

レコード番号は一意です。更に単一のフィールドです。加えて基本機能です。

これさえあればいいじゃない！（と思っていた時期が私にもありました）

まあご存知の方も多いと思いますが、レコード番号は、kintoneのアプリに対してデータをバックアップして戻すなどのシチュエーションを考えた時に、同じレコード番号を取り直す事ができない　という特性があるので、アプリ間でのレコードの関連性を示す先（ルックアップだったり関連レコードだったりの、関連付ける先のフィールド）としては基本的には使わないのが望ましいとされています。

ただし、レコード番号の一意性が非常に役立つケースもあります。

例えばカスタマインで

レコードを一旦保存
そのレコードに対し、改めて更新
と行った処理を行う場合、レコードを保存したアクションの結果としてレコード番号が帰って来る仕様になっているため、次のようなカスタマイズを設定してあげるとうまく動きます。

採番した値

カスタマインで採番した値（例えば自動採番を行うや自動採番を行う）は一意です。基本的には数値フィールドに素直に格納すると思うので、単一のフィールドです。

特にこだわりがなければ、採番した値を使って一意性をうまく活用するのが良いでしょう。

こういったケースの採番についてはこの記事が詳しいです。

レコード保存直後に自動採番

なお前述の帳票のIDなんかも自動採番をつかってもらうのが楽だろうな　という気がしています。

ランダムな文字列

少し変わり種でいうと充分な長さを担保した、やること「ランダムな文字列を生成する」の結果は、ほぼほぼ一意になるはずです。ランダムなので。

まあ、採番したほうが手っ取り早い気がしますが、この特性をうまく使った例としては
ランダムな文字列で抽選アプリを作成する方法
というのがあります（値が衝突しないし、ランダムなのでソートするとランダムな順に並ぶ）。

レコード番号をカスタマイズでコピーする

レコード番号はエクスポート／インポートすると値がリセットされるのでレコードの関連性を取り扱うには向かないのですが、例えば「レコード番号をコピーする」フィールドを作っておき、レコードを保存した直後（レコードを保存した直後（削除後は除く））にそのフィールドに値が入ってなければコピーする　という事をしてあげると、一意な値として使えます。

まあ、採番したほうが手っ取り早い気がしますが。

作成者と作成日時を組み合わせる

もし、１分に１レコード以上絶対に入らない事が保証されているアプリであれば、作成者と作成日時を組み合わせると一意になります（その作成者が平行で作業をしていないという前提のもとですが）。

※安全をみるのであれば、1レコードが2分より短い間隔では入らない運用となっているアプリの方が望ましいでしょう

なお、完璧に重複を排除するまでしたければ、この２つを複合キーとして取り扱えば重複排除できます。
※同様の例でいうと、たとえばユーザー単位で書く月報アプリなんかだと、年月とユーザーIDを組み合わせれば一意になります

複合キーの内容を説明している記事としては
複合キーで重複チェックをレコード保存時に実行
が詳しいのですが、シンプルなカスタマイズの例は次のようになります。

自分で取得した日時と登録ユーザーIDを組み合わせる

kintone標準だと、日時型や時間型のフィールドは分までの粒度でしか値を持てないのですが、例えばカスタマインのnow()関数を使い、これを文字列(1行)フィールドに格納して、ユーザーIDと組み合わせるとどうなるでしょうか？

そうです。ほぼほぼ一意になります（こちらも、その作成者が平行で作業をしていないという前提のもとですが）。

具体的なカスタマイズ例でいうと、次の通りです。

ただし、now()関数はブラウザが動いてるコンピューター上の時計を見るため、複数の端末（たとえばスマホとPCなど）を利用していてそれぞれの時計がズレているとうっかり値が重なるケースがあるかもしれません。

なお、値を意図的に重ねてみるとこんな感じです（複数のブラウザ画面上で１秒以内に収まるように、複数回新規レコードの追加を行っています）。

ですので、例えば機械的に大量のデータを入れる様なケースにも弱いです（画面操作からでないと、レコードを投入しないなどの前提があればうまく一意制約が効くと思います）。

まあ、結局のところ採番したほうが手っ取り早い気がしますが。

おわりに

今回は、kintoneやカスタマインにまつわる/かかわる一意をざっと俯瞰してみました。

意外なフィールドの組み合わせも、見かたを変えると一意になっているかもしれません。ぜひ身近な一意を探してみてください！