# Claude Code で FileMaker 開発：ODBC で実データを AI に読ませる

- 公開日: 2026-09-15
- 更新日: 2026-09-15
- URL: https://systemdesignworks.co.jp/news/filemaker-claude-code-odbc-data
- 発行: 株式会社システムデザインワークス

> DDR で設計を読み、XML で書き戻せるようになっても、「このフィールドには実際どんな値が入っているのか」は DDR のどこにも書かれていません。FileMaker の ODBC(xDBC)接続を使い、Claude Code が SQL で実データを直接確かめられる環境を作りました。基本構成は FileMaker Server にホストされたファイルへ開発機から直接つなぐ形で、Server が無ければ手元の FileMaker Pro でも同じ手順で動きます。文字化け・プロセス即死・権限エラーなど実機で確認した 5 つの落とし穴、バグ調査・全テーブルの CSV 書き出し・リプレース時のデータ移行への応用、Data API との使い分け、実データを AI に渡すときの注意点を、連載最終回としてまとめます。

こんにちは！システムデザインワークスの山岸です。

FileMaker に溜まった実データを AI に直接読ませて、確認や集計を任せられたら、と考えている方は多いのではないでしょうか。

連載の[第 1 回](/news/filemaker-claude-code-ddr-reading)で FileMaker の設計情報を DDR（データベースデザインレポート）で XML に出して Claude Code（Anthropic 社の AI コーディングツール）に読ませ、[第 2 回](/news/filemaker-claude-code-script-xml)で AI が書いたスクリプトを FileMaker に書き戻せるようになりました。ここまでで、FileMaker はかなり「AI と一緒に開発できる」環境になっています。

それでも、開発を進めるうちに必ずぶつかる質問があります。「このフィールド、実際にはどんな値が入っているの?」。数量に小数は入るのか。この名称フィールドは空欄が多いのか。使われなくなったマスタの行にも、コードは入っているのか。DDR はあくまで**設計図**であって、**中身**は載っていません。CSV に書き出して渡すことはできますが、AI が疑問を持った瞬間に自分で確かめられる経路は、これまでありませんでした。

答えは **ODBC** でした。ODBC（Open Database Connectivity）は、アプリケーションが種類の異なるデータベースに共通の手順で接続するための標準規格で、FileMaker はこの規格の「接続先」になれます。FileMaker はこれを xDBC（ODBC / JDBC）と呼び、外部から SQL を実行する機能として提供しています。これを使えば Claude Code は「SELECT を投げて確かめる」という、データベース開発ではごく当たり前の動きができるようになります。

検証の結論も第 1・2 回と同じで、**実データの確認でも AI は FileMaker 開発に活用できます。** 要点を先にまとめます。

1. **FileMaker は ODBC で SQL 直参照できる。** FileMaker Server の Admin Console で ODBC/JDBC を有効にすれば、開発機からサーバー上のファイルに直接 SQL を打てる。Server が無くても、手元の FileMaker Pro で開いたファイルに同じ手順でつなげる（同じマシンからのみ）
2. **設定の落とし穴は 5 つ。**
3. **使い道は「確かめる」だけではない。** バグ調査、全テーブルの CSV 書き出し、他のプラットフォームへのリプレース時のデータ移行にも同じ経路が使える
4. **Data API と使い分ける。** 両経路で同じ結果になることは実証済み
5. **AI には「必要な列だけ、集計と数行」を渡す。** 実データを扱う以上、渡し方には規律を持つ

---

**この連載はこんな方に向けて書いています**

- FileMaker で業務システムを開発・保守しているエンジニアや、社内の情報システム担当の方
- FileMaker のデータを、他のシステムや AI から直接参照したい方
- Claude Code などの生成 AI を FileMaker 開発に取り入れたいが、何から始めればよいか分からない方

FileMaker Pro の基本操作は分かっている前提で書いていますが、主要な用語は本文で一言ずつ補足します。

**Claude Code で FileMaker 開発（全 3 回）**

1. [第 1 回：DDR で設計を AI に読ませる](/news/filemaker-claude-code-ddr-reading)
2. [第 2 回：AI にスクリプトを書かせる](/news/filemaker-claude-code-script-xml)
3. **第 3 回：ODBC で実データを AI に読ませる（本記事）**

