# Claude Code で FileMaker 開発：AI にスクリプトを書かせる

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

> FileMaker にはソースファイルがなく、AI が書いたスクリプトをそのまま流し込む入口がありません。鍵はクリップボードでした。FileMaker はスクリプトを XML でコピー&ペーストできますが、テキストのままでは貼れず、専用のデータ型で渡す必要があります。DDR から正確な ID を引き、貼り付け前に参照を検証し、実機で 17 ステップのスクリプトを一発で貼り付けるまでに分かった仕様と手順を、連載第 2 回としてまとめます。

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

FileMaker のスクリプトを AI に書かせたい、と考えている方は多いのではないでしょうか。

[第 1 回](/news/filemaker-claude-code-ddr-reading)では、FileMaker の設計情報を DDR（データベースデザインレポート）で XML に出し、Claude Code（Anthropic 社の AI コーディングツール）に読ませるところまでを検証し、「AI は FileMaker 開発に活用できる」という結論を得ました。

ただし、読めるだけでは半分です。次に欲しくなるのは当然「書く」ことです。「この画面に一括登録のスクリプトを追加して」と頼んで、Claude Code が書いたスクリプトがそのまま FileMaker に入ったら、開発の速度は別物になります。

ところが FileMaker には、ソースコードを置くファイルがありません。スクリプトはスクリプトワークスペースという GUI で組み立てるもので、テキストを流し込む入口がどこにもないのです。

答えは **クリップボード**にありました。FileMaker はスクリプトをコピーすると、内部的には XML としてクリップボードに載せています。この XML を AI に書かせ、正しい形でクリップボードに入れれば、あとは人が ⌘V するだけです。検証の結論も第 1 回と同じで、**「書く」工程でも AI は FileMaker 開発に活用できます。** 分かったことを先に 4 点にまとめます。

1. **XML はテキストのままでは貼れない。** クリップボードには FileMaker 専用のデータ型で入れる必要がある
2. **参照は ID で解決される。** 同じファイル内に貼る限り、名前が合っていても ID が違えば別物になる。ID は推測せず DDR から引く
3. **貼る前に検証する。** ID の実在と名前の一致を機械的に確かめてから渡す
4. **既存スクリプトを雛形にする。** DDR から取り出した実物を書き換えるのが、いちばん速くて確実

---

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

- FileMaker で業務システムを開発・保守しているエンジニアや、社内の情報システム担当の方
- FileMaker のスクリプト作成や改修にかかる時間を短くしたい方
- Claude Code などの生成 AI を FileMaker 開発に取り入れたいが、何から始めればよいか分からない方

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

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

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

---

## 背景・課題：読めるようになっても、書き戻す入口がない

第 1 回の方法で、Claude Code は「この画面の保存ボタンは何をしているか」に答えられるようになりました。しかし、そこから先の「では、こう直してください」を実現するには、AI が出した手順を人がスクリプトワークスペースに打ち込むしかありません。

- ステップを 1 つずつ選び、引数を入力し、フィールドを選ぶ。20 ステップなら 20 回
- 計算式は AI の出力をコピーして貼る。ここだけはテキストで済むが、それ以外は全部 GUI
- 打ち間違いや選び間違いが起きても、それを見つけるのは人

AI が数秒で書いたスクリプトを、人が 15 分かけて写経する。これでは AI を使う意味が薄れます。

一方で、FileMaker 開発者なら誰でも知っている事実があります。スクリプトやステップは、スクリプトワークスペースの中で **コピー&ペーストできる**。別のファイルにも貼れる。この経路に AI の出力を載せるのが、本記事の方法です。

## 手順の全体像

先に、手順の全体を示します。Claude Code はこの 4 ステップを毎回踏み、最後の ⌘V だけを人が行います。

```mermaid
flowchart LR
    A["ID を引く<br/>DDR の索引から TO・フィールド・<br/>レイアウト・スクリプトの ID"] --> B["XML を書く<br/>貼り付け用 fmxmlsnippet"]
    B --> C["検証する<br/>ID の実在・名前の一致・<br/>計算式内の参照"]
    C --> D["クリップボードへ<br/>専用データ型で書き込む"]
    D --> E["人が FileMaker で ⌘V"]
```

貼り付け用 XML の基本形はこれだけです。

```typescript
<fmxmlsnippet type="FMObjectList">
<Script includeInMenu="False" runFullAccess="False" id="0" name="L3.2.1_一括登録">
  <Step enable="True" id="86" name="エラー処理">
    <Set state="True"/>
  </Step>
  <Step enable="True" id="141" name="変数を設定">
    <Value><Calculation><![CDATA[Get ( スクリプト引数 )]]></Calculation></Value>
    <Repetition><Calculation><![CDATA[1]]></Calculation></Repetition>
    <Name>$param</Name>
  </Step>
  <Step enable="True" id="76" name="フィールド設定">
    <Calculation><![CDATA[$param]]></Calculation>
    <Field table="L3.2.1_編集_dat受注" id="12" name="備考"/>
  </Step>
</Script>
</fmxmlsnippet>
```

