Claude Code で FileMaker 開発：DDR で設計を AI に読ませる

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

FileMaker の開発にも生成 AI を取り入れて、効率を上げたいと考えている方は多いのではないでしょうか。とはいえ FileMaker にはソースコードのファイルがなく、そもそも AI に何を読ませればよいのか、というところで手が止まりがちです。

弊社でも FileMaker のシステム開発・保守を手がけていますが、長年運用されてきた大規模な基幹システムになると、FileMaker Pro の画面からスクリプトを 1 本ずつ開いて追う調査には限界があります。そこで、Claude Code（Anthropic 社の AI コーディングツール）に FileMaker を読ませる開発スタイルに切り替えられるか検証しました。

結論から言うと、AI は FileMaker 開発に活用できます。 鍵は、設計情報をまるごと XML で書き出す DDR（データベースデザインレポート） です。この XML を Claude Code に読ませれば、「この画面のボタンは何をしているか」といった調査が、質問ひとつで返ってきます。

本記事は全 3 回の第 1 回で、設計情報を「読む」ところまでを扱います。

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

• FileMaker で業務システムを開発・保守しているエンジニアや、社内の情報システム担当の方

• 引き継いだ FileMaker システムの中身を、効率よく把握したい方

• Claude Code などの生成 AI を FileMaker 開発に取り入れたいが、何から始めればよいか分からない方

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

Claude Code で FileMaker 開発（全 3 回）

1. 第 1 回：DDR で設計を AI に読ませる（本記事）

2. 第 2 回：AI にスクリプトを書かせる

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

背景・課題：FileMaker は「読めない」

FileMaker は、テーブル・画面・スクリプトを 1 つのファイルの中で GUI から組み立てる開発環境です。業務アプリを短期間で作れる強力な道具ですが、引き継ぎや改修の場面では、ほかの開発環境にはない壁があります。

• ソースコードが存在しない。 スクリプトはスクリプトワークスペースで 1 本ずつ開くしか読む手段がなく、横断検索も限定的です

• 画面と処理の結びつきが見えない。 ボタンにどのスクリプトが紐づき、レイアウトにどのトリガーが仕掛けられているかは、オブジェクトを 1 つずつ開いて確かめる必要があります

• AI に渡せない。 Web 開発では当たり前になった「コードベースを AI に読ませて質問する」という進め方が、バイナリの .fmp12 ではそもそも成立しません

参考までに、私たちが扱っている FileMaker システムの一つを DDR の概要から抜き出すと、次の規模になります。

長年運用されてきたシステムでは、複数の開発者が手を入れて命名規約が時代ごとに違う、ということも珍しくありません。「この画面で保存ボタンを押すと何が起きるのか」を確かめるだけで、スクリプトを何本も渡り歩くことになります。

Claris 社自身も、生成 AI への対応を公式に進めています。時系列で並べると次のとおりです。

• 数年前から: 埋め込み（ベクトル化）や RAG のための AI 関数を FileMaker に追加

• 2025 年 12 月: Claris MCP を公開。Claude などの AI アシスタントから FileMaker のレコードを読み書きし、既存のスクリプトを実行できる

• 2026 年 5 月: CEO が「エージェント型開発」の構想を発表。Claude Code・Cursor・Codex といった AI コーディングツールから FileMaker のスクリプトやスキーマを直接書けるようにするもので、開発者プレビューは同年夏以降と予告

• 2026 年 6 月: FileMaker 2026 をリリース。フィールドやテーブルに AI 向けの注釈を付け、自然言語での問い合わせ精度を上げる機能を追加

ただし本記事の執筆時点（2026 年 9 月）では、エージェント型開発の開発者プレビューはまだ公開されておらず、実際に使えるのは出来上がったシステムを AI から「使う」ための仕組みです。スクリプトやレイアウトを AI が読み書きする、つまりシステムを「開発する」ための公式ツールは、まだ手元にありません。本連載で紹介するのは、その空白を FileMaker が元々持っている機能で埋める方法です。公式ツールが出たあとも、DDR・クリップボード・ODBC という出入口の理解は無駄になりません。

取り組みの概要：3 つの道具で「読める」状態を作る

