1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@fuji1009_REBELL(Fujisawa Yuta)

FileMakerの業務システムをClaude Codeでモダナイズする3つの実践パターン

1
Last updated at Posted at 2026-07-18

FileMakerで業務システムを作ってきた人間として、正直に書きます。FileMakerと生成AIの組み合わせについての情報は、ほとんどありません。Qiitaで「FileMaker × AI」を検索しても実装記事はごくわずかです。

一方で現場には、FileMakerで作られた業務システムが大量に生きています。顧客管理、在庫管理、帳票発行——「市販品では合わないが、フルスクラッチは高すぎる」領域を10年以上支えてきたのがFileMakerです。問題は、その周辺——外部連携・データ移行・集計クエリ——が属人化して塩漬けになりやすいこと。

この「周辺」こそ、Claude Codeが効く場所でした。本記事では、実際に運用している3つのパターンを、コードと再現手順つきで共有します。

まず前提: Claude CodeはFileMaker本体を直接編集できない

最初に限界をはっきりさせておきます。FileMakerのファイル（.fmp12）はバイナリで、Claude Codeが直接読み書きできません。スクリプトもレイアウトもGUIの中に閉じています。

なので戦略はこうなります。

領域 担当 理由
テーブル・レイアウト・帳票 FileMaker（人間がGUIで） FileMakerの独壇場。触らない
スクリプトの設計・ロジック Claude Codeに擬似コードで相談 → 人間がGUIに転記 直接編集不可のため往復する
外部連携（API・ゲートウェイ） Claude Codeでコード生成 普通のNode.js/Pythonの世界
データ移行・クレンジング Claude Codeでスクリプト生成 同上
ExecuteSQLの式 Claude Codeに書かせて貼り付け SQLはLLMの得意領域

つまり「FileMakerの中」はFileMakerに任せ、「FileMakerの外側」をClaude Codeで固める。この役割分担が答えです。以下、外側の3パターンを紹介します。

パターン1: Data API + APIゲートウェイで外部公開する

社内の在庫管理システム（FileMaker）のデータを、Webサイトからリアルタイム参照したいという要望がありました。FileMaker Serverを直接インターネットに晒すのはセキュリティ的に論外なので、FileMaker Data APIの手前にNode.jsのAPIゲートウェイを置く構成にしました。

まずData API単体の動きを押さえます。認証してセッショントークンを取り、そのトークンで検索を叩く2段構えです。

# 1. ログインしてセッショントークンを取得
curl -X POST "https://<server>/fmi/data/vLatest/databases/InventoryDB/sessions" \
  -H "Content-Type: application/json" \
  -u "apiuser:<password>" \
  -d "{}"
# → response.token にセッショントークンが返る

# 2. トークンで検索（_find）
curl -X POST "https://<server>/fmi/data/vLatest/databases/InventoryDB/layouts/api_inventory/_find" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"query":[{"item_code":"=A-1001"}],"limit":"10"}'

ここで注意が2つ。トークンはアイドルが続くと失効する仕様なので、再ログイン処理が必須です。また、Data APIに公開するレイアウトはAPI専用に最小フィールドで作ること。レイアウト上のフィールドが全部レスポンスに乗るため、既存の画面レイアウトを使い回すと不要なデータまで外に出ます。

ゲートウェイ本体はClaude Codeに作らせました。指示はこの程度で骨組みが出てきます。

FileMaker Data APIの手前に置くNode.js(Express)のAPIゲートウェイを書いて。
- POST /api/inventory/search を受けて Data API の _find に変換して転送
- Data APIのトークンはメモリに保持し、失効エラー時は自動で再ログインしてリトライ
- クライアント側はAPIキー認証。レート制限とレスポンスの60秒キャッシュも入れる
- サーバーURL・DB名・レイアウト名は環境変数で差し替え可能に

トークンの再取得やキャッシュはどのプロジェクトでも書く定型部分で、ここを自分で書かなくていいのは体感でかなり楽です。結果として、Webサイトからのリアルタイム在庫表示を実現しつつ、FileMaker Serverへの直接アクセスは完全に遮断できました。Data APIを使うときは直接公開せず、間にゲートウェイを一枚挟む——これが今のところのベストプラクティスだと考えています。

なお、Data APIはライセンス上のデータ転送量に上限があります。契約プランの範囲を事前に確認してください。

パターン2: レガシーデータの移行・クレンジングを自動化する

モダナイズで必ず発生するのがデータ移行です。Excelで管理されていた顧客データ5,000件をFileMakerに移行した案件では、列の対応関係が複雑で単純インポートでは通りませんでした。

やったことは2段階です。前処理はClaude Codeで生成したスクリプト、取り込みはFileMakerのインポートスクリプトという分担にしました。

前処理スクリプトへの指示はこうです。