---

## 背景・課題：DDR には「値の実態」が無い

設計情報だけで開発を進めると、こういうことが起きます。

- **仕様書にも DDR にも「整数」と書いていない数量フィールドに、小数が入っていた。** 整数前提で書いた計算式やスクリプトが、実データで弾かれる
- **名称フィールドが空欄で、上位分類の名称しか入っていない行が大量にあった。** 画面には表示されているので、誰も空欄だと思っていない
- **使われなくなったマスタの行ではコードが空だった。** コードが一意である前提の処理が止まる

いずれも、DDR を読み込んだ Claude Code が「設計上はこうなっているはず」と推測し、実データで裏切られたケースです。AI の推測が間違っていたのではなく、**推測しか材料が無かった**ことが問題でした。第 2 回の方法で書いたスクリプトの計算式が想定外の値でエラーになる、という形で、改修でも移行でも同じように起きます。

FileMaker にはデータを外部から取る手段として **Data API**（REST）があります。ただし Data API はレイアウト経由の仕組みで、取りたいフィールドがレイアウトに置かれていなければ取れず、日付は既定で `MM/DD/YYYY` で返り、セッション（トークン）の管理も要ります。「ちょっと確かめたい」用途には重い。もっと直接、テーブルに SQL を打ちたい。それが ODBC を選んだ理由です。

## 取り組みの概要：開発機から FileMaker Server へ直接つなぐ ODBC 構成

基本の構成は、FileMaker Server にホストされたファイルへ、開発者の Mac から ODBC でつなぐ形です。Claude Code → 小さな CLI → ODBC ドライバ → ネットワーク（ポート 2399）→ FileMaker Server、という経路になります。FileMaker Server 側では Admin Console で ODBC/JDBC を有効にし、ファイル側では接続用アカウントに拡張アクセス権を付けます。

```mermaid
flowchart LR
    A["Claude Code"] -->|"SQL を渡す"| B["疎通・任意 SQL の CLI<br/>（node-odbc）"]
    B --> C["unixODBC<br/>ドライバマネージャ"]
    C --> D["FileMaker ODBC ドライバ<br/>/Library/ODBC"]
    D -->|"TCP 2399（社内 LAN / VPN）"| E["FileMaker Server<br/>Admin Console で ODBC/JDBC を有効"]
    D -.->|"同じ手順で localhost:2399"| F["FileMaker Pro 単体<br/>手元で開いた複製に ODBC/JDBC 共有 ON"]
```

FileMaker Server が無い場合や、本番の複製を手元で試したい場合は、**FileMaker Pro 単体でも同じ手順が使えます**。ファイルを開いた Pro が自分自身でポート 2399 の接続を待ち受けるので、接続先を `localhost` にするだけで、ドライバもコードもそのまま動きます。ただし Pro の共有は同じマシンからの接続に限られ、最大 5 接続です。別のマシンからつなぐなら Server が必要で、これが Server を基本構成にしている理由でもあります。

## ① セットアップ：4 つをそろえる

そろえるものは 4 つです。

**FileMaker Server 側。** 対象ファイルをホストした状態で、Admin Console の [コネクタ]（Connectors）> [ODBC/JDBC] を有効にします（画面構成は FileMaker Server のバージョンで異なります）。次に、接続に使うアカウントのアクセス権セットに、拡張アクセス権 `fmxdbc`**（ODBC/JDBC によるアクセス）** を付けます。これが無いと、Admin Console で有効にしていても、ユーザー名とパスワードが正しくても接続を拒否されます。接続用のアカウントは閲覧のみのアクセス権セットにしておくと安全です。複数ファイルで構成されたシステムなら、参照するすべてのファイルにこの拡張アクセス権が要り、同じ Server にホストされている必要があります。

FileMaker Server が無い場合は、FileMaker Pro で対象ファイルを開き、[ファイル] メニュー → [共有設定] → [ODBC/JDBC を有効にする...] で [ODBC/JDBC 共有] を [オン] にします。拡張アクセス権の要件は同じです。接続できるのはファイルを開いている間だけなので、作業中は FileMaker Pro を開いたままにします。

