FileMakerで複数のレイアウトやテーブルを扱っていると、「似たようなフィールド更新スクリプトが量産されてしまう」「どこを直せばいいか分からない」といった悩みが出てきます。そこで役立つのが、フィールド名を使って共通的に処理する「汎用更新スクリプト」の考え方です。
この記事では、「名前でフィールド設定」という考え方を使って、できるだけシンプルに、分かりやすく汎用更新スクリプトを作る方法を紹介します。
汎用更新スクリプトが必要になる場面とは？
たとえば、次のような場面を思い浮かべてみてください。
- 「ステータス」フィールドを「未処理 → 処理中 → 完了」と切り替える処理を、いろいろなテーブルで使いたい
- 「更新者」「更新日時」を必ずセットする処理を、あちこちのスクリプトで書いている
- 同じような「入力チェック → エラー表示 → フィールド更新」を何度も作っていて、メンテナンスが大変
こうした共通処理を、テーブルやレイアウトごとに個別のスクリプトとして作ると、あとで仕様変更が入ったときに、全部修正して回る必要が出てきます。ここで役に立つのが、「フィールド名」をキーにして処理する汎用スクリプトです。
「名前でフィールド設定」とはどういう考え方？
通常、スクリプトでフィールドを更新するときは、
- 「フィールド設定」ステップで、テーブル::フィールド名 を直接指定する
という形になります。このやり方だと、スクリプト内にフィールド名が固定されてしまうため、他のテーブルやレイアウトでは使い回しにくくなります。
そこで、「名前でフィールド設定」という発想では、
- フィールド名そのものをテキストとして渡す
- スクリプトの中で、その名前をもとにフィールドを特定して値をセットする
という形に切り替えます。つまり、「どのフィールドに書き込むか」をスクリプト引数などで外から指定するイメージです。
基本的な汎用更新スクリプトの考え方
もっともシンプルな形を、まずイメージしてみましょう。
- スクリプト引数として「フィールド名」と「セットしたい値」を受け取る
- 受け取ったフィールド名をもとに、対象のフィールドを見つける
- 見つかったフィールドに、受け取った値をセットする
この流れさえ押さえれば、後はエラーチェックや付加処理（ログを残す、更新日時を記録するなど）を追加していくだけです。ポイントは「スクリプトの中では具体的なフィールド名をできるだけ書かない」ことです。
スクリプト引数の設計イメージ
FileMakerでは、スクリプト引数をテキストとして渡します。汎用更新スクリプトでは、次のような情報を渡す形が分かりやすいです。
- targetFieldName：更新したいフィールド名（テーブルオカレンス名::フィールド名）
- newValue：セットしたい値
実際の実装では、
- JSON形式で渡す（例：
{"targetFieldName":"テーブルA::ステータス","newValue":"完了"}） - 区切り文字でつなげる（例：
テーブルA::ステータス¶完了）
といった形がありますが、これから作る場合はJSON形式を使うと、後で項目を増やしやすくて便利です。
実際の操作手順（設計の流れ）
ここでは、具体的な操作の流れをざっくりと説明します。細かいステップ名や関数名は、マニュアルと照らし合わせながら進めてみてください。
1. 汎用更新スクリプトを新規作成する
- スクリプトワークスペースを開き、「新規スクリプト」を作成します。
- 名前は分かりやすく「汎用_フィールド更新」などとしておきます。
2. スクリプト引数を受け取る
- スクリプトの先頭で、「スクリプト引数」を変数に代入します（例：
Set Variable [ $param ; Get ( ScriptParameter ) ]）。 - JSON形式にしている場合は、
JSONGetElement ( $param ; "targetFieldName" )、JSONGetElement ( $param ; "newValue" )のようにして
targetFieldName と newValue をそれぞれ変数に取り出します。
3. 対象フィールドを特定する
ここが「名前でフィールド設定」の肝になる部分です。レイアウト上の対象フィールドを、
- 現在表示しているレイアウト
- もしくは特定のテーブルオカレンス
の中から、名前で探して特定します。実装方法はいくつかありますが、シンプルなパターンとしては、
- 「テーブルオカレンス名::フィールド名」の形で完全な名前を引数で渡してもらう
という割り切りをしてしまう方法です。この場合、スクリプトの中では、Evaluate 関数を使って、文字列として渡されたフィールド参照に対して「フィールド設定」ステップを適用します（例：Set Field By Name [ $targetFieldName ; $newValue ] というカスタム関数相当の処理を Evaluate で実現するなど）。
4. 値をセットする
対象フィールドが特定できたら、
- 「フィールド設定」ステップで newValue をセット
するだけです。このとき、
- 空値を許可するか
- もともとの値に追記するのか、置き換えるのか
などの仕様を、スクリプトの中でしっかり決めておくと、後々トラブルが減ります。
活用例：ステータス更新を一元管理する
実用的な例として、「ステータス」更新を共通化するケースを考えてみます。
- レコードの状態を「未処理」「処理中」「完了」で管理している
- 複数のテーブルに「ステータス」フィールドがある
- ボタンからステータスを変更したい
この場合、各レイアウトのボタンから、次のようなスクリプト引数を渡します。
{"targetFieldName":"テーブルA::ステータス","newValue":"完了"}{"targetFieldName":"テーブルB::ステータス","newValue":"処理中"}
ボタンごとに変わるのは「引数の中身」だけで、実行するスクリプトは同じ「汎用_フィールド更新」です。この形にしておくと、
- 「ステータス更新時には必ず更新日時と更新者も記録したい」
といった仕様変更があったときも、汎用スクリプト1本を直せば全てに反映されます。
汎用スクリプトを作るときの注意点
便利な一方で、いくつか注意したいポイントもあります。
- フィールド名が変わると動かなくなるため、名前変更には十分注意する
- 誤ったフィールド名が渡されたときのエラーチェックを入れておく
- 「どこで何が更新されているか」が分かりにくくなるので、コメントや命名規則で補う
特に、引数の中に渡すフィールド名は「テーブルオカレンス名::フィールド名」で統一するなど、最初にルールを決めておくと混乱を防げます。
まとめ：少しの工夫でメンテナンスを楽にする
「名前でフィールド設定」を使った汎用更新スクリプトは、最初に考えると少し回りくどく感じるかもしれませんが、
- 同じようなスクリプトを量産しなくてよくなる
- 仕様変更のときに直す場所が少なくて済む
- 処理の標準化・品質の安定につながる
というメリットがあります。特に、テーブル数やレイアウト数が多くなってきたタイミングで威力を発揮します。
いきなり全てを汎用化する必要はありません。まずは「ステータス更新」「更新日時・更新者の記録」など、よく使う処理から少しずつ共通化していくと、負担を抑えながら効果を実感しやすくなります。