システム開発のサーバー名義は誰にする？外注前の決め方

システム開発を外注するとき、サーバーやドメインを誰の名義で契約するかは、機能や見積もりの話に紛れて後回しになりがちです。この記事では、名義を発注側（事業の持ち主）にするのが基本とされる理由、対象ごとの決め方、契約前に確認しておきたい項目を整理します。新規事業のシステムを外注しようとしている方が、後から困らないための判断材料として読んでいただけます。

結論：名義は事業の持ち主、作業の権限は開発会社に渡す

先に結論です。ドメイン、サーバー（クラウド）、アプリストアのアカウントなどは、事業を運営する側の名義で契約するのが基本です。そのうえで、開発会社の担当者には「作業に必要な権限だけ」を与える形をとります。

名義と権限は別のものです。名義は「その契約の持ち主は誰か」を指し、権限は「そのアカウントで何を操作できるか」を指します。開発会社に作業してもらうために、名義まで渡す必要はありません。

名義を発注側に置くのが望ましいと考える理由は、大きく3つあります。

• 開発会社を変えたり、契約が終わったりしても、事業の土台が手元に残る
• 請求や更新の通知が、事業の持ち主に届く
• 個人情報や顧客データを置く場所の責任を、事業の側が把握できる

新規事業の場合、ドメインは事業の「住所」にあたります。サービスの名前、メールアドレス、検索結果での評価、利用者が覚えているURLなどが積み上がっていく場所です。システムそのものと同じくらい、事業の資産になります。

名義が開発会社のままだと起きやすいこと

名義を開発会社に任せた状態が、すぐに問題になるとは限りません。ただ、後から事情が変わったときに困りやすい点があります。ここでは、起こりうる場面を3つに分けて見ていきます。

開発会社の変更や契約終了のとき

最も影響が出やすいのは、開発会社を乗り換えるときや、保守契約を終えるときです。ドメインやサーバーが開発会社名義のままだと、移すために開発会社の協力が必要になります。

たとえばドメインの移管（別の管理会社へ契約を移すこと）では、登録者の本人確認や、移管用の認証コードの受け渡しが必要です。登録直後は移管できない期間が設けられていることもあります。名義の持ち主が自社でなければ、こうした手続きがすべて相手任せになります。

関係が良好なうちは問題にならなくても、契約終了の場面では、依頼しにくい、対応を後回しにされる、といった行き違いが起こりえます。乗り換え時の確認点は「システム開発会社の乗り換え前に確認したい引き継ぎの要点」でも整理しています。

請求と更新のとき

ドメインやサーバーには、年単位や月単位で更新や課金が発生します。名義が開発会社だと、更新の通知は開発会社に届きます。

担当者の異動や退職、開発会社側の体制変更で通知が見落とされると、更新が漏れてドメインが失効したり、サーバーが止まったりするおそれがあります。失効したドメインは、他の人に取得される可能性もあります。事業で使っていたURLを失うのは、影響の大きい事故です。

反対に、費用を事業側が負担しているのに名義が開発会社のままだと、支払いの実態と契約の名義が食い違い、経理上の説明もしにくくなります。

個人情報や顧客データの責任

会員情報や取引データなどをサーバーに置く場合、その場所を誰が管理しているのかは、情報管理の面でも重要です。名義が開発会社のままだと、事業側が「どこに、どんな設定でデータがあるのか」を自分で確認しにくくなります。

個人情報を扱う事業では、保管場所や管理体制を説明できることが求められます。設計の前に確認したい点は「新規事業の個人情報とシステム設計｜設計前に確認する点」で扱っています。

名義を決める対象は、サーバーとドメインだけではない

「名義」と聞いてサーバーとドメインだけを思い浮かべていると、他の契約が抜け落ちます。システムが動くまでには、次のようなさまざまなアカウントや契約が関わります。

対象	名義で確認したいこと
ドメイン	登録者は誰か、管理会社のアカウントは誰のものか
DNS（ドメインとサーバーを結びつける設定）	設定を変更できるのは誰か
サーバー・クラウド	契約者は誰か、管理者権限は誰が持つか
SSL証明書（通信を暗号化するための証明書）	発行・更新の担当と、期限の通知先
アプリストアのアカウント	開発者アカウントの名義、公開者として表示される名前
外部サービス（メール配信、決済、地図、AIなど）	契約者、APIキーの管理者、請求の宛先
ソースコードの保管場所	リポジトリの持ち主、閲覧・変更できる人

ここからは、特に判断に迷いやすいものを個別に見ていきます。

ドメイン

ドメインでは「登録者」と「管理画面のアカウント」の2つを確認します。開発会社が代行で取得した場合、管理画面のアカウントも登録者の情報も開発会社になっているケースがあります。

確認したいのは次の点です。

• 登録者の欄に、事業を運営する会社（または個人）の名前が入っているか
• 管理会社のアカウントを、事業側が持っているか
• 更新の通知メールが、事業側が受け取れるアドレスに届くか
• 自動更新の設定と、支払い方法が誰のものか