**ネットワーク。** 開発機から Server の TCP 2399 番ポートに届く必要があります。社内 LAN や VPN の内側からつなぐのが基本で、インターネット側から開ける場合は期間と送信元 IP を絞ります。ODBC の設定を疑う前に、まず `nc -vz <サーバーのホスト名> 2399` で到達を確かめます。

**クライアント側ドライバ。** ドライバマネージャの unixODBC を Homebrew で入れ、Claris が提供する xDBC クライアントドライバ（FileMaker Pro / Server のインストーラに同梱の xDBC フォルダ、または Claris のダウンロードページから入手）を入れます。ドライバは `/Library/ODBC` 配下に登録されます。

```typescript
brew install unixodbc
# Claris の xDBC クライアントドライバ (.pkg) を実行すると次が配置される
#   /Library/ODBC/FileMaker ODBC.bundle/Contents/MacOS/fmodbc.so
#   /Library/ODBC/odbcinst.ini
```

**アプリ側。** Node の `odbc` パッケージ（node-odbc）で接続します。DSN を登録しなくても、接続文字列だけで繋がります。

```typescript
DRIVER={FileMaker ODBC};Server=<サーバーのホスト名>;Port=2399;Database=<ファイル名>;UID=<アカウント>;PWD=<パスワード>;MultiByteEncoding=UTF-8
```

`Server=` は FileMaker Server のホスト名（Pro 単体なら `localhost`）、`Database=` は `.fmp12` を除いたファイル名です。この接続文字列を組み立てて任意の SQL を実行し、結果と所要時間を返す小さな CLI を Claude Code に作らせました。失敗したときは SQLSTATE を見て「ドライバ未導入」「共有 OFF か到達不能」「認証・権限」のどれかを示すようにしています。接続まわりの落とし穴（次の ② の 1・4・5）は SQLSTATE で見分けられるからです。

## ② 落とし穴は 5 つ

セットアップの説明より、こちらのほうが価値があると思います。いずれも実機で再現した症状で、原因と対処を表にまとめました。

| # | 症状 | 原因と対処 |
| --- | --- | --- |
| 1 | `IM002`（ドライバまたは DSN が見つからない） | Homebrew の unixODBC は既定で別の場所の設定を見る。FileMaker ドライバの登録先を教えるため、実行時に環境変数 `ODBCSYSINI=/Library/ODBC` を渡す |
| 2 | 日本語が全部 `�`（U+FFFD）になる | 接続文字列に `MultiByteEncoding=UTF-8` が無いと、ドライバが既定の文字コード（UTF-8 ではない）で文字を返し、Node 側が UTF-8 として読んで壊れる。**復元不能**なので必ず付ける |
| 3 | `SELECT *` や存在しない列を指定すると、node-odbc 経由では **Node のプロセスが即死**（SIGABRT） | エラーではなくクラッシュする。列は DDR で実在を確認したものだけを明示する。第 2 回で作った DDR の索引がここでも効く |
| 4 | `28000`（認証・権限エラー） | パスワードは正しいのに拒否される場合、アカウントに `fmxdbc` 拡張アクセス権が無い |
| 5 | `08001`（接続できない） | ポート 2399 に届いていない、Server 側の ODBC/JDBC が有効になっていない、あるいは接続先のホスト名が違う。ODBC の前にまず `nc -vz <ホスト名> 2399` で TCP 到達を確かめる。タイムアウトならファイアウォールや VPN、接続拒否なら Admin Console の ODBC/JDBC 設定（Pro 単体なら共有設定）を疑う |

細かい点として、テーブル名や列名に日本語を使っている場合、SQL では **ダブルクォートで括る**必要があります（`SELECT "主キー" FROM "mst商品"`）。FileMaker の SQL 方言（`FETCH FIRST n ROWS ONLY` など）は、第 1 回で紹介した claris-docs プラグインの `sql-reference` スキル（Claude Code に手順を教える単位）で公式リファレンスを引けます。ここでもプラグインが働いてくれました。

## ③ Claude Code に実データを「確かめさせる」

環境ができると、開発の進め方が変わります。Claude Code は DDR で設計を読んだあと、疑問が出た時点で自分から SQL を投げて確かめます。「背景・課題」で挙げた 3 つの例は、こうして解決します。