やることは単純です。FileMaker の設計情報を テキストにし、AI が扱いやすい粒度に 分割し、FileMaker の仕様を 公式ドキュメントで裏取りできるようにする。この 3 点がそろえば、Claude Code は FileMaker でも普通のコードベースと同じように働きます。

使った道具は次の 3 つです。3 つとも無料で使え（Claude Code 自体の利用料は別です）、Mac 1 台で完結します。

前提となる Claude Code は、Anthropic 社が提供する、ターミナルで動く AI コーディングツールです。プロジェクトのファイルを読み、コマンドを実行し、ファイルを書き換えることができます。利用には Anthropic のアカウント（Pro / Max / Team / Enterprise の各プラン、または API の従量課金）が必要で、導入手順は公式ドキュメントにまとまっています。本連載はすべて macOS で進めています。

以下、順番に見ていきます。

① claris-docs プラグイン：仕様は記憶ではなく公式ヘルプから引かせる

最初に入れたのが claris-docs です。FileMaker のコンサルティングで知られる Soliant Consulting 社がコミュニティ向けに公開しているもので、Claris 社の公式プロダクトではありません（MIT ライセンス）。Claude Code のプラグイン機能から 2 コマンドで入ります。

1/plugin marketplace add soliantconsulting/soliant-public-claude-plugins
2/plugin install claris-docs@soliant-public-claude-plugins
Copy

このプラグインの設計思想が気に入りました。ドキュメントの内容を AI に埋め込むのではなく、**公式ヘルプのどのページを読むべきかを案内する「ナビゲーター」**として作られています。FileMaker Pro・Server・WebDirect・Data API・SQL リファレンス・セキュリティガイドなど 17 のスキル（Claude Code に手順を教える単位）があり、質問の種類に応じて該当スキルが起動し、help.claris.com の該当ページをその場で取得して答えます。

なぜこれが重要かというと、AI は FileMaker の細かい仕様を「うっかり思い出す」からです。スクリプトステップの引数や関数の挙動を学習データの記憶から答えると、バージョン違いの古い仕様や、そもそも存在しない選択肢が混ざります。公式ヘルプを毎回読む運用にしておけば、この種のもっともらしい誤りをかなり減らせます。

日本語版 FileMaker を使う方には、ひとつ小技があります。プラグインが案内する URL は英語版ヘルプですが、URL の /en/ を /ja/ に置き換えるだけで日本語版ヘルプが取れます。

1英語: https://help.claris.com/markdown/en/pro-help/set-variable.md
2日本語: https://help.claris.com/markdown/ja/pro-help/set-variable.md  ← 「変数を設定」
Copy

日本語版のシステムでは、スクリプトステップ名も関数名も日本語です（Get ( スクリプト引数 ) のように）。日本語ヘルプを読ませることで、AI が出力する名称がシステム内の表記とそのまま一致するようになります。この置き換えはプロジェクトの CLAUDE.md（Claude Code が毎回のセッション開始時に読む申し送りファイル）に 1 行書いておけば、以後は自動で守ってくれます。

② DDR を XML で出し、FMPSplit で分割する

DDR の出力

DDR は FileMaker Pro の標準機能です。[ツール] メニューの [データベースデザインレポート...] を開き、対象ファイルと [レポートに含める] 要素を選び、[レポート形式] で XML を選んで作成します。既定は HTML ですが、公式ヘルプにあるとおり HTML レポートの情報は XML 版のサブセットです。AI に読ませる目的なら迷わず XML を選びます。

出力されるのは、概要（Summary）の小さな XML と、設計情報すべてが入った本体の XML です。先ほどの規模のシステムでは本体が 約 235MB。しかも文字コードは UTF-16 で書き出されます。

実は、この 1 ファイルのままでも AI に読ませることは不可能ではありません。UTF-8 に変換すれば（iconv -f UTF-16 -t UTF-8 の 1 行で済みます）全文検索は効きますし、Claude Code は検索で当たりをつけて該当箇所だけを切り出して読む、という動きを自分でやってくれます。ただし 235MB を丸ごと読むことはできないので、質問のたびに「探して、切り出して、読む」を繰り返すことになり、時間もトークン（AI が読み書きする文字量の単位で、料金と処理時間に直結します）もかさみます。

