プリザンターを業務で活用するための導入・設計・運用をご支援しています。
プリザンターでは、同じ要件を サーバスクリプト でも スクリプト（クライアント側） でも実装できる場面が少なくありません。
そのため現場では、「サーバスクリプトのほうが実装が簡単だから」という理由で選択されるケースをよく見かけます。
確かに、サーバスクリプトは 実装が簡単に感じられることが多い のは事実です。
しかし「簡単そうだから」という理由だけでサーバ側に寄せてしまうと、後になって 遅い・重い・待つ といった問題に直面することがあります。
本記事では、「どちらが正解か」ではなく、「どんな観点で選ぶべきか」という視点で、サーバスクリプトとスクリプトの使い分けを整理します。
- サーバスクリプトとスクリプトの役割の違い
- なぜ「実装が簡単」だとサーバスクリプトに寄せがちなのか
- どちらでも実装できる場合の判断基準
- スタイルとスクリプトの使い分けも考えておく
- 設計で迷うのは「実装」より「運用フェーズ」
- まとめ
サーバスクリプトとスクリプトの役割の違い
サーバスクリプトとは
サーバスクリプトは、サーバサイドで JavaScript を実行し、条件分岐や計算、文字列処理、レコード操作などの業務ロジックを実装するための仕組みです。
レコードの作成前・更新前・更新後といった サーバ側の処理タイミング に紐づけて実行されます。
サーバスクリプトが「実装が簡単に感じられる」ことが多い理由は、ここで言う“簡単”が、同じ要件を実現するためのコード量が少なく、非同期処理や画面制御などを意識せずに済むという意味だからです。
たとえば、他のレコードやテーブルの情報が必要な場合でも、サーバスクリプトでは items.Get のようなメソッドを使って、必要なデータをその場で取得できます。
クライアント側のように「どのタイミングで取得するか」「非同期でどう扱うか」「画面の状態とどう整合を取るか」といった点を考える必要がなく、業務ロジックそのものに集中して実装しやすいのが特徴です。
サーバスクリプトの詳細については、下記記事をご参考ください。
スクリプトとは
一方、スクリプト（クライアント側）は、主に 画面表示やユーザー操作に即応する処理 を担います。
入力値に応じた自動補完や表示の切り替えなど、ユーザー体験に直結する処理が得意な領域です。
ただし、画面で操作している以外のデータを参照・集計・判定したい場合には、追加のデータ取得や制御が必要になります。
その結果、非同期処理や画面制御などの考慮点が増え、その分だけコード量が増えがちになるのが実情です。
スクリプトについての詳細は、下記記事をご参照ください。
なぜ「実装が簡単」だとサーバスクリプトに寄せがちなのか
サーバスクリプトは実装が簡単なことが多い
実務上、サーバスクリプトは次のような理由から「簡単に書ける」と感じられやすい傾向があります。
-
必要なデータを
items.Getなどで取得できる -
非同期処理を意識せずにロジックを書ける
-
画面状態やユーザー操作を考慮しなくてよい
特にデータ中心の処理では、「やりたいこと」をそのままコードに落とし込みやすく、初期実装がスムーズに進みやすいのがサーバスクリプトの強みです。
その判断が後で苦労につながる理由
しかし、「実装が簡単だから」という理由だけでサーバスクリプトに寄せてしまうと、後になって問題が表面化することがあります。
サーバスクリプトは、処理のたびにサーバ側で実行されます。
そのため、データ量や利用者が増えると、
-
サーバ負荷が高まる
-
処理待ちが発生する
-
画面操作のたびに“待たされる”体験になる
といった影響が出やすくなります。
最初は問題なかった処理が、運用フェーズで一気にボトルネックになる
これは、現場でよく見られるパターンです。
どちらでも実装できる場合の判断基準
判断軸① 処理の即時性・体感速度
ユーザーの操作に対して 即座に反応したい処理 は、クライアント側で完結させた方が体感速度は良くなります。
入力補助や表示切り替えなど、操作に対してリアルタイムな反応が求められる処理は、サーバ通信を挟まない方が自然です。
たとえば、入力値に応じて項目を自動補完したり、条件に応じて表示・非表示を切り替えたりする処理では、サーバ側で処理を行うと、そのたびに通信待ちが発生します。
処理自体は軽くても、ユーザーの操作回数が増えるほど「ワンテンポ遅れる」「入力が引っかかる」といった体感の悪さにつながります。
判断軸② データ量・実行回数・サーバ負荷
処理そのものが軽くても、実行回数が増えればサーバ負荷は蓄積します。
特に入力補助のように、ユーザー操作のたびに実行される処理は注意が必要です。
入力補助は、クライアント側で処理できる部分が多く、サーバとの往復回数を減らしやすい領域です。
マスタ参照が必要な場合でも、
-
画面表示時に一度だけデータを取得して使い回す
-
入力に必要な範囲に絞ってデータを取得する
といった設計にすることで、入力のたびにサーバ処理を実行する設計を避けられることが多いです。
一方、同じ処理をサーバスクリプト側に寄せると、保存や更新のたびにサーバ処理が実行されます。
1回あたりの処理は軽くても、操作回数や利用者数が増えたときに影響が表面化しやすい点は、設計時に意識しておくべきポイントです。
判断軸③ セキュリティ・整合性・最終判断
権限チェックやデータ整合性の担保、最終的な確定処理 は、サーバ側で行うべき領域です。
クライアント側の処理は、あくまでユーザー操作を補助するものであり、最終的な正しさを保証する場所ではありません。
入力途中の補助や仮判定はクライアント側で行い、
保存・更新時の最終チェックや確定処理はサーバ側で行う、
といった役割分担を意識することで、安全性と拡張性の両立がしやすくなります。
スタイルとスクリプトの使い分けも考えておく
プリザンターでは、画面の見せ方や操作性に関する制御を、スタイルとスクリプトのどちらでも実装できる場面があります。
そのため、実装前に「どこまでをスタイルで解決し、どこからをスクリプトに任せるか」を意識しておくことが重要です。
表示や入力可否など、見た目や操作性に関わる制御については、
ロジックを書き始める前に スタイルで実現できないかを先に検討する ことで、実装や運用が安定しやすくなります。
一方で、値の計算や他項目への影響、複雑な条件分岐など、業務ロジックを含む処理は、
スクリプトの役割としたほうが良い場合が多いでしょう。
設計で迷うのは「実装」より「運用フェーズ」
小さく始めた実装でも、全体展開や長期運用の中で、利用者数やデータ量、業務フローといった前提条件は少しずつ変わっていきます。
そのときに問題になるのは、「どのように実装したか」そのものよりも、なぜその実装を選んだのかが分からなくなってしまうことです。
たとえば、
-
なぜこの処理はサーバスクリプトで実装しているのか
-
どこまでをクライアント側で完結させる想定だったのか
-
当初は問題なかったが、今の利用規模でも同じ前提でよいのか
といった判断理由が共有されていないと、
改善や見直しをしようとした際に 「触っていいのか分からない」「どこを直せばいいか分からない」 状態に陥りがちです。
結果として、本来であれば小さな見直しで済むはずの変更が、大きな調査や作り直しにつながり、修正コストが一気に膨らむことも少なくありません。
だからこそ、実装時点で 役割分担や判断軸を意識しておくこと が、運用フェーズでの迷いを減らすことにつながります。
まとめ
今回は、プリザンターで サーバスクリプトとスクリプトのどちらでも実装できる場面 において、どのような観点で実装場所を判断すべきかを整理しました。
サーバスクリプトは、コード量が少なく実装しやすいケースが多い一方で、実行回数や利用規模が増えると、体感速度やサーバ負荷の面で課題が表面化しやすくなります。
一方、スクリプト（クライアント側）は、非同期処理や画面制御といった考慮点は増えるものの、即時性が求められる処理や、サーバとの往復回数を抑えたい処理では有効な選択肢になります。
どちらが正解かを一律に決めることはできませんが、即時性・実行回数・セキュリティや整合性 といった観点で整理して考えることで、「なぜその実装にしたのか」を説明できる設計に近づけるはずです。
こうした判断は、実装時だけでなく、運用が始まってからや、利用範囲が広がったタイミングで改めて見直す必要が出てくることも少なくありません。
その際に、状況に応じて 第三者の視点を取り入れて整理してみる ことも、設計を見直す一つの手段と言えるでしょう。
それでは、今回はこの辺で。
最後までご覧いただき、ありがとうございました。
