ブログ

FileMakerは時代遅れ?大規模な基幹システムで使うための4つの設計

「FileMakerは時代遅れ」「大規模なシステムには向かない」と言われる理由と、実際にどこまでの規模で使えるのかを、公式の技術仕様と数百人が使う基幹システムの実例で説明します。大規模でも遅くならないための4つの設計も紹介します。

公開 更新 カテゴリ DX
FileMakerは時代遅れ?大規模な基幹システムで使うための4つの設計のアイキャッチ画像

こんにちは。リナークのニシザワです。

Claris FileMaker(以下、FileMaker)について調べると、「時代遅れ」「大規模なシステムには向かない」「検索や表示が遅い」といった声を目にすることがあります。

私たちは、FileMakerで製造業の基幹システムを開発し、運用を支えています。その経験から言うと、これらの声の多くはFileMakerという道具ではなく、設計の問題から来ています。

この記事では、FileMakerが時代遅れと言われる理由、実際にどこまでの規模で使えるのか、そして大規模なシステムでも遅くならないために私たちが実践している4つの設計を紹介します。

FileMakerが「時代遅れ」と言われる理由

よく聞く理由は、おおむね次の3つです。

  • 検索や表示が遅い:データが増えるにつれて、画面の切り替えや検索に時間がかかるようになった。
  • 大規模なシステムには向かない:部署の中の小さな道具としては便利でも、会社全体の基幹システムには使えないと思われている。
  • 作った人にしか分からない:社内の誰かが自己流でつくったファイルが、本人の異動や退職で手をつけられなくなった。

どれも実際に起きていることです。ただし、原因をたどると、データの設計をせずに機能を足し続けたことに行き着く場合がほとんどです。FileMakerは手軽に画面をつくれる分、設計を飛ばしても動いてしまいます。小さいうちは問題になりませんが、利用者やデータが増えたときに一気に表に出ます。

実際にどこまでの規模で使えるのか

公式の技術仕様

Claris社が公開している FileMaker Server 2026 の技術仕様では、同時接続の上限は次のとおりです。

  • FileMaker Pro:テスト済み 500、最大 2,000
  • FileMaker Go:テスト済み 500、最大 500
  • FileMaker Data API:テスト済み 500、最大 1,000

※出典:Claris「Claris FileMaker 2026 Technical Specifications」。テスト済みの値は Claris のテスト環境での結果で、性能を保証するものではありません。

数十人から数百人が毎日使う、中小製造業の基幹システムであれば、接続数の面では十分に対応できる範囲です。

実例1:数百人が使う、一気通貫の基幹システム

私たちが開発し、お客様が現在も運用している基幹システムには、常時数百のクライアントが接続しています。

扱う業務は「案件 → 見積 → 受注 → 設計 → 計画 → BOM(部品表)→ 資材 → 製造 → 物流 → 在庫 → 請求 → 入金」までの一気通貫です。部門ごとに別々のシステムを使うのではなく、1つの仕組みの中でデータがつながっています。

実例2:小さな仕組みから120ライセンスへ

私が前職のメーカーで担当していた仕組みも、FileMakerで育てたものです。

2013年に入庫管理という1つの業務から始め、物流、発注へと広げ、2022年には生産・購買・工程管理まで対象を広げました。最初は1ライセンスだった利用者は、120ライセンスになりました。

  • 三十数年にわたって積み重なった古いシステムでしかできなかった作業の属人化を解消
  • 生産の状況をリアルタイムで見られるようにし、データを活用できる環境を整えた
  • 8年間の取り組み全体で、5,030万円相当の効果がありました(金額の削減2,580万円以上と、作業時間の削減2万7千時間以上を長野県の最低賃金で換算した2,450万円の合計)。

大規模でも遅くならないための4つの設計

1. データ中心で設計する(データモデリング)

画面から考えるのではなく、まず業務の中にどんなデータがあり、それぞれがどうつながっているかを整理します。整理した結果はER図にまとめ、その設計どおりにテーブルをつくります。この考え方は「DOA(データ中心アプローチ)」と呼ばれます。

FileMakerはローコードで開発できるので、設計をしなくても小さな仕組みはつくれます。しかし、数十人、数百人が同時に使う基幹システムでは、設計に忠実かどうかで、拡張のしやすさと応答の速さに大きな差が出ます。