```typescript
数量に整数以外の値はあるか?
→ SELECT "数量", COUNT(*) FROM "dat受注明細" GROUP BY "数量"
→ 小数の値が存在。整数限定の処理をやめ、小数を許容する形に修正

商品名が空の行はどれくらいあるか?
→ SELECT COUNT(*) FROM "mst商品" WHERE "商品名" IS NULL OR "商品名" = ''
→ 名称が空で分類名だけ入っている行が多い。商品名 → 分類名の順で採用するフォールバックに

取引を停止した取引先のコードは入っているか?
→ SELECT COUNT(*) FROM "mst取引先" WHERE ("取引先コード" IS NULL OR "取引先コード" = '') AND "取引停止日" IS NOT NULL
→ 停止済みの行では空。一意になるよう内部 ID から補完するルールに
```

（テーブル名・列名・結果は、実物を伏せた例です）

ポイントは、**推測が事実確認に変わった**ことです。DDR（設計）と ODBC（実態）を往復できるようになると、Claude Code は「仕様書にこう書いてあります」ではなく「実データを見ると、こうなっています」と答えます。

## ④ 使い道は「確かめる」だけではない

SQL を打てる状態ができると、開発中の確認以外にも同じ経路がそのまま使えます。代表的な使い道を 3 つ挙げます。

**バグ調査。** 「この伝票だけ金額が合わない」「特定の月だけ集計がずれる」といった報告は、FileMaker の画面で 1 件ずつ検索して追うと時間がかかります。SQL なら、該当レコードとその明細を一度に取り出し、同じ条件に当たるレコードが他に何件あるかまで数えられます。その件数がそのまま影響範囲になるので、直す優先度も決めやすくなります。Claude Code に任せると、DDR で読んだ条件と実データの差から原因の候補を挙げてきます。

**全テーブルの CSV 書き出し。** FileMaker の画面からの書き出しはテーブルごとの手作業で、テーブルが 100 を超えると現実的ではありません。ODBC なら、システムテーブル `FileMaker_Tables` でテーブルの一覧を取り、テーブルごとに SELECT した結果を CSV に書くスクリプトを 1 本用意すれば、全テーブルを一括で書き出せます。

```typescript
SELECT TableName, BaseTableName FROM FileMaker_Tables
```

`FileMaker_Tables` はテーブルオカレンス単位の一覧で、SQL の FROM に書くのもテーブルオカレンス名です。そのため BaseTableName でベーステーブルごとに 1 つを選び、列は第 2 回の DDR の索引から組み立てて必ず明示します（node-odbc 経由では `SELECT *` でプロセスが落ちるためです）。システムテーブル `FileMaker_Fields` でも列名は取れますが、日本語の列名が文字化けすることがあるため、私たちは DDR を正本にしています。別システムへの取り込み、引き継ぎや監査のためのスナップショット、集計・分析の元データなど、ここから始められる作業は多いです。

**他のプラットフォームへのリプレース時のデータ移行。** FileMaker から Web アプリケーション（PostgreSQL など）へ作り替える場面では、ODBC で読んだ行をそのまま移行先に書き込む取り込み処理が組めます。CSV を経由しないので、書き出しと取り込みの間で文字コードや日付書式が崩れる余地がありません。進め方は、DDR でフィールドの型と役割を読み、ODBC で実データの分布を確かめて取り込み時のエラーの芽を先に潰し、そのうえで Claude Code に移行先スキーマとの対応表と変換処理を書かせる、という順序です。移行後は、移行元の FileMaker と移行先のデータベースで `COUNT(*)` を並べて比べます。これが SQL 一発でできると、「入ったはず」が「入った」になります。私たちは件数に加えて、行単位で移行先と値を比較する突合処理も用意しています。

## ⑤ Data API との使い分け — 同じ結果が出ることを確かめてから

ODBC を導入しても、Data API を捨てたわけではありません。ODBC はドライバを入れた開発機から使うものですが、Data API は FileMaker Server があれば HTTPS でどこからでも呼べ、Web アプリケーションやサーバー上の自動処理からのアクセスに向いています（Linux 向けの純正 ODBC ドライバは提供されていません）。両方を使う以上、同じデータを読んだときに同じ結果になることを確かめておく必要があります。そこで、**④ の突合処理を Data API 経路と ODBC 経路の両方で実行し、結果が一致するか**を確かめました。