（スクリプト名・テーブルオカレンス名・フィールド名は、本記事ではすべて実物を伏せた架空の例です）`<Step>` の `id` はステップの種類（86 = エラー処理、141 = 変数を設定、76 = フィールド設定）、`<Field>` の `id` はベーステーブル内のフィールド ID です。新規スクリプトの `id` は `0` でよく、FileMaker が採番します。途中で出てくる自作ツール（クリップボード書き込み、索引、バリデータ）は、いずれも Claude Code に作らせた数百行のスクリプトです（末尾で触れます）。以下、この形を作るために押さえる点を順に説明します。

## ① XML はテキストのままでは貼れない

XML をテキストエディタで ⌘C して、スクリプトワークスペースで ⌘V しても何も起きません。「ペースト」メニューが有効にすらならないのは、クリップボードの **データ型**が違うからです。macOS のクリップボードは、同じ内容を複数の型で持てます。FileMaker はスクリプトをコピーするとき、プレーンテキストではなく **FileMaker 専用の型**で XML を載せます。逆に言えば、プレーンテキストで入っている XML を FileMaker は見向きもしません。

FileMaker が使う型は次のとおりです。

| データ型 | 中身 | 貼り付け先 |
| --- | --- | --- |
| `«class XMSC»` | `<Script>` まるごと | スクリプトワークスペースのスクリプト一覧 |
| `«class XMSS»` | `<Step>` の並び | 編集中のスクリプトの中 |
| `«class XMFD»` | `<Field>` | フィールド定義ダイアログ |
| `«class XMTB»` | `<BaseTable>` | テーブル定義 |
| `«class XMFN»` | `<CustomFunction>` | カスタム関数ダイアログ |
| `«class XMVL»` | `<ValueList>` | 値一覧ダイアログ |
| `«class XML2»` | レイアウトオブジェクト | レイアウトモード |

調べ方は単純で、FileMaker で何かをコピーした直後に AppleScript の `clipboard info` を実行すると、クリップボードに載っている型の一覧が見えます。書き込みも AppleScript でできるので、「XML ファイルを読み、中身のルート要素から型を判定し、その型でクリップボードに書き込む」小さなツールを Claude Code に作らせました。逆方向、つまり FileMaker でコピーしたものをファイルに保存する機能も付けています。**構造が分からないステップは、FileMaker で 1 つ作ってコピーし、実物を見るのが最も確実**だからです。

運用上の注意として、ツールでクリップボードに入れたあとにエディタで XML を ⌘C すると、クリップボードがプレーンテキストで上書きされて貼れなくなります。「貼り付けできない」ときは、まずクリップボードの型を確認します。

## ② DDR の XML と貼り付け用 XML は「同じで、少し違う」

第 1 回で読んだ DDR にはスクリプトの XML がすべて入っていて、構造は貼り付け用 XML とほぼ同じです。ただし DDR は「読むため」の出力なので、貼り付け形式には無い表示用の要素を含み、要素の入れ子も細部で異なります。そのまま貼ると、エラーは出ないのに意図どおりに入りません。

差分は、①のツールの逆方向、つまり **FileMaker で実際にコピーしたものをファイルに保存し、DDR の同じスクリプトと見比べる**ことで洗い出せます。貼り付け用 XML の構造は Claris の公式ヘルプに載っておらず、第 1 回の claris-docs で引くこともできません。FileMaker が出力した実物が正解なので、迷うことがありません。差分が分かれば、変換はスクリプトで機械的に行えます。

方針はこうなります。**DDR から既存スクリプトを取り出し、貼り付け形式に変換して雛形にする**。近い処理をしているスクリプトを全文検索で探し、変換して出力し、AI に書き換えさせる。ゼロから書くより速く、そのシステムの流儀（変数の命名、コメントの入れ方、ダイアログの出し方）が自然に引き継がれます。

計算式は `<Calculation><![CDATA[ … ]]></Calculation>` の形で囲みます。`<`、`>`、`&` を含む式が壊れないためで、これも DDR の実物がそうなっています。

## ③ ID は推測しない — 参照解決の仕組み

XML の `name` が正しくても、貼り付けたスクリプトを開くと「スクリプト実行」ステップの参照先が `<不明>` になっていることがあります。

