1. 環境分離の最大の壁 ｢データ移行｣
前回のブログでは、安全な開発のために ｢環境分離（本番と開発を分ける）｣ が不可欠であることをお伝えしました。しかし、実際に環境を分けると、必ず大きな壁にぶつかります。
それは、｢開発が終わった新しいファイルに、運用中の最新データをどう移すか｣ という問題です。
今回は、長年エンジニアを悩ませてきた ｢手動インポート｣ の限界と、それを救ってくれる Claris 公式ツール Claris FileMaker Data Migration Tool について深掘りします。
2. 従来の ｢インポート・エクスポート｣ はここがツライ！
これまでの主流だった ｢インポート｣ によるデータ移行。確実な方法ではありますが、エンジニアが細部まで神経を研ぎ澄ませて作業する必要があり、かなりの労力とプレッシャーがかかるのが現実でした。
- 終わらない待ち時間
データ量が多いと、インポートだけで数時間がかかってしまうことも珍しくありません。 - 複雑なスクリプトの作り込み
移行のためだけに専用のスクリプトを組んだり、メンテナンスしたりする手間がかかります。 - アカウントが引き継げない
最大の悩みどころは、データは移せても ｢アカウント名とパスワード｣ はインポートできない点です。ユーザー全員にパスワードを再設定してもらうか、管理者が手作業で登録し直す必要があり、運用上大きなリスクを抱えていました。 - 値一覧の同期漏れ
値一覧の ｢カスタム値｣ にはインポート機能がありません。本番環境で追加された値を、開発ファイルへ手作業で転記する作業が発生します。 - シリアル番号の再設定ミス
入力値の自動化で設定しているシリアル番号の ｢次の値｣ を手動で合わせる必要があります。対象フィールドをすべて特定し、現在の最大値を確認して ｢次の値｣ を一つひとつ手入力……。これを一つでも忘れると、運用開始直後にエラーが発生する原因になります。
3. FileMaker Data Migration Tool がもたらす ｢技術革命｣
こうした苦労を一掃するために提供されているのが、コマンドラインツール FileMaker Data Migration Tool ( DMT ) です。DMT は ｢ソースファイル（旧ファイル・本番）｣ のデータを ｢クローンファイル（新ファイル・開発済み）｣ へ一気に流し込み、新しい本番ファイルを生成してくれます。
DMT が現場を救う 3 つのポイント
- アカウント情報の完全移行
ハッシュ化されたパスワードを含め、アカウント情報をそのまま引き継げます。オプション設定により、新旧どちらのアカウントを優先するかを選択できる柔軟性も備えています。 - シリアル番号と値一覧も自動でおまかせ
各フィールドのシリアル番号 ｢次の値｣ をソースファイルから引き継ぎ、クローンファイルへ適用します。また、値一覧のカスタム値もそのまま引き継げ、オプションでソースファイルとクローンファイルの優先度を選択可能です。これにより、ヒューマンエラーを物理的に排除できます。 - 圧倒的な処理スピード
データの塊をダイレクトに転送するので、通常のインポートより数倍、条件が良ければ数十倍のスピードで終わります。
4. 知っておきたい ｢運用の落とし穴｣
DMT は非常に強力ですが、万能薬ではありません。「DMT 独自のルール」を正しく理解しておくことで、トラブルを未然に防ぐことができます。
技術的な注意点（仕様の壁）
1. どのフィールドがマッチングするか分かりにくい
DMT は、以下の優先順位でオブジェクトを自動的に紐付けます。
- 内部 ID と名称の両方が一致
- 名称のみ一致
- 内部 ID のみ一致
【注意】 異なるフィールドタイプ（例：日付からタイムスタンプへの変更）であっても、名前や ID が一致すればデータは強制的に流し込まれます。開発中にフィールド名を変更したり、テーブルの再作成によって ID がズレたりしている場合は、予期せぬマッピングが起きていないか細心の注意が必要です。
最大の懸念は、DMT は ｢実行してみるまでどこが紐付いたのか(または紐づかなかったのか)が見えない｣ というブラックボックスであることです。エラーで止まることなく、知らない間に意図しないデータの上書きが完了してしまうリスクが潜んでいます。
予期せぬマッピングによるトラブル例
- テキストから日付への変更
データをエクスポート･インポートした場合にフィールドタイプの違いにより､インポートエラーが発生する可能性がある- テキストから数字への変更
リレーション成立の条件が変わり､関連レコードに意図しないレコードが含まれる可能性がある
2. アクセス権セットの ｢迷子｣ に注意
アカウント情報の移行時、紐付く ｢アクセス権セット｣ がクローン側で見つからない(名称も ID も一致しない)場合、安全策として [Unmapped Privilege Set] が割り当てられます。
- このセットは ｢アクセス権すべてなし｣ の状態であるため、そのままではユーザーが何も操作できず、現場が混乱してしまいます。
- 新旧のアカウントを統合する設定はないため､どちらを優先するか(デフォルトはソース優先)をあらかじめ決めておく必要があります｡状況によっては移行後の手作業での調整が必要です｡
3. 値一覧（カスタム値）の優先度
ユーザーが自由に値を編集・追加できる ｢カスタム値｣ は、移行時に ｢ソース｣ と ｢クローン｣ のどちらを優先するか選べますが(デフォルトはソース優先)、｢両方の値を生かしたい｣ という場合は、移行後に手作業での調整が必要です。
4. 外部データソースの設定確認
他の FileMaker ファイルや SQL サーバーを参照している場合、その ｢外部パス｣ が本番環境の構成に合っているか再確認しておきましょう。
5. 新規テーブルとシリアル番号
新しく追加したテーブルに「シリアル番号」の自動入力設定がある場合、移行後の ｢次の値｣ が意図しない番号になってしまうことがあります。
- シリアル番号のリセット
移行後はレコード数が0になるため、次に振られる番号を適切に設定し直す必要があります。特に開発中のテストでレコード作成・削除を繰り返していた場合、番号が重複するリスクがあるため、再設定は必須作業です。 - 初期データの投入
新規テーブルにマスターデータ等が必要な場合は､ DMT 実行後にインポートスクリプトを走らせる等の対策を検討してください｡
6､ 追加フィールドの初期値
既存テーブルに新しくフィールドを追加し､そこに特定の初期値が必要な場合は､移行が終わった後の設定(全レコード置換など)を忘れないようにしましょう｡
運用面の課題（実戦の壁）
- CLI 操作の心理的ハードル
コマンドラインでの操作は、慣れていないと構文ミスやパス指定の間違いが起きやすく、複数ファイルを処理するとなるとより複雑化します。 - 深夜作業の拘束
ツール自体は高速ですが、結局 ｢ユーザーが使わない深夜に PC の前で待機し、手動でコマンドを叩く｣ という状況は変わりません。
5. まとめ
DMT の活用で、処理スピードは劇的に上がり、移行作業の時間は大幅に短縮されました。しかし、依然として「ユーザーが使わない深夜に PC の前で待機し、ミスが許されないコマンド操作（ CLI ）を行う」という精神的プレッシャーは残っています。
しかし､一方でコマンドライン( CLI )操作には特有の｢壁｣も存在します｡構文ミスやパスの間違いが許されない緊張感､そして実行直前の｢本当に正しく紐付いているかな……？｣という不安｡
DMT は便利ですが､コマンドを叩くまでは｢本当に意図通りにデータが流れるか｣がブラックボックスです｡やり直しのきかない一発勝負の前に､もし｢シミュレーション｣ができて､問題点を事前に可視化できたら最高だと思いませんか？さらに、黒い画面（コマンドライン）ではなく、直感的な画面（UI）で安全に操作できたらどうでしょうか？
そこで最終回となる次回は、DMT の実行をサポートし、よりミスのない運用を可能にするツール ｢ Migration Master ｣ について詳しく解説します。移行作業をよりスマートに、そして確実に行うためのヒントをお伝えします。
→ [第3回]の記事はこちら