一方で、FileMakerはデータと画面・スクリプトの距離が近いため、業務のルールが変わったときの作り直しが速いという強みがあります。設計をきちんとしたうえでこの強みを生かせば、業務の変化に合わせて仕組みを育て続けることができます。

ER図の具体例は「在庫管理データベースの作り方。最小構成のテーブルとER図の3段階【FileMaker】」でも紹介しています。

2. データと画面のファイルを分ける(分離モデル)

データ(テーブルとレコード)を入れるファイルと、画面・スクリプト・値一覧などを入れるファイルを分けます。これを「分離モデル」と呼びます。

画面や処理だけを直すときは、画面側のファイルを入れ替えるだけで済みます。データのファイルに触れないので、データを守りやすく、改修のたびに長い時間システムを止める必要もありません。小さな改修を繰り返して仕組みを育てるには、欠かせない考え方です。

データの構造を変える改修では、Claris社の「FileMaker Data Migration Tool」を使うと、データの移行を効率よく進められます。

3. データの性質ごとにファイルを分ける

データのファイルは、さらに性質ごとに3つの系統に分けます。

  • トランザクション系:見積・受注・発注・実績・売上・請求など、業務が進むたびに増え続けるデータです。更新が多く量も増えるので、部門やデータの性質ごとにファイルを分け、バックアップや復旧にかかる時間を抑えます。
  • マスタ系:商品・取引先・社員など、更新は少ないものの、あらゆる画面や処理から参照されるデータです。トランザクション系と分け、更新できる人を権限で限定します。
  • サマリ系:日別・営業所別の売上や棚卸の集計など、人が見やすい形にまとめたデータです。数百万件のトランザクションをその都度集計すると、サーバーに大きな負荷がかかります。そこで、定期的に実行する処理(バッチ処理)であらかじめ集計しておき、画面ではその結果を表示します。

「検索や表示が遅い」という問題の多くは、この分け方と集計の持ち方で解決できます。

4. FileMaker Server で、みんなで使う前提にする

仕組みは、複数の人が同じデータを使うことで本来の力を発揮します。私たちは FileMaker Server、または FileMaker Cloud を使い、開発の段階からサーバー上で仕組みをつくります。開発中の機能を現場の方にすぐ試していただき、そのフィードバックを次の改修に生かします。

利用者が増えたり、対象の業務が広がったりしたときも、サーバーの増強や構成の見直しで対応できます。「小さく始めて、大きく育てる」進め方と相性のよい環境です。

FileMakerが向いていないケース

公平のために、向いていないケースも挙げておきます。

  • 不特定多数の人が同時に使う、大規模な一般向けのWebサービス
  • 数千人を超える利用者が同時に接続し続けるような規模

こうしたケースでは、別の開発手段を選ぶほうが適しています。私たちも、FileMakerにこだわるのではなく、FileMakerとAI駆動開発のどちらも選択肢として持ち、業務と規模に合わせて道具を選んでいます。

まとめ

  • 「時代遅れ」「遅い」と言われる原因の多くは、FileMakerではなくデータ設計の不足にある
  • FileMaker Server 2026 の技術仕様では、FileMaker Pro の同時接続はテスト済み 500、最大 2,000
  • 数百人が使う一気通貫の基幹システムや、1ライセンスから120ライセンスへ育った実例がある
  • 大規模でも遅くならないためには「データ中心の設計」「分離モデル」「データの性質ごとのファイル分割」「サーバー前提の開発」の4つが要になる

外部の開発会社に依頼するときの確認点は「FileMaker開発会社の選び方。依頼する前に確かめたい7つのこと」にまとめています。

リナークでは、今あるFileMakerの仕組みの見直しや、紙・Excelからの切り替えを、業務の整理から一緒に進めています。「社内でつくったFileMakerが遅くなってきた」「作った人がいなくなって手をつけられない」といった段階でもご相談いただけます。サービスの内容はサービス紹介を、ご相談はお問い合わせからどうぞ。

まず一つの仕事を書き出してみませんか。

きれいな資料にする必要はありません。紙やホワイトボードに、箱と矢印で書くだけでも構いません。システムを作るか決まっていない段階でも、業務整理から相談できます。

一つの受注、一つの製品、一つの業務について

  1. 誰が関わっているか
  2. 何を受け取っているか
  3. 何を見て判断しているか
  4. 結果をどこへ残しているか
  5. 次回に生かせる情報が残っているか