自社用に作った業務ツールを他社にも出すなら会社ごとに別の実行環境で動かす｜サブドメイン・設定ファイル・データ置き場を分ける構成と、未設定なら元の動作になる作りにする理由

自社や最初の取引先のために作った業務ツールが現場で回り始めると、「同じものを別の会社にも使ってもらえないか」という話が出てきます。このとき、最初からたくさんの会社が1つのシステムに同居する作り（マルチテナント）に作り直そうとすると、工事が大きくなり、いま動いている1社目の本番を壊す危険も増えます。

2社目・3社目くらいまでの段階なら、次の形で出すのが現実的です。

• 会社ごとにサブドメインを1つ割り当て、実行環境を丸ごと分ける。 プロセス・ポート・設定ファイル・データ置き場・Webサーバーの設定を会社単位で持つ
• コードは1本にまとめられる作りにし、会社ごとの違いは設定ファイルで切り替える。 業種の違いも「どの業種の文言・設問を使うか」という設定値で選ぶ
• 設定しなければ、今までの1社目と同じ動作になる作りにする。 こうしておくと、新しいコードを1社目の本番に入れても何も変わらず、コードを1本にそろえられる
• 知らない設定値が入っていたら、起動の時点で止める。 打ち間違いのまま動いて、別の業種の文言でお客様に出てしまう事態を防ぐ
• 2社目を展開する前後で、1社目の本番が1文字も変わっていないことを機械的に照合する。
• 監視とバックアップも会社ごとに付ける。 異常の通知は提供する側に届くようにする

以下、名古屋のWEB制作会社graciautoが、白髪染め専門店フランチャイズ（27店舗・2026年9月時点）の本部向けに作った口コミ管理ツール「coecoco」を、業種の違う2社目にも提供している構成をもとに、分け方と判断の基準を紹介します。

実例：1社目と2社目で何を分けたか

coecocoは、店舗のGoogleの口コミを取り込み、新着の通知や返信の下書きを管理画面で扱うツールです。もともと1社の本部向けに作ったもので、2社目は業種もお客様層も違います。

2社目を出すときに分けたものは次のとおりです。

項目	1社目	2社目
URL	既存の独自ドメインのまま（変えない）	「会社の識別名＋3桁の連番」のサブドメイン
実行するプロセス	1社目専用	2社目専用（別のポートで待ち受け）
設定ファイル	1社目専用	2社目専用（業種・契約プラン・通知先など）
データの置き場	1社目専用	2社目専用
Webサーバーの設定	1社目専用の設定ファイル	2社目専用の設定ファイル＋SSL証明書
監視・バックアップ	1社目用	2社目用（5分おきの死活監視・毎日のバックアップを14日分保持）
コード	従来のコード	業種を設定で切り替えられるコード（未設定なら1社目と同じ動作）

プロセス・設定・データは会社ごとに別なので、片方を再起動しても、もう片方には影響しません。2026年10月時点の実測で、1社分のプロセスが常に使うメモリは約110MBでした。小さな業務ツールであれば、会社ごとにプロセスを分けてもサーバーの負担はそれほど大きくありません。

手順1：URLの付け方を先に決める

最初に決めるのは、会社ごとのURLの付け方です。coecocoでは、サービスのドメインの下に「会社の識別名＋3桁の連番」のサブドメインを作る規則にしました（例：example002.example.com）。1社目を001扱いにして、新しい会社ごとに番号を1つ増やします。

ポイントは2つあります。

• 1社目の既存URLは変えない。 すでに店頭のQRコードや案内文で使われているURLを変えると、張り替えの手間が出るうえ、古いQRから入ったお客様が迷います。規則は2社目から当てはめ、1社目は「001番」と台帳上で扱うだけにします
• 番号を付けておく。 会社名だけだと、同じ会社が別の事業部で使いたいときや、試験用の環境を立てるときに名前がぶつかります。連番なら名前が重なっても区別できます

サブドメインはDNSの設定1件で増やせるので、会社が増えるたびに新しいドメインを取る必要もありません。

手順2：実行環境を会社ごとに分ける

次に、プログラムを動かす単位を会社ごとに分けます。分けるのは次の5つです。

1. プログラムの置き場（会社ごとのフォルダ）
2. 設定ファイル（APIキー・業種・通知先・契約プランなど）
3. データの置き場（口コミ・アンケート回答・店舗の情報）
4. プロセスと待ち受けポート（プロセス管理ツールに会社ごとの名前で登録）
5. Webサーバーの設定（サブドメインごとの設定ファイルとSSL証明書）

