PSOSで検索・集計を高速化する設定術実践
スクリプト

PSOSで検索・集計を高速化する設定術実践

2026年4月27日 admin スクリプト

FileMakerでデータ量が増えてくると、「検索が遅い」「集計ボタンを押してから待ち時間が長い」と感じることが増えてきます。特にサーバー運用していると、複数人が同時に使うことで、さらに動作が重くなることもあります。この記事では、FileMaker Serverの「PSOS（Perform Script On Server：サーバーサイドスクリプト）」を使って、検索や集計を高速化するための実践的な設定方法を、なるべく専門用語を避けて解説します。

PSOSとは？なにが速くなるのか

PSOSは「スクリプトをサーバー側で実行する」ための仕組みです。通常は、各ユーザーのPC（クライアント）が検索や集計を行いますが、PSOSを使うと次のようなメリットがあります。

  • サーバーはデータに一番近い場所にあるため、検索・集計が速く終わりやすい
  • 重い処理をサーバーに任せることで、ユーザーのPC側の動作が軽くなる
  • 複雑な集計やバッチ処理などを、裏側でまとめてこなせる

つまり、「時間がかかる処理や大量データを扱う処理を、サーバーに肩代わりしてもらう」イメージです。

PSOSを使って高速化しやすい処理の例

PSOSの効果が分かりやすいのは、次のような処理です。

  • 数万〜数十万件単位のレコード検索
  • 売上やアクセスログなどの期間別集計
  • 期間や条件で絞った上での小計・合計の作成
  • 日次・月次レポート用の中間テーブルの更新

逆に「1〜2件だけ更新」「単純な表示切り替え」など、そもそも軽い処理はPSOSにしても体感差はあまりありません。まずは「普段イライラするくらい待たされる操作」からPSOS化を検討するとよいです。

PSOSを使う前に確認しておきたいポイント

PSOSは便利ですが、いくつか事前に押さえておきたいルールがあります。

  • FileMaker Server 上で動くため、ユーザーの画面（レイアウト）は直接触れない
  • 実行結果は、スクリプトの「スクリプト結果」でクライアントに返すのが基本
  • グローバルフィールドやグローバル変数の扱いは「サーバー側のセッション」で独立している
  • プラグインや外部サービスを使う処理は、サーバー側に同じ環境が必要

つまり、「画面で見せる処理はクライアント」、「重い計算やデータ加工はPSOS」と役割分担するイメージで設計すると分かりやすくなります。

基本的なPSOSスクリプトの作り方

ここでは、売上データを期間指定で検索して集計する例で、PSOS用スクリプトの作り方をざっくり説明します。

  1. クライアント側で条件を集める
    日付範囲や顧客IDなど、ユーザーが画面で入力した検索条件を、スクリプト引数（スクリプトパラメータ）にまとめます。
    例：JSON形式で { "start": "2026-04-01", "end": "2026-04-30" } のように渡す。
  2. PSOS専用スクリプトを作る
    FileMaker Server 側で実行される前提で、次のような流れにします。

    • スクリプト引数を受け取り、JSONを分解して条件を取得（JSONGetElement 関数などを使用）
    • 対象テーブルを PSOS 用に用意した「専用レイアウト」で開く（スクリプトステップ「レイアウト切り替え」などを使用）
    • 条件に基づき検索を実行
    • 集計フィールドやサマリーフィールドで集計
    • 結果をJSONにまとめて「スクリプト結果」として返す（JSONSetElement 関数などを使用）
  3. クライアント側でPSOSを呼び出す
    「サーバーでスクリプトを実行」ステップを使い、先ほどのPSOS用スクリプトを呼び出し、「完了まで待機」オプションをオンにして、実行が終わるまで待機する設定にします。
  4. 返ってきた結果を画面に反映する
    スクリプト結果として返ってきたJSONを分解して（Get ( スクリプト結果 ) と JSONGetElement などを使用）、画面上のフィールドやグローバルフィールドに表示します。

高速化のコツ：レイアウトとフィールドの設計

PSOSであっても、レイアウトの設計が良くないと速度は出ません。特に次の点を見直すと効果的です。

  • PSOS用の専用レイアウトを用意する
    表示に不要なフィールド（ポータル、集計用ではないサマリー、画像、外部コンテナなど）は一切置かない、シンプルなレイアウトを作ります。サーバーで開くレイアウトは、できるだけ軽くすることが重要です。
  • 不要な関連レコードの自動ロードを避ける
    ポータルや関連フィールドがあると、その分サーバーが余分にデータを読み込みます。PSOS用レイアウトには基本的にポータルを置かず、関連テーブルの処理が必要なら、別ステップで意識的に行うようにします。
  • 検索対象のフィールドを見直す
    不要な曖昧検索（ワイルドカードや部分一致）を減らし、できるだけ「完全一致」「範囲指定」の検索にすることで、サーバー側の負荷を軽減できます。

PSOSでのエラー処理とログの考え方

サーバー側で動くスクリプトは、ユーザーの目には見えません。そのため、エラーが起きても気づきにくくなります。次のような工夫をしておくと安心です。

  • スクリプトの最初に「エラーを捕捉する［オン］」を設定
  • エラー発生時には、専用のログテーブルに内容を書き込む
  • スクリプト結果に「成功／失敗」とメッセージを含めて返す

クライアント側では、PSOSの戻り値をチェックして「エラーの場合はメッセージを表示する」ようにしておくと、ユーザーにも分かりやすい動きになります。

どこまでPSOS化すべきか？現場での落としどころ

すべての処理をPSOSにすれば良いわけではありません。設計やデバッグの手間も増えるため、次のような基準で選ぶとバランスが取りやすくなります。

  • 実行に数秒以上かかる重い処理
  • データ量が多く、今後さらに増えそうな処理
  • 複数人が同時に使うことで特に遅くなりやすい処理

まずは「集計レポート」「期間別売上」「大量インポート後の再計算」など、よく使うのに重い処理からPSOS化し、様子を見ながら範囲を広げていくのがおすすめです。

まとめ：PSOSで“待ち時間”を減らす設計にシフトする

PSOSは、FileMakerのパフォーマンス改善において非常に効果的な仕組みです。ポイントは「サーバーが得意な重い処理を任せる」「クライアントは画面表示と操作に専念させる」という役割分担の発想です。専用レイアウトの用意や条件の渡し方、結果の戻し方を丁寧に設計すれば、ユーザーの待ち時間を大きく減らすことができます。日々のイライラする操作がある場合は、ぜひPSOSを前提にした設計を一度検討してみてください。

※ 本稿は、生成AIを使用して執筆しています。重要な内容については、必ずご自身でマニュアル等をご確認ください。
#FileMaker Pro