| 項目 | Data API | ODBC |
| --- | --- | --- |
| 取得元 | レイアウト経由 | ベーステーブルを直接 |
| 取りたい列 | レイアウトに置く必要がある | SQL で指定するだけ |
| 日付の書式 | 既定は `MM/DD/YYYY`（`dateformats=2` で ISO 8601 も可） | `YYYY-MM-DD` |
| 認証 | セッション（トークン）を取得して管理する | 接続を張って使い回す |
| 動く環境 | FileMaker Server / Claris Cloud が必要。クライアントはどこからでも（HTTPS） | FileMaker Server でも Pro 単体でも。クライアントはドライバを導入し、2399 番に届く開発機（macOS / Windows） |
| 主な用途 | アプリケーションや自動処理からのアクセス | 開発者の手元での調査・移行・裏取り |

日付書式の差だけを正規化したうえで、同じテーブルの 12 か月分のレコードを両経路で処理したところ、取得時刻を除く**全項目がバイト一致**しました。これで「ODBC で確かめた結果は Data API でも同じ」と言い切れるようになり、アプリケーションや自動処理は Data API、手元の裏取りは ODBC、という分担に落ち着きました。

## ⑥ 実データを AI に渡すときの規律

ここまで来て避けて通れないのが、実データを AI ツールに見せることへの向き合い方です。第 1 回で書いたとおり、弊社は Claude Code を**データが学習に使われない設定**で運用していますが、それだけでは足りません。次の規律を決めています。

- **本番サーバーの 2399 番をインターネットに開けない。** 社内 LAN や VPN の内側からだけ届くようにし、外から開ける必要があるなら期間と送信元 IP を絞る。試したいだけなら、複製をホストした検証用サーバーか、手元の FileMaker Pro で開いた複製につなぐ
- **必要な列だけを SELECT する。** `SELECT *` はプロセスが落ちるという実害もあるが、そもそも氏名や連絡先を取る必要のない質問がほとんど。列を明示する習慣は安全にも効く
- **AI に渡すのは集計値と数行のサンプル。** 分布・件数・空欄率で答えが出る質問に、全行を見せる理由はない
- **ログと成果物に残さない。** 接続文字列のパスワードはログ出力前にマスクし、取得した実データを置くディレクトリはバージョン管理から除外する

実データにアクセスできる力は、開発の精度を上げると同時に、扱いを誤れば最も大きな事故につながります。「できる」と「やってよい」の間に規律を置くことが、この手法を業務で使う条件だと考えています。

## 結果：読む・書く・確かめる、がそろった

3 回の連載で、FileMaker の開発に Claude Code を組み込む 3 つの経路がそろいました。

| 回 | 経路 | AI ができるようになったこと |
| --- | --- | --- |
| 第 1 回 | DDR → XML → 分割 | 設計を**読む**。画面・スクリプト・リレーションを横断して調査する |
| 第 2 回 | XML → クリップボード → ⌘V | スクリプトを**書く**。検証済みの XML を人が貼るだけで入る |
| 第 3 回 | ODBC → SQL | 実データを**確かめる**・**取り出す**。推測を事実確認に変え、バグ調査や移行の土台になる |

第 1 回の冒頭で立てた問い、「AI は FileMaker 開発に活用できるのか」への答えは、はっきりと「できる」です。設計を読み、スクリプトを書き戻し、実データで確かめる。この 3 つがそろえば、調査と実装の大半を占めるスクリプト周りの開発は、Web 開発に近い進め方で AI と進められます。レイアウト設計やリレーションシップグラフ、アクセス権の設定といった GUI 中心の作業は残りますが、そこは元々 FileMaker が得意とする部分です。