FMPSplit で分割すると、AI も人も読みやすくなる

そこで私たちは、DDR を分割してから渡すことにしました。必須の工程ではありませんが、やってみると AI の読み方が目に見えて変わったので、おすすめしたい一手間です。

使ったのは FMPSplit（FileMaker DDR Splitter） です。FileMaker 開発者の Karsten Wolf 氏が公開している Python 製のツールで、macOS 用のアプリ版もあります。DDR を要素ごとに分解し、1 つのテーブル・1 つのレイアウト・1 つのスクリプトが、それぞれ 1 つの XML ファイルになります。レイアウトとスクリプトはフォルダ階層と並び順もそのまま再現できます。作者のベンチマークでは 275MB の DDR を 19 秒で分割したとのことで、今回も待ち時間はほぼありませんでした。使い方は、アプリ版なら概要（Summary）の XML を指定するだけ、スクリプト版なら python3 ddrsplit.py Summary.xml の 1 行です。UTF-16 のままの DDR をそのまま渡せます。

分割後のディレクトリはこのような構造になります（名称は例です）。

1Exports/業務システム_fmp12/
2├── Accounts/            4 ファイル
3├── Basetables/          119 ファイル（ベーステーブルごとにフィールド定義）
4│   ├── 0000130 mst商品.xml
5│   └── 0000131 dat受注.xml
6├── CustomFunctions/     68 ファイル
7├── CustomMenus/         25 ファイル
8├── CustomMenuSets/      2 ファイル
9├── ExtendedPrivileges/  7 ファイル
10├── Layouts/             488 ファイル（レイアウトフォルダの階層がそのままディレクトリに）
11│   └── 00006 0000034 レイアウト/
12│       └── 00111 0000957 3.2_受注/
13│           └── 00115 0001011 L3.2.1_編集_dat受注.xml
14├── Privileges/          4 ファイル
15├── Relationships/
16│   ├── Relationship/    769 ファイル（1 リレーション = 1 ファイル。ファイル名が「左TO---右TO」）
17│   └── TableList/       1,136 ファイル（テーブルオカレンス）
18├── Scripts/             1,369 ファイル（1 スクリプト = 1 ファイル。区切り線を含む）
19│   └── 0001144 2_データ/
20│       └── 0001165 2.2_受注/
21│           └── 0001210 2.2.4_伝票発行.xml
22└── ValueLists/          164 ファイル
Copy

合計 4,155 ファイル。ファイル名の先頭には FileMaker 内部の ID が付きます。FileMaker のレイアウト一覧やスクリプトワークスペースを見慣れた方なら、ディレクトリを眺めるだけで構成が思い浮かぶはずです。

分割が効く理由は 3 つあります。

• AI が「必要な部分だけ」を開ける。 「受注編集画面の保存ボタン」を調べたいとき、Claude Code はレイアウト名でファイルを特定し、その 1 ファイル（数十 KB）だけを読みます。235MB を探し回る必要がありません

• 人間が迷わない。 ディレクトリ構成が FileMaker 内の見た目と一致するので、AI が「このファイルを読みました」と示したときに、人間側もすぐ同じ場所を FileMaker で開けます

• スクリプトがそのまま読める。 分割されたスクリプトの XML には、スクリプトワークスペースに表示されるのと同じ文（エラー処理 [ オン ] のような StepText）が各ステップに入っています。XML に慣れていない人でも、AI の説明と見比べながら読めます

③ Claude Code でコードリーディングする

分割された XML と claris-docs がそろえば、あとは Claude Code に質問するだけです。分割先のディレクトリで Claude Code を起動すれば、そのフォルダ全体がプロジェクトとして扱われ、必要なファイルを自分で探して読みます。実際にどう読み解いていくのかを、代表的な 3 つの場面で紹介します（画面名・スクリプト名は実物を伏せた例に置き換えています）。

画面からスクリプトを追う

レイアウトの XML には、その画面が使うテーブルオカレンス、配置されたフィールド、ボタンに紐づくスクリプト、そしてスクリプトトリガーがすべて書かれています（この例では画面専用のテーブルオカレンスをレイアウトと同じ名前にしているため、<Table> の name がレイアウト名と一致しています）。