ドメインの種類によっては、登録できる者の条件が決まっています。名義を決める前に、取得したいドメインの登録条件も確認しておくと安心です。

サーバー・クラウド

AWS や Google Cloud などのクラウドサービスでは、契約の持ち主となる管理者アカウントがあります。たとえば AWS では、アカウントを作成したメールアドレスのルートユーザーが最上位の権限を持ち、日常の作業には、権限を絞った別のユーザーを使うのが一般的です。

名義の考え方としては、次のように分けると整理しやすくなります。

• 最上位の管理者アカウントは、事業側が作成して保管する
• 開発会社の担当者には、作業に必要な範囲の権限を持つ個別のユーザーを発行する
• 管理者アカウントには、多要素認証（パスワードに加えて別の確認手段を使う仕組み）を設定する
• 請求の宛先と支払い方法は、事業側のものにする

こうしておくと、開発会社が変わっても、担当者のユーザーを無効にして新しいユーザーを発行するだけで引き継げます。セキュリティの観点では、権限を必要な範囲に絞ること自体も重要です。AIが書いたコードを含む開発での確認点は「AI生成コードのセキュリティ｜確認点と人の役割」にまとめています。

アプリストアのアカウント

スマートフォンアプリを作る場合は、Apple や Google の開発者アカウントが必要になります。このアカウントの名義は、ストアでの公開者名として利用者にも見える部分です。

後から変更しようとすると、手続きが複雑になったり、アプリの移管が必要になったりすることがあります。法人として登録する場合は、企業の識別番号（D-U-N-S番号）の確認を求められることもあります。必要な条件は各社の公式の案内で確認し、早めに準備しておくと進行が滞りません。

外部サービスとAPIキー

決済、メール配信、地図、生成AIなどの外部サービスは、システムの機能の一部を支えています。契約者が誰か、APIキー（外部サービスを呼び出すための合言葉のようなもの）を誰が管理するかを決めておきます。

とくに生成AIのAPIを使う場合、利用量に応じた請求が発生し、入力した情報の扱いも契約条件に左右されます。事業アイデアや顧客の情報を入力するかもしれないため、契約者と設定を事業側が把握しておくことが大切です。確認点は「生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデア」で詳しく扱っています。

ソースコードの保管場所

ソースコードを置くリポジトリ（GitHub などの保管場所）も、名義の対象です。リポジトリが開発会社のアカウントの中にあると、契約終了後に事業側が自分の手でコードを受け取れない状態になりえます。

あわせて確認したいのが、ソースコードの権利です。費用を払ったからといって、著作権が自動で移るわけではありません。保管場所の名義と権利の帰属は別の問題として、それぞれ契約書で確認します。詳しくは「ソースコードの著作権譲渡｜費用を払っても自動では移らない」を参考にしてください。納品物の範囲については「システム開発の納品物一覧｜ソースコード以外に受け取る成果物」も確認しておくと役立ちます。

開発会社の名義で始めたほうがよい場面はあるか

ここまで「発注側の名義が基本」と書きましたが、すべての場面で最初から事業側の名義にしなければならないわけではありません。段階によって使い分ける考え方もあります。

検証用の環境は開発会社側で用意することもある

構想を確かめるための試作段階では、開発会社が用意した検証用の環境で動かすことがあります。この段階では、本番の顧客データを置かず、試作の確認だけに使うという前提であれば、名義が開発会社でも大きな問題にはなりにくいでしょう。

ただし、次の2点は先に取り決めておくと安心です。

• 検証用の環境は、いつまで使い、その後どうするか（削除するのか、移すのか）
• 本番の公開前に、事業側の名義へ移す手順と、そのタイミング

「試作だから」と曖昧にしたまま本番に進むと、試作の環境がそのまま本番になり、名義も開発会社のまま残ることがあります。試作から本番へ進む際の見直しは「MVPから本開発は作り直し？引き継げる部分と見直す点」でも触れています。

事業側に管理できる人がいない場合

社内にエンジニアがいない会社では、管理者アカウントを持っても運用できるか不安に感じるのは自然なことです。その場合も、名義と運用は分けて考えます。

名義と管理者アカウントは事業側が持ち、日々の運用や設定変更は開発会社に任せる、という形が現実的です。保守契約の中で運用の範囲を決めれば、名義を渡さなくても作業を任せられます。保守の対応範囲は「システム開発の保守契約｜納品後の対応範囲の確認点」で整理しています。エンジニアがいない会社の進め方については「新規事業でエンジニアいない会社の進め方｜システム開発」も参考になります。

契約前に決めておきたいこと

名義の話は、開発が始まってから切り出すより、契約や発注の前に決めておくほうが円滑です。確認したい項目を並べます。

取り決めの項目

• 各契約（ドメイン、サーバー、ストアアカウント、外部サービス）の名義を誰にするか
• 管理者アカウントを誰が作成し、どこに保管するか
• 開発会社に与える権限の範囲と、その期間
• 費用の負担者と、請求の宛先
• 更新期限と、更新の通知を受け取る担当者
• 契約終了時の引き継ぎ（認証情報の返却、権限の削除、データの受け渡し）の手順
• 試作用の環境を使う場合、本番へ移す条件とタイミング