1つのシステムに全社を同居させる作りと比べたときの利点は、次のとおりです。

• データが混ざらない。 データの置き場が物理的に別なので、プログラムの不具合で他社の口コミが見えてしまう、という種類の事故が構造上起きにくい
• 影響範囲が会社の中で閉じる。 2社目の設定変更や再起動が、1社目の営業時間中の運用に響かない
• やめるときの範囲がはっきりする。 書き出しや削除の対象が、その会社のフォルダ・データ・設定にまとまっている

逆に、会社が増えるほどプロセスの数が増えるので、サーバーのメモリと、更新を全社に配る手間は増えます。この点は後半の判断基準で触れます。

手順3：会社ごとの違いは設定ファイルで切り替える

会社ごとに違う部分を、コードを書き換えずに設定で選べるようにします。coecocoの場合、1社目向けの文言（アンケートの設問、返信の下書きを作るときのルール、緊急として扱う言葉など）がコードの中に多数ありました。2社目は業種が違うため、そのままでは美容室向けの設問が別の業種のお客様に出てしまいます。

そこで、業種ごとの文言と設問を「業種プロファイル」という単位にまとめ、設定ファイルのINDUSTRY_PROFILEという値でどれを使うかを選ぶ形にしました。

• 1社目＝美容室（白髪染め）向けのプロファイル
• 2社目＝2社目の業種向けのプロファイル（設問・緊急として扱う言葉・返信の下書きのルールを業種に合わせて用意）

あわせて、次の2つを入れておくと安全です。

• 知らない値が入っていたら起動しない。 設定の打ち間違いで既定の業種のまま動き、別業種の文言がお客様に表示される、という事態を防げます。起動しなければその場で気づけます
• 1社目向けの初期データは、1社目の業種でしか作らない。 初期化のときに1社目の店舗の雛形が作られる作りだと、別の会社の管理画面に1社目の店舗が並んでしまうおそれがあります。他の業種では初期データを空にします

手順4：設定しなければ元の動作になる作りにする

ここがこの記事でいちばん伝えたい点です。新しく足した設定値は、何も設定しなければ、これまでの1社目とまったく同じ動きをするように作ります。coecocoでは、INDUSTRY_PROFILEを設定しない場合は美容室として動きます。

こうする理由は、コードを1本にまとめられるようにするためです。

• 1社目の本番にこの新しいコードを入れても、設定ファイルを触らなければ何も変わらない
• だから、1社目も2社目も同じコードにそろえられる
• そろえた後は、修正や機能追加を1回すれば、全社に同じものを配れる

2社目を出す時点で1社目の本番まで入れ替える必要はありません。1社目は従来のコードのまま動かしておき、3社目を迎える前など区切りのよいところで、同じコードにそろえる段取りが組めます。

反対に、2社目用にコードをコピーして書き換える形で増やすと、最初は早く出せますが、不具合の修正や改善のたびに会社の数だけ手で直すことになります。3社目、4社目と増えるほど、どの会社にどの修正が入っているかを追えなくなります。

「同じ動きをする」ことは、言葉で確認するのではなくテストで確かめます。coecocoでは、設定しない状態での画面や文言の出力が、変更前と完全に一致することを確かめるテストを追加しました。既存のテスト105件に新しく19件を足し、合計124件がすべて通ることを確かめています。画面用のファイルは書き換えず、配信するときに業種ごとの文言へ置き換える形にしたのも、1社目の画面を変えないためです。

手順5：展開の前後で1社目の本番が変わっていないことを照合する

2社目の環境を1社目と同じサーバーに作る場合、作業の途中で1社目の設定やファイルに触れてしまうと、気づかないまま1社目のお客様に影響が出ます。

coecocoの展開用スクリプトには、次の安全策を入れています。

• 作業の前後で、1社目の本番の「指紋」を照合する。 コード・設定ファイル・プロセスの登録内容・Webサーバーの設定について、作業前と作業後で中身が完全に同じかを機械的に比べる
• 名前やポートが既存のものと重なったら中止する。 1社目のプロセスやURLを上書きしてしまう事故を入口で止める
• Webサーバーの設定チェックに失敗したら元に戻す。 設定の書き間違いで、同じサーバー上の全サイトが止まることを防ぐ
• DNSがまだ反映されていなければ、SSL証明書の取得だけを後回しにする。 反映を待ってから同じスクリプトをもう一度実行すればよい
• 何度実行しても同じ結果になるように作る。 途中で止まっても、最初からやり直せる

照合で見るのは、既存の本番のコード・設定・プロセス・Webサーバーの設定がすべて作業前と同じであることと、既存のURLが正常に応答していることです。

