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

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

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

第 1 回では、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 に読ませる

2. 第 2 回：AI にスクリプトを書かせる（本記事）

3. 第 3 回：ODBC で実データを AI に読ませる

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

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

• ステップを 1 つずつ選び、引数を入力し、フィールドを選ぶ。20 ステップなら 20 回

• 計算式は AI の出力をコピーして貼る。ここだけはテキストで済むが、それ以外は全部 GUI

• 打ち間違いや選び間違いが起きても、それを見つけるのは人

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

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

手順の全体像

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

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

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

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

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

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

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

調べ方は単純で、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 は索引を引くために作った自作コマンドで、名称は仮です）。

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

参照の種類ごとの細かな挙動も実機で確かめて規則にし、後述のスキル（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 から取り出して書き換える。直すときは作り直さず差し込む

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

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

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