FileMakerで業務システムを作っていると、「入力したはずのデータが保存されていなかった」「逆に、試し入力のつもりがそのまま保存されてしまった」といったトラブルが起きがちです。これらの多くは「レコードのコミット」の仕組みを正しく理解していないことが原因です。この記事では、レコードのコミット（保存）を意識的にコントロールし、未保存や誤保存を防ぐ基本的な考え方と操作方法を、できるだけやさしい言葉で整理していきます。
レコードの「コミット」とは何かをまず押さえる
FileMakerでは、フィールドに入力した瞬間には「まだ完全には保存されていない」状態です。
この「入力中の状態」から「確定して保存された状態」に切り替えることを、レコードの「コミット」と呼びます。
イメージとしては、次のように考えるとわかりやすくなります。
- 編集中：メモ帳に下書きをしている状態
- コミット後：メモ帳の内容が正式な台帳に転記された状態
ユーザーは普段、コミットをあまり意識せずに使っていますが、どのタイミングでレコードがコミットされるかを理解しておくと、意図しない保存や未保存をかなり減らせます。
レコードが自動でコミットされる主なタイミング
代表的な自動コミットのタイミングを知っておくと、どこで「結果が確定するか」をイメージしやすくなります。
- 別のレコードに移動したとき（上下の矢印やポータル内の移動など）
- 別のレイアウトに切り替えたとき
- ウインドウを閉じたとき（保存するかどうかの確認が出る場合もあり）
- スクリプトで「レコードをコミット」ステップを実行したとき
逆にいうと、同じレコードを編集し続けている間は、コミットされずに「入力中」の状態が続いていることになります。途中でアプリが落ちたり、マシンが強制終了した場合、その編集内容が失われる可能性があります。
未保存や誤保存が起きる典型的なパターン
現場でよく聞くトラブルを、少し整理してみます。
- 入力後にそのまま画面を閉じてしまい、保存確認ダイアログを「いいえ」と押してしまった
- 試しに打ち込んだ内容が、別レコードへの移動でそのまま確定してしまった
- 担当者が途中まで入力したレコードを、別の人がうっかり上書きしてしまった
これらはすべて「いつコミットされるか」「コミットさせないようにするにはどうするか」を意識すると、防止策を立てやすくなります。
基本の対策１：明示的にコミットするボタンを用意する
もっともシンプルで分かりやすい対策は、「保存（確定）」ボタンをレイアウトに用意して、ユーザーにそこでコミットさせるやり方です。
具体的には、次のようなスクリプトを保存ボタンに割り当てます。
- 入力チェック（必須項目が空ではないか、数値の形式は正しいかなど）
- 問題があればダイアログ表示してキャンセル
- 問題がなければ「レコードをコミット」ステップを実行
こうすることで、「保存ボタンを押したときにだけ確定される」という、ユーザーにとってわかりやすいルールを作れます。
基本の対策２：自動コミットをできるだけ起こさない設計
保存ボタンでコミットを制御したい場合、逆に「意図せぬコミット」が起こりにくい画面設計も大切です。
- 一覧画面（リスト形式）と詳細画面（1レコード表示）を分ける
- 詳細画面では、別レコードに移動させない（ナビゲーションは別ウインドウや別レイアウトに）
- 「一覧から詳細へは移動するが、一覧に戻るときは必ず保存確認を通す」流れにする
レイアウトを分けるだけでも、「いつレコードが変わったのか分からないうちにコミットされていた」という事態をだいぶ減らせます。
基本の対策３：レコードをロックして誤上書きを防ぐ
複数人で同じレコードを扱う場合、編集中のレコードを他の人がうっかり編集してしまうことを防ぐ仕組みも重要です。
よく使われる方法は、次のような「ロック用フィールド」を用意するパターンです。
- 編集中ユーザー名を入れるフィールド
- 編集開始時刻を入れるフィールド
- 編集中かどうかを判定する計算フィールド
編集ボタンを押したときに、
- 誰かがすでに編集中であれば編集させない（ダイアログ表示）
- 誰も編集中でなければ、自分のユーザー名と時刻を記録してから編集開始
というスクリプトを挟むことで、意図しない同時編集をかなり防げます。編集完了時には、ロック用フィールドをクリアしてから「レコードをコミット」します。
基本の対策４：レイアウト切り替え時は必ず「保存するのか」を決める
レイアウトを切り替えたタイミングでもレコードはコミットされます。そのため、画面遷移の前に「保存するか、破棄するか」を明確に決めることが大切です。
例えば、別画面に移動するボタンに次のようなスクリプトを設定します。
- 現在のレコードが編集されているかどうかをチェック
- 編集されていれば「保存して移動」「保存せず破棄して移動」「キャンセル」などの選択肢を提示
- ユーザーの選択に応じて「レコードをコミット」または「現在のレコードを元に戻す」を実行
- その後にレイアウト切り替えを実行
このように、「移動ボタン＝コミットを含めた処理の入り口」にしておくと、
予期しないタイミングでデータが確定してしまうのを防げます。
実務でのポイント：まずは「どこで保存されるか」を可視化する
いきなり複雑なスクリプトや権限設定を考える前に、次のような整理をおすすめします。
- このレイアウトでは、ユーザーに「どのタイミングで保存されたことを意識してほしいか」
- 保存されていない変更があるときに、どんな行動を禁止したいか（画面遷移、レコード移動など）
- 複数人で同時に編集されると困るレコードはどれか
これを書き出してみると、「保存ボタンを増やすのか」「画面を分けるのか」「ロック機構を入れるのか」など、やるべき対策が見えやすくなります。
FileMakerは標準の動きでも十分便利ですが、「コミットのタイミング」と「未保存時のふるまい」を少し意識して設計するだけで、
現場の「データが消えた」「意図せず上書きされた」といったストレスを大きく減らすことができます。