手順6：監視とバックアップを会社ごとに付ける

最後に、2社目にも1社目と同じ水準の監視とバックアップを付けます。coecocoでは2社目に、5分おきの死活監視と、毎日深夜のバックアップ（14日分を保持）を設定しました。

ここで決めておきたいのが、異常の通知をどこへ送るかです。2社目の利用者が使っている連絡手段（たとえばLINE公式アカウント）に監視の通知まで流すと、相手の無料の送信枠を減らしてしまいます。監視の異常・復旧の通知は、提供する側（自社）が受け取る経路に送るのが筋です。

相手の既存の仕組みとぶつかる機能は絞って出す

他社に出すときは、相手がすでに使っているツールと機能が重なることがあります。2社目の会社のLINE公式アカウントでは、LINEからの受信（Webhook）を配信ツールがすでに使っていました。LINE公式アカウントのWebhookの送り先は1つしか設定できないため、coecocoがここを使うと、既存の自動応答が止まってしまいます。

そこでcoecocoに、LINEを通知を送るだけで使う設定を用意し、2社目ではこの形にしました。設定ファイルで「送信のみ」を指定すると、受信の入口は閉じられ、口コミの新着通知はスタッフのグループへ送るだけ、返信の操作は管理画面から行う形になります。あわせて、通知に使うチャネルのトークンは再発行しないことを運用ルールにしています。再発行すると、今動いている通知が止まるためです。

既存のLINE公式アカウントにツールを足すときの注意点は、友だち数千人の既存LINE公式に拡張ツールを入れるときの注意点でも詳しく書いています。

判断基準：会社ごとに分けるか、1つのシステムに同居させるか

会社ごとに実行環境を分ける形は、どこまでも続けられるわけではありません。目安は次のとおりです。

状況	おすすめの形
2〜3社目まで、業種が少しずつ違う	会社ごとに実行環境を分ける（この記事の形）
会社が増えてきて、更新を配る手間が目立つ	コードを1本にそろえ、展開・監視・解約の手順をスクリプト化する
数十社以上、同じ業種で設定の違いが小さい	1つのシステムに同居させる作りへの作り直しを検討する

会社ごとに分ける形を続けるときに、先に手当てしておきたいのは次の点です。

• コードを会社ごとにコピーしない。 違いは設定とデータに寄せ、1本にそろえたコードを全社に配る。配った後は、各社の環境に同じ版が入っていることを照合する
• 1社目向けの店舗の雛形や固有の文言は、1社目の業種を選んだときだけ使う。 他の業種の会社の画面に、1社目の店舗や文言が出ないようにする
• 提供先を増やしていく前提なら、提供用のサーバーを本業の本番とは別に用意する。 他社側の負荷や障害が、自社の本番に響かないようにするため
• 解約のときの手順を先に決めておく。 データを書き出して渡す、消す、外部サービス（Googleや LINE）の権限を外す、の順番を決めておくと、やめるときに慌てない

本番に手を入れるときの基本的な確かめ方は、手元のファイルを本番へ上げる前に「どちらが新しいか」を確かめるでも紹介しています。また、サブドメインを使った構成で外部からの接続先が古いまま残る問題については、WordPressのREST APIが突然404になるときが参考になります。他社に紹介するための画面の見せ方は、自社サービス（SaaS）の機能紹介動画の作り方にまとめています。

まとめ

自社や1社目のために作った業務ツールを他社にも出すときは、最初から大きなシステムに作り直すより、会社ごとに実行環境を分けて出すのが安全で早い方法です。

• 会社ごとにサブドメインを割り当て、プロセス・設定ファイル・データ置き場・Webサーバーの設定を分ける。1社目の既存URLは変えない
• 会社ごとの違いは、コードではなく設定ファイルで切り替える。知らない設定値なら起動しない
• 新しい設定値は、未設定なら1社目と同じ動きになるように作り、それをテストで確かめる。これでコードを1本にそろえられる
• 展開の前後で、1社目の本番が変わっていないことを機械的に照合する
• 監視とバックアップは会社ごとに付け、異常の通知は提供する側が受け取る
• 相手の既存ツールとぶつかる機能（LINEの受信など）は、送るだけに絞って出す

graciautoでは、美容室・店舗ビジネス向けの業務ツールを、自社の現場で使える形に作り、ほかの会社にも使える形へ広げるところまで支援しています。社内で使っているツールを取引先にも出したい、という段階で構成に迷っている場合は、今の作りを見ながら一緒に整理するところからご相談いただけます。