Article

Claris FileMakerで業務システム構築

高田晃太郎
Claris FileMakerで業務システム構築

Gartnerは2025年までに新規業務アプリの約70%がローコードで構築されると予測している[1]。開発需要は右肩上がりなのに、エンジニアの供給は追いつかない。公開レポートや多くの現場事例を俯瞰すると、要件定義から初期リリースまでのリードタイム短縮と、業務部門の自律的改善能力の獲得が成果の分水嶺になっていると言える。ローコード基盤の選定は、速度、安全性、将来の拡張性という相反しやすい要件の最適点をどこに置くかの経営判断だ。また、ローコード開発テクノロジへの世界支出は2026年までに445億ドルへ拡大する見通しであり[2]、選定の重要性はさらに増している。ここで取り上げるClaris FileMakerは、データモデルと画面、スクリプトが有機的に結びつき、現場の“いま不便な作業”を数日でアプリに変える。しかもData API(RESTベースのWeb API)やJavaScript連携で既存システムとつながる設計が可能だ[7,9]。現場に寄り添うスピードと、エンタープライズ連携の堅牢さを両立したいCTOやエンジニアリーダーにとって、内製化による業務改善とシステム効率化を同時に進める現実解になりうる。

なぜFileMakerか――速度・統制・拡張性のバランス

FileMakerプラットフォームは、クライアントであるFileMaker Pro/Go(Windows/Mac/iOS用アプリ)と、オンプレミスまたはクラウドのFileMaker Serverで構成される[3]。画面レイアウト、テーブル定義、スクリプトは一体的に管理され、要件の変化に応じた反復が速い。セキュリティはアカウントと権限セット、SSL、外部認証(OAuth:外部IDプロバイダによる認証)に対応し、運用で求められる監査とバックアップもサーバー標準機能で賄える[4–6]。拡張性の観点では、RESTベースのFileMaker Data API、ODBC/JDBC(外部DB接続)、WebViewerのJavaScript連携(埋め込みWebの双方向通信)、サーバースクリプトによるバッチ処理という四つの接点を押さえるとよい[7,8,9,10]。スモールスタート(小さく始めて素早く学ぶ)から段階的拡張がしやすく、既存の基幹やSaaSと疎結合につなぎ込めるからだ。

アーキテクチャ上の勘所は、データとプレゼンテーションの分離、リレーションの意図的な最小化、レイアウトの軽量化にある。まず業務語彙に即した正規化テーブル群を定義し、ユースケース単位でレイアウトを設計する。次に、一覧と詳細を分離し、検索や並び替えはサーバーに寄せる。最後に、集計や整形は計算式に閉じ込め、スクリプトではフロー制御と例外処理に集中する。これだけでも体感性能は大きく変わる。現場の改善サイクルに耐える速度が、継続的な業務改善の土台になる。

データモデルとUIの分離で変化に強くする

レイアウトは役割ごとに最小限のフィールドだけを置き、関連テーブルへの参照は必要な時だけ評価する。検索専用レイアウトを用意し、ユーザー操作のたびに全計算が走る構成は避ける。ExecuteSQL関数(FileMaker内部からSQLで“読み取り”を行う関数)は“読み取りの最適化”に割り切り、更新はスクリプトで明示的に行う[11]。これにより、要件変更時の影響範囲が局所化し、リリースの粒度を小さく保てる。

設計と実装の標準プロセス――プロトタイプから本番化

プロジェクトは、ドメインの共通語彙を整えることから始める。紙帳票やExcelの列名を写経するのではなく、現場で使う名詞だけを抽出し、エンティティと関係を言語化する。モデルが固まれば、最低限のテーブルとキー、リレーションを定義し、一覧と詳細の二つのレイアウトを作る。ここまでを一週間で反復し(短いスプリントで学習を早める)、現場の実データで手触りを確かめる。反復が進んだら、権限セット、バックアップ、ログ監査を整備して本番化する[6]。

スクリプトはフロー制御と例外処理に集中させる