同じファイル内で貼り付けて確かめた範囲では、FileMaker はペースト時に、レイアウト・スクリプト・テーブルオカレンス（TO）・値一覧を `id`** で解決**します。`name` は表示用と考えてよく、`id` が 1 つ違うだけで別物を指します。そして FileMaker の内部 ID は GUI には表示されません（デザイン関数で取り出すことはできますが、数千件をまとめて引くには向きません）。AI がそれらしい数字を書いても当たるはずがなく、**ID は必ず DDR から引く**必要があります。

第 1 回で分割した XML からも探せますが、ID を引くためだけに毎回ファイルを検索するのは AI にとっても遠回りです。そこで DDR 本体を **SQLite に索引化**しました。分割 XML は人と AI が「読む」ためのもの、索引は ID を機械的に「引く」ためのもの、と役割を分けています。UTF-16 の 235MB を UTF-8 に変換しつつ読み、ベーステーブル・フィールド（約 2,750 個）・TO・レイアウト・スクリプト・カスタム関数・値一覧・リレーションを表に落とします。所要時間は約 4 秒。索引ができれば、Claude Code は次のような小さなコマンドで ID を引けます（`fmddr` は索引を引くために作った自作コマンドで、名称は仮です）。

```typescript
fmddr to 受注                      # TO を名前で検索 → TO ID とベーステーブル
fmddr fields dat受注 備考           # ベーステーブルのフィールドと ID
fmddr ref L3.2.1_編集_dat受注 備考  # <Field table="…" id="…" name="…"/> をそのまま出力
fmddr layout 受注入力               # レイアウト ID
fmddr script 保存                   # スクリプト ID
fmddr xml 2283                      # 既存スクリプトを貼り付け用 XML に変換して出力
fmddr grep "ExecuteSQL"             # スクリプト本文の全文検索
```

参照の種類ごとの細かな挙動も実機で確かめて規則にし、後述のスキル（Claude Code に手順を教える単位）に書き残しています。

ステップの種類も `id` で決まります。「変数を設定」は 141、「フィールド設定」は 76。日本語版・英語版で `name` は変わりますが `id` は共通です。DDR を集計すると、そのシステムで実際に使われているステップは 77 種類でした。それぞれの XML 構造の実例を DDR から 1 件ずつ自動抽出し、貼り付け形式に変換してテンプレート集にし、Claude Code の参照資料にしています。

## ④ 貼る前に検証する

ID を索引から引くようにしても、AI が書き写す途中で取り違えることはあります。貼ってから気づくより、貼る前に機械的に確かめるほうが確実なので、バリデータを作りました。チェックしているのは次の項目です。

- XML として妥当か、ルート要素が `<fmxmlsnippet>` か
- ステップの `id` と `name` の組み合わせが、DDR にある実物と一致するか
- `<Field>` `<Layout>` `<Script>` `<Table>` `<ValueList>` の `id` が DDR に実在し、`name` が一致するか
- 計算式の中の `TO名::フィールド名` が実在するか
- DDR 専用の `<StepText>` `<DisplayCalculation>` が混入していないか

別ファイルのテーブル（外部データソース）はこの DDR にフィールド定義が無いので、そこだけ検証を省略して警告にとどめます。すべて通ったものだけをクリップボードに入れる、という順序を Claude Code の手順に固定しました。

## ⑤ 新規に作るか、既存に差し込むか

最後の判断は、スクリプトごと新しく作るか、既存スクリプトの途中にステップを差し込むかです。データ型で言えば `«class XMSC»`（スクリプト一覧に貼る）と `«class XMSS»`（編集中のスクリプトに貼る）の違いで、同じ XML ファイルから `<Script>` で包むか外すかを切り替えれば両方出せます。

原則は **既存スクリプトを直すときは差し込む**、です。スクリプトを作り直すと ID が変わり、ボタンや他のスクリプトからの参照が切れます。第 1 回で見たとおり、レイアウトからスクリプトへの参照は数千箇所あります。1 本作り直すだけで、どこが切れたか探す作業が発生してしまいます。

また、システムには暗黙の規約があります。たとえば私たちが扱っているシステムでは、スクリプトの冒頭は原則として「エラー処理 [オン]」→「ユーザによる強制終了を許可 [オフ]」で始まり、1,368 本のうち 1,234 本がこの形でした。区切りコメントの書き方、TO 名の付け方も決まっています。こうした規約は DDR を集計すれば見えるので、`CLAUDE.md`（Claude Code が毎回のセッション開始時に読む申し送りファイル）に書いておけば、AI は既存のスクリプトと見分けがつかない書き方をしてくれます。

## 結果：17 ステップのスクリプトが一発で入った

この手順で、フィールド・レイアウト・スクリプトを参照する 17 ステップの新規スクリプトを XML から貼り付け、**すべての参照が正しく解決される**ことを実機で確認しました。

