「このデータは外に出せないので、AI は使えません。」 そういって諦めた企画で、AI を使えるようにする。それが Claris FileMaker 2026 の Claris AI Model Server です。
本シリーズの第1回では、「FileMaker 万年ジュニアズ」の筆者が「Claris AI Model Server セットアップガイド」を片手に Claris AI Model Server をセットアップしました。そして最初の泥沼、AI モデルの使い分けの落とし穴からなんとか這い上がったところです。
この第2回から、ようやく本題です。うちのとある上司が昔ウガンダで撮影した写真 592点をテキストで検索できるように、埋め込みを生成します。
今回の旅路：
（第1回）
1. はじめに
2. Claris AI Model Server をセットアップする
3. AI モデルの選択でつまずく
（第2回・本記事）
4. 埋め込み生成しながら処理時間を測ってみる
（第3回）
5. テキストで画像を検索してみる
6. おわりに
なお、本記事では、Claris が提供するオンプレミス AI 推論基盤を「Claris AI Model Server」、AI モデルをホストしてリクエストを処理する役割・機能を単に「AI モデルサーバー」と呼びます。
4. 埋め込み生成しながら処理時間を測ってみる
第1回で、日本語で画像を検索するための AI モデルの使い方がわかったので、さっそく埋め込みの生成です。
Claris FileMaker で埋め込みを生成するスクリプトステップは 2つあります。[埋め込みを挿入] スクリプトステップと [対象レコードに埋め込みを挿入] スクリプトステップです。両者は処理の仕組みが異なり、処理件数が増えたときの傾向に違いが出ます（詳細は後述）。モデルは、第1回のひと騒動の末に判明したとおり、clip-ViT-B-32 を使用します。
今回の画像データ（とある上司の秘蔵写真）は 592点、サイズの合計は約 583MB。それなりの分量があります。そして「埋め込みベクトルを生成する」という語感から、よくわからないけれどすごいことをやるので時間がかかりそう、という先入観があります。そこで、実際に処理時間を測定してみることにしました。
参考データとして、「Claris AI Model Server セットアップガイド」（以下、「AIS ガイド」）のサンプルで使用されているイメージキャプションも生成してみました。第1回で作成した API キーに「イメージキャプション」を含めておいたのはこのためです。使用するスクリプトステップは、[イメージキャプションを挿入] スクリプトステップと [対象レコードにイメージキャプションを挿入] スクリプトステップ、モデルは Salesforce/blip2-opt-2.7b です。
各スクリプトステップについて詳しくは、Claris FileMaker Pro ヘルプや AI 機能に関する Claris ブログなどを参照してください。
終わらないスクリプト
まず、AI が筆者の上司の写真をどう見るかのか（「見る」と言えるのかはさておき）興味があったので、先にイメージキャプションを生成しておくことにしました。
イメージキャプション用の Claris 推奨モデルは上記 1つだけなので、こちらを AI モデルサーバーの Admin Console からダウンロードしておきました。
イメージキャプション生成用のスクリプトは、画像 1点ずつの処理時間も知りたかったので、[イメージキャプションを挿入] スクリプトステップを [Loop] スクリプトステップで 1回ずつ時間を測りながら繰り返し実行します。まずは 10点だけを対象に実行して、ちゃんと繰り返し処理がされることを確認して、592点、全レコードについて実行開始しました。
その日、筆者は自宅から VPN で職場につないで作業していました。先に 10レコード（10点）で動作確認をしたときも、すぐに処理が終了しなかったのでチラと気にはなったのですが、そのときは他のことに気を取られているうちに処理が終わっていたので（1分以内）、592点も、まあ、5分もあれば終わるだろうと思っていました。
ところが、5分経っても、10分経っても、FileMaker Pro クライアント上では「レインボーのくるくる」が回るばかりです（macOS での正式名称は「スピニングウェイトカーソル（Spinning Wait Cursor）」というのだそうです）。正直、筆者が（また）何かやらかしたのかと思って、焦りました。しかし、10レコードでは問題なく動作していたので、スクリプトの問題ではないはずです。
[Loop] スクリプトを使ったイメージキャプション生成用スクリプト例
スクリプトは結局、20分以上経ってやっと終了しました。正常終了で、592点の画像すべてについてキャプションが生成されていました。ただ、時間がかかっていただけだったのです。ローカルの AI モデルで、他はまだ誰も使っていないはずなのに、なぜ？
落ち着いて考えれば、当たり前でした。写真は社内のサーバー（FileMaker Server）にあり、AI モデルサーバーも社内にあり、その間に筆者の自宅の FileMaker Pro クライアントが挟まっていたのです。写真は VPN を往復していたのでした。
「ローカル AI なので処理時間はマシンの性能次第」と思い込んでいて、データの通り道をまるで考えていませんでした。
3とおりの構成で処理時間測定
こんなに時間がかかるとは思ってなかったので、せっかくなので次の 3とおりの構成で処理時間を測定してみることにしました。
(1) 同一 LAN 構成：FileMaker Server、Claris AI Model Server、FileMaker Pro の 3台のマシンが同じ拠点 A の同じ LAN 内
(2) 拠点間 VPN 構成：FileMaker Server および Claris AI Model Server は拠点 A に、FileMaker Pro クライアントが国内の別拠点 B にあり、VPN を通して通信
(3) 同一マシン構成（参考）：Claris AI Model Server が稼働しているマシンに FileMaker Pro をインストールし、カスタム App をローカルで開いて実行
各構成で使用したマシンはすべて同一の機材で、構成ごとに入れ替えていません。違うのは画像データが拠点間または拠点内でどれだけの距離を移動するかです。
(1) はサーバーが置かれているオフィスで実行する構成、(2) はリモートワークで自宅にあるクライアントから実行する構成という、通常業務の場面でよくありそうな標準構成です。
一方、(3) の構成は、画像データが移動する距離の違いに加え、そもそも FileMaker Server を経由しないという違いもあります。(1) や (2) と横並びで比べられる構成ではないため、あくまで下限値の参考としてご覧ください。
処理時間を測定した 3構成
測定したマシンのスペック：
- Claris AI Model Server 用：Mac mini (2024) / M4 / 32GB ユニファイドメモリ / macOS Tahoe 26.5
- FileMaker Server 用：Mac mini (2024) / M4 / 32GB ユニファイドメモリ / macOS Tahoe 26.4.1
- FileMaker Pro 用 (*)：MacBook Pro (2023) / M3 Pro / 36GB ユニファイドメモリ / macOS Tahoe 26.5.2
(*)：(1) および (2) の FileMaker Pro クライアント。(3) では AI モデルサーバー機（Mac mini）上の FileMaker Pro を使用。
なお、FileMaker は上記構成によらずすべて FileMaker 2026 (26.0.1) を使用しています。
1 レコードずつ繰り返し処理するか、まとめて処理するか
処理時間を測定するきっかけとなったのはイメージキャプション生成ですが、今回の記事のターゲットは埋め込み生成なので、忘れちゃいけない、埋め込みの処理時間を測定します。埋め込み生成もなにか難しいことをやっていそうなので、処理時間がかかるのではないかと予想しました。
埋め込みを生成するにあたって、今回、 [埋め込みを挿入] スクリプトステップと [対象レコードに埋め込みを挿入] スクリプトステップのそれぞれを使った測定パターンを用意しました。
正直に打ち明けると、筆者はこの 2つのスクリプトステップが存在することは知りながらも、FileMaker Pro ヘルプをちゃんと読み込めてはいませんでした。[対象レコードに埋め込みを挿入] スクリプトステップは、対象レコードそれぞれに対して [埋め込みを挿入] スクリプトステップを実行してくれる、つまり自分でループを書かなくて済むだけのちょっと便利なスクリプトステップだと思い込んでいました。[対象レコードにイメージキャプションを挿入] スクリプトステップの方も同じです。
今回は念のため、それを確認してみようと測定してみたわけです。先にヘルプを読めば済むものを、第1回のモデルカードの件といい、後悔先に立たずを具現しています。
結果は、次の表のとおり、想像していたものとかなり違いました。
測定パターン (i) は、[Loop] スクリプトステップで [埋め込みを挿入] スクリプトステップを 592回繰り返し実行したときの所要時間です（レコードの移動など、ループ制御に要した時間は含みません）。一方、測定パターン (ii) は、[対象レコードに埋め込みを挿入] スクリプトステップで 592個の対象レコードを一括で処理したときの値です。スクリプトステップのオプションは、いずれもデフォルトのままとしました。
(iii) と (iv) は参考値として、イメージキャプション生成についても同様に測定したものです。
注：上記測定結果は、各構成を 2回実施した際の平均値です。測定回数が 2回ずつと少なく、測定した日や時間帯も異なるため、あくまで傾向を掴むための目安としてご覧ください。
測定値から確認できたこと
これら測定値から、3つのことが確認できました。
まず、イメージキャプション生成に比べて埋め込み生成の方が格段に処理時間が短くなっていました。これは、埋め込みを生成するモデルと、イメージキャプションを生成するモデルの処理方法の構造的な違いによるものでしょう。
次に、予想どおりではありますが、同じ LAN の中で実行する (1) 同一 LAN 構成の方が、拠点をまたぐ (2) 拠点間 VPN 構成よりも速いことが確認できました。これは、どの測定パターンを見ても明らかです。
もう 1つは、構成によらず測定パターン (ii) が測定パターン (i) よりも速いことです。つまり、[対象レコードに埋め込みを挿入] スクリプトステップは、[埋め込みを挿入] スクリプトステップを自動で繰り返してくれるだけの便利ステップではなく、繰り返し処理するよりもはるかに速いことがわかりました。
とはいえ、これらの数値の差はどう考えたらいいのでしょうか。手がかりを探すため、とりあえず測定結果をグラフにしてみました。
スクリプトステップと構成をそれぞれ変えて測定した処理時間例
スクリプトステップの処理時間の差の正体
まず、上記の左側の埋め込みのグラフから見てみます。
同じ構成でスクリプトステップによる違いを見るために、[埋め込みを挿入] スクリプトステップの繰り返し処理 (i) のグラフ上端と [対象レコードに埋め込みを挿入] スクリプトステップによる一括処理 (ii) の上端を線で結んでみます（オレンジ色の矢印線）。すると、 (1) 同一 LAN 構成と (2) 拠点間 VPN 構成のそれぞれの線がほぼ同じ傾きになっています。つまり構成が異なっても、両スクリプトステップの処理時間の差はほぼ同じということです。
FileMaker Pro ヘルプをよくよく読んでみると、この理由は 2つのスクリプトステップの処理の違いにありそうです。
[対象レコードに埋め込みを挿入] スクリプトステップには [引数:] というオプションがあり、何種類かの引数が指定できるようになっています。その中に [MaxRecPerCall] という引数キーがあり、その説明に「各 API 呼び出しで処理するレコードの最大数」と書いてありました。どうやらこのスクリプトステップには、複数のレコードをまとめて AI モデルに渡す機能があるらしく、その渡すレコード数を指定できるようです。今回はこのオプションを指定せずに実行したのでデフォルト値の「20」が使われ、20レコードずつまとめて処理されていたことになります。
つまり、オレンジ色の矢印線の傾きは、592レコードそれぞれに対する 592回の API 呼び出しと、20レコードずつ 30回の API 呼び出しの差、すなわち 562回の API 呼び出しに要した時間（API 呼び出し 1回あたりのオーバーヘッド × 呼び出し回数）と考えられます。そのため、(1) 同一 LAN 構成と (2) 拠点間 VPN 構成では、差がほぼ同じ（測定誤差の範囲）になるわけです。
なお、(3) 同一マシン構成ではこの差が 1/10 程度まで縮んでいることから、API 呼び出し 1回あたりのオーバーヘッドは、ネットワークを介するかどうかで大きく変わるものと考えられます。
同様に、[対象レコードにイメージキャプションを挿入] スクリプトステップにも [引数:] オプションに [MaxRecPerCall] キーが指定できるようになっています。上記右側のグラフでも (1) 同一 LAN 構成と (2) 拠点間 VPN 構成のあいだで、[イメージキャプションを挿入] スクリプトステップの繰り返し処理 (iii) と [対象レコードにイメージキャプションを挿入] スクリプトステップによる一括処理 (iv) の処理時間の差が両者ほぼ同じになっていますが、こちらも API 呼び出し回数の差と考えられるでしょう。
構成の差の正体
次に、同じスクリプトステップで構成による違いを見るために、測定パターン (i) と (ii) のそれぞれにおいて、(1) 同一 LAN 構成と (2) 拠点間 VPN 構成のグラフ上端を結んでみます（緑色の矢印線）。こちらも、測定誤差を考えればスクリプトステップの違いによらずほぼ同じ傾きになりました。
これを画像データの流れから考えてみると、次のようになります。まず、(1) 同一 LAN 構成では、同じ拠点内の FileMaker Server から FileMaker Pro、そして AI モデルサーバーと移動します。一方、(2) 拠点間 VPN 構成では、画像データは最初に FileMaker Server（拠点 A）からクライアントの FileMaker Pro（拠点 B）へ渡り、続いて FileMaker Pro（拠点 B）から AI モデルサーバー（拠点 A）に渡ります。つまり、同じ画像データが VPN を 2回通ることになります。
約 583MB が 2回、合計約 1.2GB。(1) と (2) の差は、この量のデータを LAN ではなく VPN で運ぶコストと考えると、測定値をうまく説明できそうです。
AI 処理時間の考え方
ここまでの考察を整理すると、AI 関連処理にかかる時間は、次の足し算になりそうです。
3つ目の項の「API 呼び出し 1回あたりのオーバーヘッド」は、ネットワークを介するかどうかで大きく変わります。(3) 同一マシン構成でこの項が小さく済んでいるのは、ネットワークを介した通信が発生しないためと考えられます。
また、「呼び出し回数」は、[対象レコードに] で始まるスクリプトステップの MaxRecPerCall オプション値（1回に渡すレコード数）を変更すればさらに縮められるかもしれません。ただし、1回に渡すレコード数を増やせばその分、AI モデルサーバー側のメモリ消費も増えるはずなので、数値を大きくすればするほど速くなるというわけではないでしょう。今回は試していないので、気になる方はぜひやってみてください。
イメージキャプション生成（上記グラフ右側）についても同様の考察ができますが、全体として見ると、VPN を挟んでもあまり処理時間が長くなっているようには見えません。これは、イメージキャプション生成処理そのものが重いため、通信のオーバーヘッドが相対的に小さく見えているということでしょう。実際、VPN による処理時間増加分は、埋め込みとイメージキャプション生成でほぼ同じです。処理そのものが重い分、同じ増加分が目立たなくなるわけです。
どこから、どのスクリプトステップで実行するか
測定結果の数字を並べ、分解することで見えてきた優先順位は、次のようになります。
- できるだけ、[対象レコードに] で始まるスクリプトステップを使う（ただし、各レコードに対して AI 関連処理以外にやるべき作業があれば、繰り返し処理で一緒に処理をした方が良い場合もあります）。
- 画像データを移動させない。処理対象の画像が大量にあるなら、AI モデルサーバーと同じ LAN 内にあるクライアントから実行する。
- そもそもクライアントを経由させない。処理対象データが日々追加されていくようなら、サーバー側での実行や夜間バッチを検討する。
同一マシン構成が速い理由と、実務に持ち込めない理由
(3) 同一マシン構成が速いのは、画像データの転送が丸ごとなくなるためです。しかもこの構成では FileMaker Server も経由しないので、クライアント / サーバー間のデータ受け渡しにかかるコストまで短縮分に含まれています。
ただし、数字だけを見ると魅力的なのですが、これはあくまで「画像データが動かないと、どこまで速くなるか」を確かめるために用意した参考用の構成です。そのまま実務に持ち込むには、次の問題があります。
- AIS ガイドが唯一の推奨構成としているサーバー分離構成から外れます。第1回で「推奨スペックぎりぎり」と書いたマシンに FileMaker Pro を同居させることになり、AI モデルに使えるはずのメモリをクライアントが削ります。そう、「同居はストレス」なのです。
- FileMaker Server にホストされている本番ファイル外で生成した埋め込みは、あとで本番ファイルに取り込む必要があります。
- AI モデルサーバー機で FileMaker Pro を動かすので、いつ、誰が、どのように処理を実行するのか、綿密な運用設計が必要になります。
では、どうするか
画像データが VPN を 2回通るのは、クライアントを経由しているからです。裏を返せば、サーバー側でスクリプトを実行してしまえば、画像データの移動は AI モデルサーバーへの 1回で済むはずです。しかも今回使ったスクリプトステップはすべて、FileMaker Server でサポートされています。(2) 拠点間 VPN 構成でも、サーバー側で実行すれば画像データは VPN を全く通らず、(1) 同一 LAN 構成と同等か、それよりも速くなる可能性があります。
「はずです」と書いているのは、今回測定していないからです。ごめんなさい、泥沼をかき分けて這い上がっているうちに夏休みが終わってしまいました。宿題が最後まで残るのは、いつになっても変わらないようです。
MaxRecPerCall の値の調整とサーバー側での埋め込み生成、やり残した宿題は 2つ。どなたか、試してみてください。
今回のまとめ
3つの構成を実測してわかったのは、次の 3点でした。
- 繰り返し処理で他に実行する作業がなければ、埋め込み生成は 1レコードずつではなく、[対象レコードに埋め込みを挿入] スクリプトステップでまとめて処理
- 画像データを、長い距離移動させない
- FileMaker Pro を経由させず、サーバーサイドスクリプトで実行するとよいかも（未検証）
どれもため息が出るほど当たり前のことばかりです。ただ、AI 機能となると身構えてしまって、「データがどこからどこへ動いているか」という基本を見落としていました。一度泥沼に落ちて、そこから這い出て、ようやく気づいたというわけです。
なお、今回の数値はあくまで筆者の環境での実測値です。マシンの構成やネットワークの状況、扱う画像のサイズによって結果は変わります。数字そのものより、何が効いているかを持ち帰っていただければと思います。
さて、写真 592点に対するマルチモーダル検索の準備が終わりました。次回は検索編。日本語で「草原でシマウマと戯れるとある上司」と入れて、写真は検索されるでしょうか？（件の写真集にそんな写真はありませんでした、念のため）
このブログでご紹介した Claris AI Model Server は、Claris FileMaker 2026（26.0.1）以降でご利用いただけます。これよりも前のバージョンをお使いの方は、最新の無料評価版をダウンロードしてご利用ください。