FileMakerのスクリプトは、人が読むことを前提にした制御フローが要だ。Set Error Captureを有効にし、例外は専用テーブルに記録する。重い計算や大量更新はサーバー側で実行し、クライアントはノンブロッキングにする。たとえば受注確定時に在庫更新と通知を同時に走らせるなら、Perform Script On Server(サーバー側でスクリプトを非同期実行)でキューに積む構造が安全だ[10]。

計算式とJSONで疎結合に保つ

画面とロジックの結合を弱めるために、JSON(汎用のデータ交換フォーマット)を中間表現に使うと拡張に強い。FileMakerのJSON関数は、データの受け渡しに十分な表現力を持つ[12,13]。

// 注文データをJSON化してサーバースクリプトへ渡す例
Let(
  [
    payload = JSONSetElement("{}"
      ; ["orderId"; Orders::id; 1]
      ; ["customer"; Customers::name; 1]
      ; ["lines"; JSONListValues( LineItems::json ); 4]
    )
  ];
  PerformScriptOnServer ( "ProcessOrder" ; payload )
)

サーバー側で受け取ったJSONは、検証後に各テーブルへ分配する。受け渡しがJSONである限り、Webやバッチ、外部システムとのやり取りもコストが増えにくい。

連携で広がる適用範囲――Data APIとJavaScript

既存システムとの連携は、FileMaker Data APIが中核になる。認証はセッションベースのBearerトークンで、REST(HTTPを用いたAPI設計)の作法に準じている[7]。認証から検索までの最小例を示す。

Data APIの認証と検索の最小例

# 認証してトークンを取得
curl -s -X POST \
  https://example.com/fmi/data/vLatest/databases/YourDB/sessions \
  -H 'Content-Type: application/json' \
  -u 'api_user:secret' | jq -r '.response.token'
# トークンを使って検索
TOKEN="<上で取得したトークン>"
curl -s -X POST \
  https://example.com/fmi/data/vLatest/databases/YourDB/layouts/Orders/_find \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"query":[{"Status":"Open"}],"limit":100}' | jq '.response.data | length'

業務改善の現場では、サーバー間の夜間バッチやSaaS連携が定番だ。Pythonでの実装は短いコードで書ける。例外時にはFileMaker側にエラーログを残す設計にすると、一次切り分けが速い。

import requests
from typing import Dict

BASE = "https://example.com/fmi/data/vLatest/databases/YourDB"
USER = "api_user"
PASS = "secret"

class FMError(Exception):
    pass

def login() -> str:
    r = requests.post(f"{BASE}/sessions", auth=(USER, PASS), json={})
    r.raise_for_status()
    messages = r.json().get("messages", [])
    if messages and messages[0].get("code") != "0":
        raise FMError(messages[0].get("message"))
    return r.json()["response"]["token"]

def find_open_orders(token: str) -> Dict:
    headers = {"Authorization": f"Bearer {token}"}
    payload = {"query": [{"Status": "Open"}], "limit": 100}
    r = requests.post(f"{BASE}/layouts/Orders/_find", headers=headers, json=payload)
    r.raise_for_status()
    return r.json()["response"]["data"]

if __name__ == "__main__":
    try:
        t = login()
        orders = find_open_orders(t)
        print(f"open orders: {len(orders)}")
    except (requests.HTTPError, FMError) as e:
        # FileMaker側のログエンドポイントへ通知する設計にしておく
        print(f"error: {e}")

WebViewerとJavaScriptの連携は、ユーザー体験の改善に効く。たとえばグラフ描画をJavaScriptライブラリに任せ、操作結果をFileMakerスクリプトへ返す[9]。

<!-- WebViewer内 -->
<div id="chart"></div>
<script src="https://cdn.jsdelivr.net/npm/chart.js"></script>
<script>
  function notifyFM(payload){
    if(window.FileMaker && window.FileMaker.PerformScript){
      window.FileMaker.PerformScript('HandleChartEvent', JSON.stringify(payload));
    }
  }
  const ctx = document.getElementById('chart');
  const chart = new Chart(ctx, { type: 'bar', data: {/*...*/}, options: {/*...*/} });
  ctx.onclick = function(){ notifyFM({ event: 'clicked', ts: Date.now() }); };
</script>

