FileMakerでGet(UUID)主キー自動採番の基本

FileMakerで主キーをどう作るか迷っていませんか？

FileMakerで本格的にデータベースを作り始めると、必ずぶつかるのが「主キー（ID）の設計」です。
「連番でいいの？」「途中で番号が飛んだらどうなる？」「複数人で同時入力したら重ならない？」など、気になるポイントは多いですよね。

そんなときにおすすめなのが、Get ( UUID )関数を使った「UUIDによる主キー自動採番」です。
この記事では、そもそも主キーとは何か、なぜUUIDが便利なのか、具体的な設定方法まで、できるだけ専門用語を避けて分かりやすく解説します。

主キーってそもそも何？なぜ必要？

主キー（Primary Key）は、レコードを一意に識別するための「番号」や「ID」のことです。
例えるなら、会員カードの会員番号や、社員の社員番号のようなイメージです。

主キーがない、あるいは曖昧だと、こんな困りごとが起きます。

同姓同名の人を区別できない
請求書と顧客情報を正しく結び付けられない
レコードのリンク（リレーションシップ）が壊れやすい

FileMakerでは、テーブルどうしをつなぐ「リレーションシップ」を組むときにも、主キーが中心的な役割を果たします。
そのため、最初に安全で壊れにくい主キーを決めておくことが、とても重要です。

連番主キーの限界とリスク

FileMakerの自動入力オプションには、「連番」でIDを振る機能があります。
「1, 2, 3, 4…」と増えていくシンプルなIDは、人間にとっては分かりやすいので、よく使われる方法です。

ただし、連番にはいくつか弱点があります。

バックアップからの復元時に、番号が重なるリスク
複数ファイルやシステムをまたぐと、番号の一意性を保ちにくい
レコードを削除すると番号が飛ぶ（気になる人は気になる）
外部システムと連携するときに、IDの重複を避けにくい

特に、システムが大きくなったり、他のシステムと連携したり、クラウドやサーバーで同時に複数ユーザーが使うようになってくると、連番だけに頼るのは心もとない場面が増えてきます。

UUIDとは？Get(UUID)が便利な理由

そこで登場するのが、Get ( UUID )関数です。
UUID（ユニバーサリユニーク ID）は、ほぼ重複しないように作られた長い文字列のIDです。

例：

3F2504E0-4F89-11D3-9A0C-0305E82C3301

このような文字列が自動で生成されます。
パッと見て意味は分かりませんが、世界中で同じIDがかぶる可能性が非常に低いというのが最大のポイントです。

FileMakerでは、Get ( UUID )関数を使うことで、このUUIDを簡単に生成できます。
これを主キーとして使うことで、次のようなメリットがあります。

IDがほぼ絶対に重ならないので、安心して使える
バックアップからの復元や移行にも強い
複数ファイル・複数システム間の連携に向いている
サーバーやクラウドでの同時入力でもIDの衝突を心配しなくてよい

「人間にとって覚えやすい番号」ではありませんが、内部でレコードを識別するためのIDと割り切ってしまえば、とても便利で安全な方法です。

FileMakerでGet(UUID)主キーを設定する手順

ここからは、実際にFileMakerでGet ( UUID )を使って主キーを自動採番する手順を説明します。
新しくテーブルを作成したり、既存のテーブルに主キーを追加するときに役立ててください。

1. 主キー用のフィールドを作成する

管理メニューから［ファイル］→［管理］→［データベース…］を開きます。
対象のテーブルを選択して、新しいフィールド名を入力します。例：id、id_顧客 など。
タイプは「テキスト」を選びます。UUIDは文字列なので、数値ではなくテキストにします。
［作成］または［変更］をクリックしてフィールドを追加します。

2. 自動入力でGet(UUID)を設定する

作成した主キー用フィールドを選び、［オプション…］ボタンをクリックします。
オプション画面で、［自動入力］タブを開きます。
「計算値」にチェックを入れ、［指定…］ボタンをクリックします。
計算式の欄に Get ( UUID ) と入力します。
下にある「既存の値を置き換えない」のチェックは、通常はオンにしておくのがおすすめです。
これにより、既にIDが入っているレコードのIDが勝手に書き換わるのを防げます。
OKで閉じて、再度OKでオプション画面も閉じます。

これで、新しくレコードを作成したときに、自動的にUUIDが主キーとして採番されるようになります。

リレーションシップでGet(UUID)主キーを使う

UUIDを主キーにしたら、関連先のテーブルにも対応する外部キーのフィールドを用意しましょう。

親テーブル（例：顧客）側：id_顧客（テキスト / Get ( UUID ) で自動入力）
子テーブル（例：請求書）側：id_顧客_fk（テキスト）

リレーションシップグラフでは、顧客::id_顧客 と 請求書::id_顧客_fk を結びます。
レイアウト上でポータルやスクリプトを使ってレコードを作るときに、この外部キーへ親の主キー（UUID）をセットすることで、レコード間のリンクが安定します。

Get(UUID)主キーを使うときの注意ポイント

便利なUUIDですが、使うときに少しだけ意識しておきたいポイントがあります。

人間には覚えにくいので、「表示用の顧客番号」などが必要なら、別に連番フィールドを作る
IDを手入力しない（コピー＆ペーストが必要な場合も、基本はスクリプトで処理する）
一度発行したUUIDは変えない（レコードの引っ越しや統合作業でも、IDの変更は極力避ける）
インポート時の「マッチフィールド」設定で、UUIDフィールドをキーにする場合は慎重に確認する

これらを心がけることで、長期的に安心して運用できるデータベースに近づきます。

まとめ：Get(UUID)主キーで「壊れにくい」FileMakerへ

この記事では、FileMakerでの主キー設計について、Get ( UUID )を使った自動採番を中心に解説しました。

主キーは、レコードを一意に識別するための「ID」
連番は分かりやすいが、重複や復元時のトラブルに弱い
Get ( UUID )は重複しにくいIDを自動で生成してくれる
フィールドをテキスト型で作成し、「計算値：Get ( UUID )」で自動入力すると簡単に導入できる
人間向けの表示番号が欲しい場合は、別に連番フィールドを用意する

これから新しくデータベースを作る方や、今のシステムを見直したい方は、「主キーはUUID、表示用には別の番号」という設計を検討してみてください。
最初のひと手間で、後々のトラブルを大きく減らすことができます。