社内業務システムを外部に発注すると、ほぼ必ずこの提案がついてきます。
「専用サーバーを構築します。」
クラウドではなく、自社専用の環境。
独立していて、外部に依存しない。
そのほうが安全に見えます。
実際、そう説明されます。
ですが、これは逆です。
セキュリティの本質は「攻撃面の大きさ」で決まります。
自社サーバーを持つとは、守るべき面を自分で作ることです。
OSのパッチ適用。ファイアウォールの設定。SSL証明書の更新。ポート管理。不正アクセスの監視。これらすべてを、自社あるいは委託先が管理します。
どこかに穴が開けば、そこから入られます。
管理する人間が優秀かどうかは関係ありません。
管理対象が存在する限り、そこにリスクが生まれます。
構造の問題です。
GoogleのインフラはGoogleが守っています。
GASやGoogle Workspaceで動くシステムは、Googleのインフラの上で動きます。
Googleのセキュリティチームは、それだけをフルタイムでやっている専門集団です。世界中から常時攻撃を受けながら、そのインフラを維持し続けている実績があります。
中小のシステム会社がそれに勝てる道理はありません。
比較の土俵にすら上がれません。
GASのスクリプトは非公開にできます。実行環境はGoogleのインフラ。アクセス制御はGoogleアカウント認証。Google Workspaceエンタープライズ版であれば、組織ポリシーがその上に乗ります。
外部から攻撃するには、このすべてを突破する必要があります。
そこまでの攻撃者が狙うのは、個人の社内業務システムではなくGoogleそのものです。
では、なぜ「専用サーバー」を提案するのか。
技術的な優位性からではありません。
独自サーバーを立てれば、保守契約が発生します。月額ランニングコストが生まれます。継続的な売上になります。
GASで完結すれば、開発費の一回払いで終わります。
それでは継続的な収益が作れません。
「セキュリティのため」という説明は、顧客が判断できない領域を使った価格正当化です。
社内業務自動化に、何が必要か。
ユーザー数名。月数回の実行。同時接続はゼロか一。
このスペックで動くシステムに、高負荷対応も独自サーバーも要りません。
必要なのは、欲しい結果が自動で出ることだけです。
誰も何もしないのに、欲しい結果が出る。
それが自動化の完成形です。
その実現に、複雑なインフラは要りません。