FileMaker内部でのデータ整形は、JSON関数とExecuteSQLを組み合わせると表現力が高い。読み取り最適化に徹し、更新系はスクリプトで担保するのが作法だ[11–13]。

// SQLで集計値を取得(読み取り専用)
Let(
  [ status = "Open";
    rows = ExecuteSQL(
      "SELECT Customer, SUM(Amount) FROM Orders WHERE Status = ? GROUP BY Customer";
      Char(9);
      Char(10);
      status
    )
  ];
  rows
)

外部SaaSとの連携でも、JSONは中間表現として有効だ。取得したレスポンスから値を安全に抜き出す例を示す[13]。

// JSONレスポンスから安全に値を取得
Let(
  [ j = API::responseJSON;
    total = GetAsNumber( JSONGetElement(j; "summary.total") );
    name = JSONGetElement(j; "data[0].name")
  ];
  If ( total > 0 ; name ; "" )
)

品質・パフォーマンス・運用――計測できる改善サイクルを作る

業務システムは作って終わりではない。計測し、改善し続けられるかが成果を分ける。パフォーマンスは、レイアウトの初期表示時間、検索の応答時間、サーバースクリプトの実行時間という三つの軸で観測すると原因切り分けが速い。特にデータ件数の増加や同時接続が増えた時に劣化しやすい箇所を事前に押さえておくと、将来のコストが下がる。クライアント側では不要な集計オブジェクトを減らし、関連の自動更新を避ける。サーバー側ではインデックス設計と検索条件の見直しが効きやすい。バッチはPerform Script On Serverで並列度を調整し、トランザクション単位を小さく保つ[10]。

外部からの負荷計測は、Data APIを対象に行うと再現性が高い[7]。環境を固定し、同一レイアウトの同一クエリを連続実行してレイテンシ(応答遅延)の分布を取る。応答時間の中央値、p95(95パーセンタイル)、スループットを記録し、変更ごとに比較する。以下はwrkでの実行例だ。

# 認証トークンは事前取得済みとする
wrk -t4 -c32 -d60s --latency \
  -H "Authorization: Bearer $TOKEN" \
  -s ./scripts/find_open_orders.lua \
  https://example.com/fmi/data/vLatest/databases/YourDB/layouts/Orders/_find

スクリプトの品質はログで担保する。例外は一元化したログテーブルに記録し、ユーザーやレイアウト、スクリプト名、エラーコード、スタック風の文脈を残す。日次でサマリを作り、失敗の多い操作から順にテストケースを追加する。運用面では、バックアップと検証の自動化が重要だ。開発版はクローンを使ってスキーマだけを運び、本番データはサーバーの復元手順で守る。スキーマ差分の記録、移行時の手順書、ロールバックポイントの明確化は、属人化を防ぐ最後の砦になる[6]。

費用対効果は初期反復の速さに直結する。要件の半分を満たすプロトタイプを一週間で出し、現場のフィードバックを反映しながら二週間で業務運用に乗せる。以降は週次で小さなリリースを重ね、三ヶ月で“やめる、残す、作り直す”の見極めをする。スクラッチ開発で膨らみがちな要件を、手触りで削ぎ落とせることがローコード開発の最大の価値だ。リスクとしてはベンダーロックインが挙がるが、Data APIとODBCの二つの脱出口を常に開けておけば、将来の再実装コストは見通しやすい範囲に収まる[7,8]。

運用自動化と管理APIの活用

FileMaker Serverの管理APIは、スケジュールやクライアント情報の取得に使える。外部監視と連動させれば、障害検知から一次対応までを自動化できる[14]。

# 管理APIでスケジュール一覧(例)
curl -s -X POST https://example.com/admin/api/v2/user/login \
  -H 'Content-Type: application/json' \
  -d '{"user":"admin","password":"secret"}' | jq -r '.token' > admin.token
TOKEN=$(cat admin.token)
curl -s -H "Authorization: Bearer $TOKEN" \
  https://example.com/admin/api/v2/schedules | jq '.data | length'

導入の進め方と意思決定――現場と経営を一枚岩にする