1<Layout id="1011" name="L3.2.1_編集_dat受注">
2<Table id="1065210" name="L3.2.1_編集_dat受注" />
3<ScriptTriggers>
4  <Trigger event="OnRecordCommit" id="104" triggerFlags="1">
5    <Script id="2282" name="L3.2.1_OnRecordCommit"></Script>
6  </Trigger>
7</ScriptTriggers>
8...
9<Object type="Button" key="1096" ...>
10  <ButtonObj>
11    <Step enable="True" id="1" name="スクリプト実行">
12      <Script id="2283" name="L3.2.1_保存" />
13    </Step>
14  </ButtonObj>
15</Object>
Copy

「この画面の保存ボタンを押すと何が起きるか」と聞けば、Claude Code はレイアウトのファイルを開いてボタンのスクリプト ID を読み、Scripts フォルダから該当スクリプトのファイルを開き、さらにそこから呼ばれるスクリプトや切り替え先のレイアウトを芋づる式にたどって、処理の流れを説明してくれます。先ほどのシステムでは 109 のレイアウトにトリガーがあり、レイアウトからスクリプトへの参照は 3,900 箇所近くありました。人手で追い切れる量ではありませんが、AI にとってはただの参照解決です。

フィールドの更新元を逆引きする

「このフィールドはどこで値が入るのか」は、FileMaker の調査でもっとも時間を取られる質問のひとつです。分割した XML なら、フィールド定義（ベーステーブル側）で自動入力や計算式を確かめ、Scripts フォルダの全文検索で「フィールド設定」しているスクリプトを列挙する、という 2 段構えで答えが出ます。計算式は テーブルオカレンス名::フィールド名 の形で書かれているので、検索の精度も高いです。

「なぜ動かないのか」を仕様として突き止める

コードリーディングの本当の価値は、この 3 つ目にあります。FileMaker のバグ調査で厄介なのは、原因がスクリプト本体の外にあるケースです。たとえば、あるスクリプトが期待どおりにレイアウトを切り替えてくれない。スクリプトを何度読み返しても間違いは見つからない。こういうときの原因は、実行元レイアウトのスクリプトトリガーが条件付きで False を返して処理を止めている、別のスクリプトが途中で状態を書き換えている、といった「呼び出し側の事情」であることが少なくありません。

FileMaker Pro の画面でこれを追うには、レイアウト設定でトリガーを確かめ、そのスクリプトを開いて条件を読み、条件に使われているフィールドをどこが更新しているか調べる、という往復が必要です。分割した XML なら、Claude Code に「このスクリプトが動かない。実行元レイアウトのトリガーと、関係するスクリプトを含めて原因を調べて」と頼むだけです。レイアウトの XML からトリガーの定義を読み、スクリプトの条件分岐を追い、条件に使うフィールドの更新元まで順にたどって、原因の候補を根拠つきで挙げてくれます。同じトリガーを持つレイアウトが他にないかも、スクリプト名の検索一発で分かります。

原因が分かると、それは「このシステムではこう振る舞う」という仕様の発見でもあります。私たちはこうした発見を、調査の手順とあわせて CLAUDE.md に書き足していきました。

1## 動かないスクリプトを調べるときの手順
21. スクリプト本体だけでなく、実行元レイアウトのスクリプトトリガーを必ず確認する
32. トリガーのスクリプトが False を返す条件を読み、条件に使うフィールドの更新元を追う
43. 同じトリガーを持つレイアウトを Layouts フォルダから検索し、影響範囲を記録する
5
6## このシステム固有の落とし穴
7- 調査で分かった仕様をここに追記していく（どのレイアウトで、何が、なぜ起きるか）
Copy

この CLAUDE.md に、システムの規模、命名規約（機能番号を接頭辞に持つ、テーブル名の接頭辞で種別を表す、など）、そしてこうした落とし穴を蓄積していくと、AI の読解精度が回を重ねるごとに上がります。そして気づけば、これはこのシステムの設計ドキュメントそのものになっています。誰も書いていなかった仕様書が、調査の副産物として育っていくのは、想定していなかった収穫でした。

AI に渡す前に確認すべきこと