これらは、発注書や契約書、あるいは作業範囲を記した資料に書き込んでおくと、後から確認できます。見積もりを比べるときに、前提や範囲を確かめる観点は「システム開発の見積もりの違い｜金額より先に見る前提と範囲」でも扱っています。

納品時にも確認する

名義の取り決めは、納品の場面でも確認します。検収の際に、次の点を実際に確かめておくと安心です。

• 管理者アカウントに、事業側がログインできるか
• 開発会社に発行した権限が、必要な範囲に収まっているか
• 認証情報の一覧が、安全な方法で共有されているか
• 更新期限の一覧が、事業側に渡っているか

「渡したつもり」「受け取ったつもり」を避けるには、実際にログインして確かめるのがいちばん確実です。検収の進め方は「システム開発の検収とは｜納品時の確認項目と進め方」で解説しています。

秘密保持との関係

認証情報や管理者権限は、秘密情報にあたります。開発会社とやり取りする際は、パスワードをメールやチャットに平文で書かない、共有には専用の仕組みを使う、といった取り扱いも合わせて決めておきます。秘密保持契約で決める項目は「システム開発のNDA｜秘密保持で決める8つの項目」にまとめています。

担当者のメールアドレスと個人名義の落とし穴

名義でもうひとつ見落とされやすいのが、登録に使うメールアドレスです。ここが個人のものだと、別の形で問題が起きます。

• 担当者個人のメールアドレスで登録すると、異動や退職の後に、認証メールや更新の通知を受け取れなくなる
• 個人のクレジットカードで支払うと、担当者が替わったときに支払い方法の変更が難しくなる
• 担当者個人の名義で契約すると、事業の資産が会社のものと言い切れなくなる

対策として、次の運用が考えられます。

• 登録用のメールアドレスは、特定の個人ではなく、複数人で受け取れる共有のアドレス（例：事業用の共有メールボックスやメーリングリスト）にする
• 支払いは会社の名義の支払い方法にする
• 管理者アカウントの情報は、会社として保管場所と閲覧できる人を決めておく

新規事業は少人数で始まることが多く、担当者に権限が集中しがちです。属人化を避ける工夫は、事業の継続性を守ることにもつながります。外注全般で失敗しにくくするための進め方は「システム開発の外注｜メリット・デメリットと失敗しない進め方」で整理しています。

すでに開発会社名義になっている場合の見直し方

すでに進行中、あるいは運用中のシステムで、名義が開発会社のままになっている場合もあるでしょう。その場合は、次の順で見直すと進めやすくなります。

1. 現状を棚卸しする。ドメイン、サーバー、ストアアカウント、外部サービス、リポジトリなどについて、名義、契約者、請求先、更新期限を一覧にする
2. 優先順位をつける。失効すると影響が大きいもの（ドメイン、本番のサーバー）から先に確認する
3. 移す方法を開発会社と相談する。移管、名義変更、新規に作り直してデータを移す、など選べる方法はサービスごとに異なる
4. 移行のタイミングを決める。公開中のサービスは、停止時間が出ないよう手順と時期を調整する
5. 移行後に権限を整理する。開発会社の権限を必要な範囲に見直し、事業側が管理者になっていることを確認する

関係が続いているうちに、落ち着いて相談するほうが進めやすいのは確かです。すでにトラブルを経験した場合の見直し点は「システム開発の外注で失敗後のやり直し｜再依頼の見直し点」でも扱っています。

まとめ

システム開発のサーバーやドメインの名義は、事業の持ち主である発注側にするのが基本です。名義を渡さなくても、開発会社に作業に必要な権限を与えれば、開発も運用も任せられます。要点を振り返ります。

• 名義と権限は別物。名義は事業側が持ち、権限は作業に必要な範囲で開発会社に渡す
• 対象はサーバーとドメインだけではない。DNS、SSL証明書、ストアのアカウント、外部サービス、リポジトリも含めて決める
• 試作段階で開発会社側の環境を使う場合は、本番に移す条件とタイミングを先に決める
• 契約前に、名義、費用の負担、権限の範囲、更新期限、終了時の引き継ぎを書面で確認する
• 登録用のメールアドレスと支払い方法は、個人ではなく会社として管理する
• 納品時には、実際にログインして、管理者権限を持てているかを確かめる

どれも、開発が始まる前なら負担の少ない確認ばかりです。名義の話を切り出すことは、開発会社を疑うことではなく、事業を長く続けるための準備と捉えるとよいでしょう。

JustFitは、構想をもとに約1ヶ月で動くプロトタイプを開発し、実物を見てから契約を判断できる受託開発サービスです。何をどこまで決めておけばよいか迷う段階や、仕様が固まる前の段階でも相談できますので、外注の進め方に不安がある場合は、JustFitのサービス紹介をご覧ください。