ドメインとサーバの基礎 — 「自社で持つもの」と「業者に委ねていいもの」
この記事でわかること
Lesson 1-1 で「Web担当者の仕事はコミュニケーションの管理」、Lesson 1-2 で「Web サイトの種類」を整理しました。 ここからは、もっと土台の仕組みに降ります。 ドメインとサーバ、そして DNS。 この 3 つを正しく理解しているかどうかで、業者と話すときの会話の深さが変わります。 技術の細部に踏み込む必要はありません。 「街の仕組み」になぞらえて、必要な分だけ押さえていきましょう。
1. インターネットを「街」に例えてみる
Web の仕組みは、街と郵便配達の関係に置き換えて理解すると、一気に腹落ちします。
1-1. ドメイン=住所
`www.example.com` のような名前が、ドメインです。 これは「住所」だと思ってください。 覚えやすい名前で、訪問者があなたのサイトに辿り着くための入口の表札です。
1-2. サーバ=土地と建物
一方、サイトの実体(HTML や画像、プログラム)が置かれているのが「サーバ」です。 これは、街の中の 土地と建物 に相当します。 どんな立派な住所(ドメイン)があっても、土地と建物(サーバ)が無ければサイトは存在できません。
1-3. DNS=住所と土地を結ぶ住民票
住所と土地は、初期状態では結びついていません。 結びつけるのが「DNS(Domain Name System)」です。 DNS は、いわば 役所の住民票 のような仕組みで、「この住所は、この土地のことです」と教えてくれます。 詳しくは H2-8 で扱いますが、Web の世界で「見えないけど一番大事な仕組み」がこれです。
1-4. ブラウザでアクセス=郵便配達
訪問者がブラウザでアドレスを入力する動きは、郵便配達と同じです。 住所(ドメイン)を見て、役所(DNS)に「この住所はどの土地ですか?」と確認し、教えられた土地(サーバ)にデータを取りに行く。 一瞬で済む処理ですが、内部ではこの 3 ステップが必ず動いています。
ここで一つ覚えておいてほしいのが、住所・土地・住民票の所有者と管理者は、全部別人にできる ということです。 ドメインを A 社の名義で、サーバを B 社が運営し、DNS は C 社が管理している、という状態が普通に成立します。 この「別々にできる」性質が、これから話す落とし穴の出発点です。
2. ドメインの基本知識
2-1. ドメインの構造
`blog.example.co.jp` のようなドメインは、右から順に分解できます。 一番右が TLD(トップレベルドメイン)。`.com` `.jp` `.co.jp` などです。 その左が SLD(セカンドレベルドメイン)。`example` の部分にあたります。 一番左が サブドメイン。`blog.` のような前置きです。 SLD は会社名・サービス名で命名できる部分で、TLD と組み合わせて「ドメイン」と呼びます。
2-2. `.com` `.jp` `.co.jp` の違い
どの TLD を選ぶかで、取得条件・費用・社会的信頼性が変わります。 `.com` は世界共通で取得制限なし、価格も安い、というのが特徴です。 `.jp` は日本に住所がある個人・法人なら取得可、価格は中程度。 `.co.jp` は日本に登記された 株式会社・有限会社などの法人 1 社につき 1 つだけ 取得できる特別な TLD で、価格は高めですが、その分「日本の法人である」という信頼性のサインになります。 自社が法人なら、コーポレートサイトには `.co.jp` をおすすめします。
2-3. 取得・管理する場所(レジストラ)
ドメインを取得・管理するサービス事業者を レジストラ と呼びます。 国内では「お名前.com」「Value-Domain」「ムームードメイン」「さくらインターネット」など、海外では「Cloudflare Registrar」などが代表的です。 どのレジストラを使うかは、管理画面の使いやすさ・サポート体制・料金で選びます。 乗り換え(移管)も可能ですが、手続きが煩雑なので、最初に選ぶときに少し時間をかけて検討する価値があります。
2-4. 更新と失効リスク
ドメインは 1 年単位の更新契約 が基本です。 更新を忘れると、最悪の場合ドメインを失います。 レジストラの自動更新を有効にし、登録メールアドレスを複数人で受信できる状態にするのが鉄則です。 後で詳しく扱いますが、個人クレジットカードでの自動更新は事故の元なので、必ず法人カードか法人口座を使いましょう。
3. ここが核心:ドメインは「自社で持つ」が原則
この Lesson で一番伝えたいのが、ここからの話です。 ドメインの所有・管理は、必ず自社で行ってください。 これを業者に任せると、後でとんでもないトラブルになります。
3-1. なぜ自社管理が必要か
ドメインを失うと、起きることはサイトが見られなくなるだけではありません。 SEO 評価がゼロからのやり直しになります。ドメインに紐づいたメールアドレスも全停止、名刺・案内・既存資料に書かれた連絡先がすべて無効になります。 一瞬で会社の Web 上の連絡経路が消えるわけです。 一度失ったドメインは、第三者に奪われると二度と戻ってきません。
3-2. 「業者名義」になっていると起きる現実
現場で一番多いトラブルが、これです。 ドメインを業者名義で取得してもらっていると、次のような事態が起きます。
- 業者を変えようとした瞬間、「移管できません」と握られる
- 「うちで管理するなら年◯万円」と、強引な増額提示をされる
- 業者が倒産・連絡途絶で、ドメインを取り戻せなくなる
どの状況も、自社の事業活動が業者に依存して詰まる、という構造的な問題を引き起こします。
3-3. すでに業者名義の場合の取り戻し方
今のドメインが業者名義になっている場合、なるべく早く自社名義に変更してください。 手順は、まず現業者に「移管」または「名義変更」を申請します。 業者がスムーズに応じてくれるなら手続きは数週間で完了します。 応じない業者の場合は、契約書を確認し、第三者(顧問弁護士・専門家)を介して交渉する、というのが現実的な進め方です。 最悪、業者が倒産・連絡途絶の場合は、レジストラに直接相談する必要があります。 いずれにしても、対応は早いほど傷が浅く済みます。
3-4. これから取る場合の正しい取り方
これから新規ドメインを取る場合、最初から自社名義で取ってください。 支払いは法人カードか法人口座振替を使い、管理アカウントは 複数人がアクセスできる 状態にしておきます。 担当者個人のメールアドレスだけで管理すると、その人が退職した瞬間に詰みます。 `domain@your-company.com` のような、共有メールアドレスで登録するのが鉄則です。
4. サーバの基本知識
4-1. 3 種類の選択肢
サーバには大きく分けて 3 種類の選択肢があります。
- レンタルサーバ:エックスサーバー、さくらのレンタルサーバ、ロリポップ、heteml など。月数百円〜数千円で借りられて、設定が簡単。中小企業のコーポレートサイトはこれが定番です。
- クラウド(AWS / GCP / Azure):従量課金で柔軟。EC、SaaS、大規模メディアなど、トラフィックの変動が大きい案件で使われます。専門知識が必要です。
- 自社サーバ:自社内に物理サーバを置く構成。セキュリティ要件が極めて高い特殊案件以外では選びません。
4-2. 何を見るか
サーバを選ぶとき、最低限見るべき項目は決まっています。 容量、転送量、対応言語(PHP・Node.js など)、SSL 対応、メール機能、ステージング環境(本番にデプロイする前に試せる環境)、バックアップ、サポート体制 — このあたりです。 各項目の意味は、Lesson 1-5 で詳しく扱います。 今は「これらの項目を比較するのだな」とだけ覚えておいてください。
4-3. 国内主要サービスのざっくり位置づけ
国内のレンタルサーバは、おおまかに価格と機能で 4 層に分けて見るとわかりやすいです。
- 安価層(月数百円):個人ブログや小規模なコーポレート向け。機能は最低限
- 標準層(月千円〜数千円):中小企業のコーポレート・サービスサイトの定番。ほとんどの案件はここで足りる
- 高速層(月数千円〜):読み込み速度に投資したいメディア系、複数サブドメイン運用
- クラウド型(従量課金):EC、SaaS、大規模メディア
「どれが正解か」はサイトのタイプと規模で変わります。 だから本書では、特定のサービスをおすすめする書き方はしません。 判断軸を 5 つ持ったうえで、自分で選んでください。 その軸は H2-7 で整理します。
5. ここがもう一つの核心:サーバは「業者に委ねる」も正解
5-1. ドメインと違って、サーバは外注して構わない
H2-3 では「ドメインは自社管理が原則」と書きました。 では、サーバはどうか。 答えは「外注して構わない」です。 これは矛盾ではなく、両者の性質の違いから来ています。 ドメインは「権利」、サーバは「技術」。 権利は自社で持たないと取り戻せませんが、技術は専門家に任せるほうが安全な場面が多いのです。
5-2. 判断軸:自社にサーバ管理スキル/トラブル対応体制があるか
自社管理が成立するのは、社内に サーバ運用のスキル と 24 時間対応できる体制 がある場合だけです。 どちらかが欠けるなら、業者管理のほうが現実的です。 中小企業で、専任のサーバ担当者がいるケースは少ないはずです。 無理に自社で抱えると、障害時に対応できず、結局事故が大きくなります。
5-3. 業者管理にする場合の最低条件
サーバを業者に委ねる場合、契約に最低限以下を盛り込んでください。
- 定期バックアップの取得と保管(頻度・保管期間・保管場所)
- 障害時の連絡 SLA(連絡時間・対応開始までの目安)
- 月次レポート(稼働率・障害履歴・対応内容)
- 退会時のデータ返却手順(全データを引き取れる状態)
詳細は Lesson 3-5 で扱いますが、契約段階でここを詰めておかないと、後で動けなくなります。
5-4. 「自社で管理できない=Web担当者失格」ではない
新米担当者ほど「サーバが分からない自分は失格なのではないか」と感じがちです。 そんなことはありません。 Lesson 1-1 でも書いたとおり、Web担当者の責任は 「すべてを自分で触ること」ではなく「適切な管理体制を作ること」 です。 サーバの技術は専門家に任せ、自分は「業者と適切に対話できる」状態を作る。 これが本書を通じて目指す担当者像です。
6. ドメイン・サーバ管理は「5 つの権限」で分けて考える
H2-3 で「ドメインは自社管理」、H2-5 で「サーバは外注可」と並列で示しました。ただし「自社管理」「外注」は単一の概念ではありません。名義 / 契約者 / 管理権限 / 運用作業 / 緊急時対応 の 5 つの権限 を分けて考えると整理しやすくなります。Lesson 1-1 H2-4 の 4 役マトリクスを、業務に適用する最初の例です。
6-1. 名義(=登録上のオーナー、最重要)
ドメインのレジストラ登録上の所有者、サーバ契約上の所有者です。 原則として自社(法人または代表者個人) が持ちます。 業者名義は最大の警戒サイン(H2-3 の一言アドバイス ① と完全連動)。 名義変更には本人確認等のハードルがあるので、最初から自社名義で取るのが鉄則です。 名義は譲渡できる権利。業者に渡した瞬間に「握られる」リスクが生まれます。
6-2. 契約者(=決済の主体)
月額・年額料金の支払い義務者です。 原則として自社、法人カード or 法人口座振替で支払います。 担当者個人のクレジットカードでの自動更新は事故の元です。 そのカードの期限切れ、本人の退職、いずれも起きた瞬間にサービス停止のリスクになります。 契約者を業者にするのも避けてください。 業者が支払いを停止した瞬間にサービスが止まります。
6-3. 管理権限(=設定変更ができる権限)
レジストラ管理画面、サーバ管理画面、DNS 管理画面へのログイン権限です。 自社と業者の両方が持っている状態が現実解 です。 自社がオーナー権限を持ち、業者には運用権限を渡す。 業者だけに権限を渡すと、業者交代時にロックアウトされます。 自社だけが持って業者に渡さないと、現場で動けません。 アカウントは個別に発行し、業者との契約終了時にはアカウントを停止する運用にしてください。
6-4. 運用作業(=日常の手作業)
DNS レコードの追加・変更、サーバ設定変更、SSL 証明書の更新、バックアップ取得 — このあたりです。 業者に委託可能な領域 です。 専門性が高いので、無理に自社で抱える必要はありません。 委託先と「何を頼むか」を契約に明記する(Lesson 3-5)、自社は「依頼する」「結果を確認する」「承認する」の 3 役を担う、というのが現実的な分担です。
6-5. 緊急時対応(=障害・乗っ取り・失効時の動き)
サーバ障害、ドメイン乗っ取り、SSL 失効、DDoS 攻撃、データ漏洩 — これらが起きたときの動き方です。 業者の SLA で担保 するのが基本です。 自社が「最終判断者」、業者が「実行者」、責任は自社が負う、という構造になります(Lesson 1-1 H2-4 の 4 役そのまま)。 連絡フロー、対応時間、エスカレーション先を契約段階で決めておく必要があります(Lesson 3-5 で詳しく)。
6-6. 5 つの権限を分けて整理した結果 — 担当者の打ち手
「ドメインは自社、サーバは業者」という大まかな言い方を、5 権限のマトリクスで具体化したのが、上の整理です。 H2-9 で扱う契約台帳に、この 5 権限を分けて記入してください。 業者選定時(Lesson 3-1)、契約締結時(Lesson 3-5)、業者交代時 — それぞれの局面で、5 権限の担当者を再確認します。
7. 「うちはどのサーバを使えばいい?」— 5 軸で自分で選ぶ
業者に「うちはどのサーバがいいですか?」と聞きたくなる気持ちはわかります。 でも、それでは判断軸が育ちません。 次の 5 軸で自分でスコアリングして、最終判断を下せるようになってください。
7-1. 軸 1:サイトタイプ
コーポレート、サービス、LP、オウンドメディア、EC、Webサービスのどれか。 タイプによって必要な機能が大きく変わります。 EC なら決済対応・在庫連動・SSL の要件が高くなり、オウンドメディアなら表示速度の優先度が上がります。
7-2. 軸 2:規模
月間 PV、画像や動画の容量、同時アクセス想定数 — このあたりです。 小規模なら標準層で十分。 アクセスが急増する見込みがあるなら、最初から余裕を持ったプランか、クラウド型を検討します。
7-3. 軸 3:必要機能
PHP・Node.js などの対応言語、CMS(WordPress 等)の対応、SSL 対応、メール機能、ステージング環境、WAF(Web Application Firewall)などです。 「あとから増やせる機能」と「最初に決めておく機能」を分けて考えると、選定が楽になります。
7-4. 軸 4:予算
月数百円〜数万円までレンジが広いのがサーバの特徴です。 「安ければ良い」でも「高ければ安全」でもなく、自社サイトの規模・目的に対して適正なコスト を見極めます。 Lesson 3-3 で詳しく扱いますが、激安は「中間マージン無し=管理工程の省略」を意味するケースが多い、と覚えておいてください。
7-5. 軸 5:トラブル時の対応
サポートの言語(日本語・英語)、連絡手段(電話・メール・チャット)、障害時の SLA(対応時間)、自社の業務時間との整合性。 夜間・休日にサポートがつながらないサーバを選ぶと、その時間帯の障害で何時間も止まる、というのは現場あるあるです。
タイプ別の目安としては、コーポレートサイトなら標準層で十分、EC や SaaS ならクラウドが定番、メディアは高速層を選ぶ、というあたりです。
7-6. サーバ選定の判断レイヤーを切り分ける
「5 軸で自分で選ぶ」は、担当者が判断軸を持つ という意味です。 すべてを担当者単独で決める、という意味ではありません。 Lesson 1-1 H2-4-4 の判断 3 レイヤーで切り分けて考えてください。
レイヤー 1(担当者単独 OK):小規模コーポレートサイト、LP、お知らせサイト、社内向けのサイト。規模が小さく、扱う情報が一般公開のみ、PV が低い案件です。担当者が 5 軸スコアシートで主要レンタルサーバから選んで OK。
レイヤー 2(専門家と擦り合わせて判断):中規模オウンドメディア、複数サブドメイン運用、SEO 重視、画像・動画の多用。制作会社・運用業者と相談し、5 軸スコアシートを共有して最終判断します。担当者が判断軸を持って業者と対話する場です。
レイヤー 3(専門家に判断を委ねる):EC / 会員制 / 個人情報を扱う / 決済を伴う / メール大量配信 が絡む案件は、サーバ選定の判断難易度が高く、担当者単独で決めるのは危険です。制作会社・SI・社内情シス・顧問専門家(セキュリティ・個人情報保護)と一緒に決めてください。担当者の役は「自社の要件を整理する」「専門家の判断結果を運用に反映する」「専門家への質問を整理する」までです。Lesson 2-1 H2-7(企画段階の前提条件)、Lesson 3-5 H2-5-8(契約での個人情報・SLA)と接続します。
自社の案件がどのレイヤーかを、サーバ選定の前に必ず確認してください。 「5 軸で自分で選ぶ」が成立するのはレイヤー 1〜2 まで。 レイヤー 3 では別フローに乗せます。
テンプレ DL:サーバ選定 5 軸スコアシート(本書のテンプレ集に収録予定)
8. DNS — 見えないけど一番大事な仕組み
8-1. DNS の役割
H2-1 で「住所と土地を結ぶ住民票」と書いたのが DNS です。 具体的には、ドメインに対して「このサーバの IP アドレスに繋いでください」という指示を持つ仕組みです。 DNS の設定が間違っているとサイトに繋がらない、という最重要のインフラなのに、見えにくいので軽視されがちです。
8-2. メール(MX レコード)もここに繋がっている
DNS が管理しているのはサイトの繋ぎ先だけではありません。 メールの受信先(MX レコード)、SPF・DKIM などの送信認証、その他のサービスとの連携 — 全部 DNS が握っています。 サーバ移転のときに「メールが受信できなくなった」事故が起きるのは、ほぼ DNS の設定ミスが原因です。
8-3. 「反映待ち 24〜72 時間」の正体
DNS の設定変更には、世界中の DNS サーバに情報が伝わるまでの時間がかかります。 一般に「反映待ち 24〜72 時間」と言われるのは、このためです。 サーバ移転や DNS 変更のスケジュールは、この待ち時間を織り込んで設計します。 金曜日の夕方に変更して土日に反映を待つ、というのが定番パターンです。
9. 担当者が必ず押さえる「契約情報の台帳化」
Lesson 1-1 で書いた「現行サイトの成り立ちを把握する」の核は、この契約情報の台帳化です。 台帳に書く項目は次のとおりです。
- ドメイン名
- 5 権限ごとの主担当(名義 / 契約者 / 管理権限 / 運用作業 / 緊急時対応)
- 更新日(ドメイン・サーバ・SSL)
- 支払い方法(法人カード番号末尾、振替口座、自動更新の有無)
- DNS 設定先(どのレジストラ・どの管理画面で設定しているか)
- 担当業者(連絡窓口・担当者名)
- 緊急連絡先(夜間・休日)
- SLA(契約書のどこに書かれているか)
退職時・引き継ぎ時に、この台帳があるかどうかで、後任者の動き出しが何倍も変わります。 H2-6 の 5 権限フレームワークを、台帳の中に組み込んでください。
テンプレ DL:ドメイン・サーバ契約台帳(5 権限マトリクス込み)(本書のテンプレ集に収録予定)
10. やってはいけない 3 つのこと
10-1. 業者名義でドメインを取得してもらう
一言アドバイス ① と完全連動です。 H2-6-1 の「名義」を業者に渡してしまう行為です。 その瞬間に、ドメインを「人質」にされるリスクを抱えることになります。
10-2. 1 人だけのクレジットカードで自動更新を設定する
H2-6-2 の「契約者」が個人になる事故です。 その人が辞めた瞬間、カード期限切れの瞬間、ドメイン・サーバ・SSL のすべてが失効リスクにさらされます。 法人カードか法人口座振替を必ず使ってください。
10-3. 「サーバとドメインは同じものですか?」を業者の前で聞く
この質問をした瞬間、業者からの信頼を一瞬で失います。 どちらも基本中の基本の概念で、担当者が混同しているとなると、業者は「この人とは深い議論はできない」と判断します。 この記事を読んでから業者と話しに行ってください。 H2-1 の「街の例え」を頭に入れておけば、二度と混同しません。