FileMaker は長く「AI と相性の悪い環境」と見られてきました。バイナリで、GUI でしか触れず、ソースコードが無い。しかし、DDR・クリップボード・ODBC という FileMaker が元々持っている 3 つの出入口を使えば、AI と一緒に開発できる環境は自分たちの手で作れます。FileMaker 側に追加するものは何も要りません（手元に置く小さな自作ツールは要りますが、いずれも数百行です）。必要なのは、出入口の仕様を実機で確かめる根気と、分かったことを `CLAUDE.md`（Claude Code が毎回のセッション開始時に読む申し送りファイル）に書き残す習慣でした。

## まとめ

実データを AI に読ませるときの要点は 3 つです。

1. **FileMaker は ODBC で SQL 直参照できる。** Server なら Admin Console で ODBC/JDBC を有効にし、ファイル側は fmxdbc 拡張アクセス権を付けて、開発機から直接つなぐ。Server が無くても手元の Pro で同じ手順が動く。開発中の確認だけでなく、バグ調査・全テーブルの CSV 書き出し・リプレース時のデータ移行にも同じ経路が使える
2. **落とし穴は先に知っておく。** `ODBCSYSINI`、`MultiByteEncoding=UTF-8`、`SELECT *` 禁止、`fmxdbc` 権限、ポート 2399 の到達性。この 5 つで詰まりどころの大半が消える
3. **実データには規律を置く。** 本番の 2399 番は外に開けず、必要な列だけ、集計と数行だけ。AI に渡す前に「渡してよいか」を決めておく

## よくある質問

**Q. ODBC 接続には FileMaker Server が必要ですか?**

A. 必須ではありません。基本は FileMaker Server の Admin Console で ODBC/JDBC を有効にし、開発機からサーバー上のファイルにつなぐ構成ですが、Server が無い場合は FileMaker Pro で対象ファイルを開き、[ファイル] メニュー → [共有設定] → [ODBC/JDBC を有効にする...] で共有をオンにすれば、その Pro 自身がポート 2399 で接続を待ち受けます。ただし Pro の共有は同じマシンからの接続のみで、最大 5 接続です。どちらの場合も、接続用アカウントには fmxdbc 拡張アクセス権が必要です。

**Q. すべてのテーブルのデータを一括で書き出せますか?**

A. できます。システムテーブル FileMaker_Tables でテーブルの一覧を取り、テーブルごとに SELECT した結果を CSV に書くスクリプトを用意すれば、FileMaker の画面でテーブルごとに書き出す手作業を無くせます。列は DDR で実在を確認したものを明示してください(node-odbc 経由では SELECT * でプロセスが落ちます)。

**Q. ODBC 経由でデータを書き換えることもできますか?**

A. FileMaker の xDBC は SQL による更新にも対応していますが、本記事の用途は読み取りに限定しています。接続に使うアカウントは閲覧のみのアクセス権セットにし、書き込みは FileMaker 側の仕組み(第 2 回のスクリプトなど)で行うのが安全です。

**Q. Windows の開発機でも同じことができますか?**

A. できます。Claris は Windows 向けの ODBC ドライバも提供しており、Windows では OS 標準の ODBC データソースアドミニストレータでドライバを登録します。unixODBC は macOS / Linux 向けのドライバマネージャなので、Windows では不要です。接続文字列の考え方と落とし穴は共通です。

**Q. Data API と ODBC はどちらを使うべきですか?**

A. 用途で分けます。どこからでも HTTPS で動く Data API はアプリケーションや自動処理に、ドライバのある開発機から直接テーブルを読める ODBC は調査・移行・裏取りに向いています。私たちは両経路で結果が一致することを確認したうえで、この分担にしています。

## ご相談お待ちしております。

**FileMaker のデータ連携・移行を相談できる会社をお探しの方、AI を取り入れた開発体制づくりをお考えの方へ。** システムデザインワークスは、栃木県に拠点を置く Claris パートナーです。FileMaker の開発・改修はもちろん、他のデータベースや Web システムとの連携・移行、既存データの調査・突合まで、本連載のような進め方で一貫して対応します。

まずは FileMaker のデータを何に使いたいか（連携・移行・集計など）と、FileMaker Server の有無をお聞かせください。それだけで、ODBC と Data API のどちらから始めるかの目安をお伝えできます。開発のご相談は、お気軽に [お問い合わせフォーム](https://systemdesignworks.co.jp/contact) よりご連絡ください。