その後は実務でも使っています。たとえば「編集画面で選んだ明細をまとめて確定する一括処理を追加して」と頼むと、Claude Code は近い処理をしている既存スクリプトを索引から探し、その構造（冒頭のエラー処理、区切りコメント、ダイアログの出し方、ポータル行の走査）を踏襲した 100 ステップ超のスクリプトを生成しました。バリデータを通してからクリップボードに入れ、人がロジックをレビューして ⌘V する。写経も、選び直しもありません。読むだけでなく書く工程でも、AI は FileMaker 開発に活用できる、というのが第 2 回の結論です。

さらに、同じ仕組みは **レイアウトオブジェクト**にも使えます。レイアウトモードでオブジェクトをコピーすると `«class XML2»` で取れるので、フィールドやボタンなどのオブジェクトを XML で生成して貼り戻せます。こちらはスクリプトとは構造も癖も別物なので、ここでも「実物をコピーして構造を見る」が近道です。

そして、この一連の手順は Claude Code の**スキル**にまとめ、プロジェクト内に手順書として置いています。ID を引く → XML を書く → 検証する → クリップボードに入れる → 人が貼る。書いてはいけない要素、このシステムの規約、貼れないときの確認手順。ここまで書いておくと、Claude Code は毎回同じ手順を踏み、私たちは貼るだけになります。

なお、ここまでに出てきた自作ツール（クリップボード書き込み、索引、バリデータ、ステップのテンプレート集）は、いずれも数百行のスクリプトです。本記事で挙げた要件をそのまま Claude Code に伝えれば書けるので、読者の環境でも同じ手順で再現できます。

設計情報を読めて、書き戻せるようになりました。しかし、まだ足りないものがあります。**フィールドに実際どんな値が入っているか**は、DDR のどこにも書かれていません。第 3 回では、ODBC 経由で実データそのものを Claude Code に読ませる方法を紹介します。

## まとめ

AI が書いたスクリプトを FileMaker に入れるうえでの要点は 3 つです。

1. **FileMaker の入口はクリップボード。** スクリプトは XML でコピー&ペーストできるが、テキストではなく専用のデータ型で渡す。DDR の XML とは細部が違うので、FileMaker がコピーした実物と見比べて変換する
2. **ID は推測せず DDR から引き、貼る前に検証する。** FileMaker は `id` で参照を解決する（同一ファイル内への貼り付けが前提）。索引化とバリデータで「貼ったのに動かない」を無くす
3. **既存を雛形にし、既存を壊さない。** 近いスクリプトを DDR から取り出して書き換える。直すときは作り直さず差し込む

## よくある質問

**Q. この方法は Windows の FileMaker Pro でも使えますか?**

A. 本記事のクリップボード書き込みは macOS の AppleScript で実装しているため、そのままでは使えません。FileMaker のスクリプトが XML でコピー&ペーストされる仕組み自体は Windows でも同じなので、Windows のクリップボード API で同等の型を書き込む実装を用意すれば同じ手順が成立します。

**Q. 既存のスクリプトを壊してしまう心配はありませんか?**

A. 貼り付けは「追加」の操作なので、既存のスクリプトを勝手に書き換えることはありません。既存スクリプトを直すときは作り直さずステップを差し込む方針にしており、差し替える前に元のオブジェクトをコピーして保存しておけば、失敗してもすぐ戻せます。

**Q. AI が FileMaker Server 上のファイルを直接書き換えるのですか?**

A. いいえ。AI が行うのは XML の生成・検証・クリップボードへの書き込みまでで、最後の貼り付けは人が FileMaker Pro のスクリプトワークスペースで行います。何が入るかを人が目で確認してから貼る、という一手を意図的に残しています。

**Q. AI が書いたスクリプトの品質は信頼できますか?**

A. 参照の誤り(存在しないフィールドや ID の取り違え)はバリデータで機械的に検出できます。処理の内容そのものは、DDR にある既存のスクリプトを雛形にすることでそのシステムの流儀に沿ったものになりますが、ロジックの妥当性は人がレビューしてから貼るのが前提です。

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

**FileMaker システムの機能追加や改修を頼める会社をお探しの方、AI を使って FileMaker 開発を速くしたいが何から手を付けるべきか分からない方へ。** システムデザインワークスは、栃木県に拠点を置く Claris パートナーです。FileMaker システムの保守全般から他システムとの連携、AI を取り入れた開発の進め方のご相談まで対応します。

まずは「この処理を変えたい」「この画面に機能を足したい」という要望を 1 つお聞かせください。DDR を出せる状態であれば、影響範囲の見立てからご一緒できます。開発のご相談は、お気軽に [お問い合わせフォーム](https://systemdesignworks.co.jp/contact) よりご連絡ください。