CTOやエンジニアリーダーが悩むのは、適用範囲の線引きと投資規模だ。第一段階では、現場の紙やExcelで回る業務を対象にし、システム部門が伴走する内製体制を作る。第二段階では、SaaSや基幹との連携を広げ、データの一元化と共通マスタを整える。第三段階で、監査、可観測性、BCPを強化し、全社プラットフォームとしての運用を安定させる。いずれの段階でも、成果を可視化できるKPIを置くことが重要だ。たとえば、入力所要時間の短縮、エラー率の低下、承認リードタイムの短縮、データ再利用による二重入力の削減といった具体的な指標である。投資判断は、短い反復で手戻りを最小化できるか、既存資産と疎結合に保てるか、将来の出口を確保できているかという三つの観点で行うとブレにくい。

意思決定を支える材料として、比較検討の視点を挙げておく。汎用ローコードと比べた時のFileMakerの強みは、オンサイトでのプロトタイピング速度と、ネイティブクライアントの操作性だ。逆に、広域分散や極端な高トラフィック、ミッションクリティカルな勘定系のような領域では、専門特化のPaaSやフルスクラッチの方が適する場合がある。最適な適材適所を見極め、使い分けのルールを明文化しておくと、組織全体の開発生産性は安定して伸びる。

まとめ――“いま困っている仕事”から始める

開発のボトルネックが慢性化するほど、現場は工夫をやめ、非公式なツールが林立する。Claris FileMakerは、その溝を埋める現実的な橋になる。小さな業務改善をすばやくアプリに変え、効果が見えたところから段階的に広げる。Data APIとJavaScriptで既存システムとつなげれば、内製と全社システムは対立しない[7,9]。速度と統制のバランスを取りながら、組織の学習スピードそのものを上げていける。あなたのチームが最初に変えたい“いま困っている仕事”は何か。今日から一週間で、プロトタイプを形にする計画を作ってほしい。初速の一歩が、業務改善とシステム効率化の循環を生む。

参考文献

  1. Gartner Press Release: Gartner Forecasts Worldwide Low-Code Development Technologies Market to Grow 20% in 2023. https://www.gartner.com/en/newsroom/press-releases/2023-01-31-gartner-forecasts-worldwide-low-code-development-technologies-market-to-grow-20-percent-in-2023
  2. ガートナー プレスリリース(日本語): ローコード開発テクノロジに対する世界の支出は、2026年までに445億ドルまで拡大するとGartnerは予測. https://www.gartner.co.jp/ja/newsroom/press-releases/pr-20230613
  3. Claris FileMaker 製品概要(英語): Develop and deploy modern, extensible apps that integrate with the rest of your tech stack. https://content.claris.com/claris_filemaker_lp_en
  4. Claris Server Help: Configuring OAuth identity providers. https://help.claris.com/en/server-help/content/config-auth-oauth.html
  5. Claris Server Installation and Configuration Guide (Archive): Requesting an SSL certificate. https://help.claris.com/archive/fm19/en/server-installation-configuration-guide/content/requesting-ssl-certificate.html
  6. Claris Server Installation and Configuration Guide: Backing up databases. https://help.claris.com/en/server-installation-configuration-guide/content/backing-up-databases.html
  7. Claris FileMaker Data API Guide: Authentication and usage. https://help.claris.com/en/data-api-guide/
  8. FileMaker Pro Help (Archive): ODBC and JDBC. https://v-fmhelp.filemaker.com/archive/help/18/fmp/en/FMP_Help/odbc-jdbc.html
  9. FileMaker Pro Help: Calling scripts from a web viewer. https://help.claris.com/en/pro-help/content/calling-scripts-from-a-web-viewer.html
  10. FileMaker Pro Help: Perform Script On Server script step. https://help.claris.com/en/pro-help/content/perform-script-on-server.html
  11. FileMaker Pro Help: ExecuteSQL function. https://help.claris.com/en/pro-help/content/executesql.html
  12. FileMaker Pro Help: JSONSetElement function. https://help.claris.com/en/pro-help/content/jsonsetelement.html
  13. FileMaker Pro Help: JSONGetElement function. https://help.claris.com/en/pro-help/content/jsongetelement.html
  14. Claris FileMaker Server Admin API: Overview. https://help.claris.com/en/server-admin-api/content/overview.html