Excelから書き出した customers.csv をFileMakerインポート用に前処理する
Pythonスクリプトを書いて。
- 全カラムの前後空白をトリム
- 電話番号のハイフン揺れ・全角混在を 0X-XXXX-XXXX 形式に正規化
- 会社名+電話番号でグルーピングし、重複候補は duplicates.csv に分離して出力
- 出力はUTF-8。処理件数と除外件数をログに出す

FileMaker側の取り込みは、スクリプトステップでこう組みます（擬似記述。実際はスクリプトワークスペースで組みます）。

# スクリプト: 顧客データ取込
エラー処理 [オン]
変数を設定 [$path; 値: Get(ドキュメントパス) & "customers_clean.csv"]
レコードのインポート [ダイアログなし; "$path"; 追加; フィールドマッピング指定]
If [Get(最終エラー) ≠ 0]
    カスタムダイアログを表示 ["取込失敗: エラー " & Get(最終エラー)]
    現在のスクリプト終了 [テキスト結果: "error"]
End If
スクリプト実行 [「取込後の重複最終チェック」]

結果、5,000件の移行は30分で完了。前処理の段階で重複候補45件を検出して統合できました。ここでの学びは、**移行は「運ぶ作業」ではなく「データを綺麗にするチャンス」**だということです。正規化と重複チェックを移行時に組み込んでおくと、新システムはゴミデータゼロの状態で始められます。この種の使い捨てクレンジングスクリプトは、まさにClaude Codeに書かせるのが割に合う仕事です。

パターン3: 重い集計をExecuteSQLに置き換える——SQLはClaude Codeに書かせる

10万レコードを超えたあたりから検索・集計が極端に遅くなったシステムがありました。原因の大半は非格納計算フィールドとサマリーフィールドの乱用です。インデックス整備とあわせて、集計をExecuteSQL関数に置き換えたところ、複数条件の検索が10秒→1秒になりました。別のシステムでは、手作業だった月次集計をスクリプト化して2時間→3分です。

ただしFileMakerのExecuteSQLには癖があります。プレースホルダは ?、日付の扱いが独特、フィールド名やテーブルオカレンス名に予約語や記号が入っていると引用符で括る必要がある——素で書くと大体一度はハマります。

ここもClaude Codeに任せます。スキーマ情報を渡して式ごと書かせるのがコツです。

FileMakerのExecuteSQL関数の式を書いて。
テーブルオカレンス: sales / フィールド: sales_date(日付), amount(数字), status(テキスト)
やりたいこと: $start〜$end の期間で status が "確定" の件数と金額合計
制約: プレースホルダ(?)を使う。引数は $start, $end で渡す

返ってきた式をカスタム関数か計算式に貼るだけです。

ExecuteSQL (
  "SELECT COUNT(*), SUM(amount)
   FROM sales
   WHERE sales_date >= ? AND sales_date < ? AND status = '確定'" ;
  "" ; "¶" ; $start ; $end
)

FileMaker開発者にはSQLに馴染みがない人も多く（自分もかつてそうでした）、ここがLLMで一番ショートカットできる部分だと感じています。逆にパフォーマンス改善そのものの定石——インデックスの整備と非格納計算フィールドの削減——はFileMaker側の作業なので、AIに聞くより先にこの2点を見直すべきです。大半はそれだけで劇的に改善します。

運用してみての注意点

  • 擬似コード往復のコストは残る: FileMakerスクリプトはGUIへの手動転記が必要です。それでも「設計をテキストでレビューできる」価値のほうが大きいというのが体感です。転記前提なら、最初から日本語のステップ名で書かせると速い。
  • 認証情報をプロンプトに入れない: Data APIのパスワードやトークンをClaude Codeへの指示文に貼らないこと。環境変数参照でコードを書かせ、値は自分で設定します。
  • 生成コードは必ず検証データで通す: 特にクレンジング系は、本番データに当てる前に件数の小さいサンプルで結果を目視確認しています。ここを省略したことは一度もありません。

まとめ: FileMakerの「外側」をAIで固める

FileMakerのモダナイズは「FileMakerを捨てる」ことではありません。GUIとデータベースはFileMakerに任せたまま、塩漬けになりがちな外側——外部連携・データ移行・SQL——をClaude Codeで固める。この分担なら、既存資産を活かしつつ確実に前に進めます。

  • 外部公開 → Data API + 生成させたAPIゲートウェイ
  • データ移行 → クレンジングスクリプトを生成させ、取込はFileMakerスクリプト
  • 重い集計 → ExecuteSQLへの置き換え、式はLLMに書かせる

FileMaker × AIの情報はまだ少ない領域です。同じ構成で運用している方がいたら、知見をコメントで交換できると嬉しいです。

関連記事

ローコード×Claude Codeの組み合わせでは、こちらも同じ発想で書いています。

この記事が参考になったら、いいね・ストック していただけると励みになります。

Claude Code・AIエージェント・業務自動化の実装Tipsを継続的に発信しています。
@fuji1009_REBELL をフォロー しておくと、新着記事が届きます。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?