ここまで読んで「うちのシステムでもやってみたい」と思われた方に、先に確認しておいていただきたい点が 2 つあります。

DDR には設計情報以外も含まれます。 レコードの中身（業務データ）は含まれませんが、ファイルの接続先ホスト名、アカウント名、アクセス権セット、外部データソースのパスが入ります。さらに、スクリプトの計算式はそのまま書き出されるので、「メールを送信」の SMTP パスワードや「URL から挿入」の API キー、「再ログイン」のパスワードが直書きされていればそれも含まれますし、値一覧のカスタム値（取引先名など）も載ります。社外のサービスに渡す前に、これらが含まれていることを把握し、必要なら該当箇所を除いてください。

AI サービス側のデータ利用ポリシーを確認してください。 Anthropic 社の Claude Code は、法人向けの Team / Enterprise プランや API 経由の利用ではコードやプロンプトをモデルの学習に使わないと明記されています。個人向けプランでは学習に使うかどうかを利用者が設定で選ぶ形です。弊社はお客様の設計情報を扱う以上、学習に使われない設定で運用しています。どのプランでも、始める前に公式の Data usage のページで自分の契約の扱いを確かめることをおすすめします（本記事の記述は 2026 年 9 月時点のものです）。

結果：調査が「開いて追う」から「聞いて確かめる」に変わった

数字で示せる種類の成果ではありませんが、検証の結論は明確でした。AI は FileMaker の調査・読解に十分に使えます。 開発の進め方は次のように変わります。

• 初動が速い。 初めて触るシステムでも、全体の構成（テーブルの役割、画面のグループ、スクリプトの命名の癖）を Claude Code との最初の数回の対話で把握できます。以前なら画面を 1 つずつ開いて回る必要があった作業です

• 仮説の検証が往復できる。 「たぶんこのトリガーが原因」という仮説を投げると、該当 XML を読んで根拠付きで肯定または否定してくれます。推測で直して動かして確かめる、という遠回りが減りました

• 知見が消えない。 分かったことは CLAUDE.md に残るので、次の改修でも、担当者が代わっても、同じ調査を繰り返しません

そして読めるようになると、次に欲しくなるのは「書く」ことです。Claude Code が書いたスクリプトを FileMaker に入れるには、FileMaker が受け付ける貼り付け用 XML の形式と、クリップボードの専用データ型を理解する必要がありました。第 2 回では、DDR を索引化して正確な ID を引く仕組み、貼り付け前に参照を検証するバリデータ、そして実機で 17 ステップのスクリプトを一発で貼り付けるまでの手順を紹介します。

さらに第 3 回では、設計情報だけでなく実データそのものを、ODBC 経由の SQL で Claude Code に読ませる方法を取り上げます。「このフィールドには実際にどんな値が入っているのか」が見えると、仕様の推測が事実確認に変わります。

まとめ

FileMaker のシステムを AI と一緒に読み解くために、押さえておきたい点は 3 つです。

1. 設計情報はテキストにできる。 DDR を XML で出せば、FileMaker も「読めるコードベース」になる。FMPSplit で 1 オブジェクト 1 ファイルにしておくと、AI も人も格段に読みやすくなる

2. 仕様は AI の記憶ではなく公式ヘルプで裏取りする。 claris-docs プラグインで公式ヘルプを都度参照させ、日本語版なら URL を /ja/ に置き換える

3. 発見は CLAUDE.md に蓄積する。 システム固有の落とし穴を書き残していくと、AI の精度が上がると同時に、それ自体が設計ドキュメントになる

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

FileMaker システムの保守・改修を任せられる会社をお探しの方、設計資料がないまま引き継いだ FileMaker システムの中身を把握したい方へ。 システムデザインワークスは、栃木県に拠点を置く Claris パートナーです。長年使ってきた FileMaker システムの改修や機能追加、既存システムの調査・ドキュメント化、新規開発まで、本連載のように AI を取り入れた進め方で堅実に対応します。

まずは本記事の手順で DDR を出して、規模感を教えていただくだけで十分です。出し方が分からない段階からのご相談でも構いません。開発のご相談は、お気軽に お問い合わせフォーム よりご連絡ください。