ドメインとサーバの基礎 — 「自社で持つもの」と「業者に委ねていいもの」

この記事では、苦手に感じる人の多い、ドメインとサーバ、そして DNS について説明します。 Web担当者の場合、すでに会社がドメインもサーバも取得済みであることが多いですが、オウンドメディアやサテライトサイト、EC サイトなど、別サイトを新たに立ち上げる際には必要な知識です。 これらを正しく理解しているかどうかで、ベンダーと話すときの会話の深さが変わります。 Web担当者の場合は、技術の細部にまで踏み込む必要はありませんが、最低限の概念の考え方だけを押さえておきましょう。

1. インターネットを「街」に例えて理解する

Web の仕組みは、街と郵便配達の関係に置き換えるとわかりやすくなります。

1-1. ドメイン=住所

「example.com」のような部分が、ドメインです。 ブラウザに表示される URL(例:https://www.example.com/about/)のうち、サイト全体の「住所」にあたる中心部分がドメインで、その後ろの「/about/」などはページの場所を示します。 覚えやすい名前で、訪問者が自社のサイトに辿り着くための入口の表札になります。

1-2. サーバ=建物、Webサイト=部屋、IP アドレス=土地の緯度・経度

一方、サイトの実体(HTML や画像、プログラム)が置かれているのが「サーバ」です。 これは、街の中の 建物 で、その中に「Webサイト」としての部屋が存在します。 そして、その建物が建っている 土地の場所(緯度と経度) にあたるのが「IP アドレス」です。 住所(ドメイン)は、あくまで割り当てられた名前に過ぎません。 正確な場所を示す土地の緯度・経度(IP アドレス)がなければただの名前ですし、建物(サーバ)が無ければ土地はただの更地になってしまい、建物がなければ部屋も存在しえない、ということです。

1-3. DNS=住所と土地を結ぶ住民票、DNSサーバ=住民票を発行する役所

住所(ドメイン)と土地(IP アドレス)があったとしても、そのままでは土地と住所が紐づけられていない状態です。 その紐づけをするのが「DNS(Domain Name System)」と呼ばれるものです。 DNS は、いわば 役所の住民票 のような仕組みで、「この住所は、この土地のことです」と証明してくれます。 詳しくはまた 「8. DNS」 で扱いますが、Web の世界ではとても重要なものです。

1-4. Webサイトを閲覧する = 部屋を訪問する

ここまでに、ドメイン、サーバ、DNS をご説明しました。では、実際に Webサイトを訪れる際にはどのようなことが起きているのかを、これまでの例えに合わせてご説明します。

Webサイトを閲覧しているユーザーは、URL(住所)から、目的の Webサイト(部屋)があるサーバ(建物)へ訪問しようとします。 そのためには、面倒ではありますが、まず役所(DNSサーバ)に、その住所の IP アドレス(緯度と経度)を確認するために、住民票(DNS)を見せてもらいに行きます。 DNS から IP アドレスを確認できて、初めてサーバにたどり着くことができ、サーバ内の目的の Webサイトに入ることができるのです。 このドメイン → DNS → サーバという一連の流れが、実際の閲覧者には意識されることなく、一瞬で処理されています。

このドメイン(住所)・サーバ(建物)・DNS(住民票)は、その 3 つすべてを同じ契約者(所有者)にしなければいけないわけではなく、状況によって、それぞれ契約者が異なる場合もあります。 ただし、この「誰が契約するか」というポイントを何も知らずに適当に進めてしまうと、後にトラブルが発生しやすくなります。 本記事で、その点を説明していきます。

2. ドメインの基本知識

2-1. ドメインの構造

「blog.example.co.jp」のようなドメインは、右から順に「トップレベルドメイン」「セカンドレベルドメイン」「サブドメイン」でできています。 一番右の トップレベルドメイン(TLD) は「.com」「.jp」「.co.jp」などで、その分野や国が表されています。 TLD の左にあるのが セカンドレベルドメイン(SLD) で、本例では「example」の部分が対象です。この部分は、TLD とセットで使用者がいなければ、任意で命名することができます。 一番左が サブドメイン です。同じドメインの中でテーマを切り分けるときなどに使用されます(例えば、本体と切り離した「blog」など)。 TLD と SLD を合わせて「ドメイン」と呼びます。 ドメインはレジストラで契約することができます。レジストラについては、後でまた説明します。

2-2. TLD の種類と違い、選び方

TLD は何を選ぶかで、取得条件・費用・社会的信頼性が変わります。代表的なものをいくつかご紹介します。

• .com
  世界共通で取得制限がなく、価格も安め。最も普及しており、業種・国を問わず無難な選択肢です。
• .net / .org
  もともとは .net がネットワーク系、.org が非営利団体向けでしたが、現在は誰でも取得できます。.com が取れないときの代替や、団体・コミュニティでよく使われます。
• .jp
  日本に住所がある個人・法人が取得でき、価格は中程度。「日本のサイト」であることが伝わります。
• .co.jp
  日本に登記された会社(株式会社・合同会社など)が対象で、原則 1 社につき 1 つだけ 取得できる特別な TLD です。登記情報の確認を経て発行されるため価格は高めですが、その分「実在する日本の法人である」という強い信頼性のサインになります。
• 用途・地域に特化した TLD
  お店の「.shop」、東京の「.tokyo」、病院の「.clinic」など、用途や地域を表す新しい TLD も多数あり、サービスと性格が合えば、覚えやすさや、サイトのテーマのわかりやすさに役立ちます。

選び方の目安としては、法人のコーポレートサイトなら、信頼性の高い「.co.jp」がおすすめです。 ただし「.co.jp」を取得するには条件があり、1 社 1 つのみで、日本の企業であることを証明するために登記情報を提示する必要があります。そのため、1 社が brand-name.co.jp と corporate-name.co.jp の 2 つを取得する、ということはできません。 さらに、他の TLD と比べると割高です。その分、条件があるからこそ信頼されるドメインで、「.co.jp」であるだけで「怪しいサイトではない」という証明にもなりやすいです。 法人ではなかったり、ドメインにコストを割けなかったりする場合は、「.com」「.jp」あたりが利用されやすい TLD です。他にも用途に合わせた TLD でも良いかと思いますが、企業という規模でドメインを取得するのであれば、「.co.jp」は取得しておくべきかと思います。

2-3. 取得・管理する場所(レジストラ)

すでに軽く触れていますが、ドメインを取得・管理するサービス事業者を レジストラ と呼びます。 国内では「お名前.com」「Value-Domain」「ムームードメイン」「さくらインターネット」などがあり、ドメインの販売の認定を受けた公認の代理店です。 どのレジストラを使うかは、管理画面の使いやすさ・サポート体制・料金などで選ぶと良いです。 レジストラの乗り換え(移管)も可能ではありますが、手続きがかなり煩雑なので、レジストラは変更しない前提で選ぶようにしましょう。

2-4. ドメインの更新と失効リスク

ドメインは 1 年単位での更新契約 が基本です。 年に 1 度の更新を忘れると、最悪の場合ドメインを失います。 レジストラの自動更新を有効にしたり、レジストラの契約時の登録メールアドレスを複数人で受信できる状態にしておくべきです。 契約時の支払い方法も、個人のクレジットカードでの自動更新は事故の元なので、必ず法人のクレジットカードか法人口座からの引き落としなどを利用するようにしましょう。

3. ドメインは「自社で取得する」が原則

「ドメインと言われても、どうやって契約すればいいのか分からない」ということで制作ベンダーなどに任せてしまうと、後々大きなトラブルの火種になりやすいため、ドメインは 自社で管理することを原則 としましょう。

3-1. なぜ自社管理が必要か

もし、ドメインの更新ができていなかったりした場合、起きることはサイトが見られなくなるだけではありません。 せっかく築き上げてきた SEO の評価もゼロからのやり直しになります。 さらには、ドメインに紐づいたメールアドレスもすべて停止してしまうので、名刺・案内・既存資料に書かれた連絡先がすべて無効になります。 一瞬で会社のインターネット連絡経路が消えてしまうのです。 しかも一度失ったドメインは、第三者に奪われると二度と戻ってきません。場合によっては第三者に悪用されてしまうこともあります。

そんな重要なドメインの管理をベンダーに委ねてしまうことが、大きなリスクであるというのがまず 1 つ。 もし、任せたベンダーが急に倒産してしまったら…。想像してみてください。

ベンダーからドメイン契約を移行させればいいと思うかもしれませんが、ここが結構面倒なのです。 そもそも、ドメインという重要な契約を他の会社に譲渡するという手続きが、それなりに面倒です。

さらに、ベンダーからドメイン契約を移行させるタイミングというのは、そのベンダーとの契約を打ち切るようなタイミングなので、ベンダーとの関係も良好でないことが多く、

• 譲渡手続き自体になかなか応じてもらえない
• 譲渡手続きに高額な費用を請求される
• 勝手に契約を破棄される

といったことも起こりかねません。これは言ってみれば、ドメインの管理を外部に任せっきりにしたツケです。 そんなことにならないように、ドメインは自社で管理するようにしましょう。

3-2. すでに業者名義の場合

もちろん、すべてのケースでドメインを自社で管理すべきというわけでもありません。 何らかの事情で、ドメインを外部業者が管理することもあり得ます。 例えば、一時的なキャンペーン実施のためにドメインを取得するような場合は、期間も限定されているので、制作ベンダーや広告代理店などがサーバと合わせてドメインも用意しておいてくれることもあります。 短期間でしか利用しないのに、わざわざ社内での承認などを取るのが手間な場合などには、このような方法を取ることもあります。 また、メールアドレスの紐づけやコーポレートサイトのドメインは自社で管理して、他のサービスサイトなどのドメインは影響範囲も限定的であるため、制作ベンダーなどが代理で契約するようなこともあります。

上述したリスクを踏まえた上で、ケースバイケースで最適な選択ができれば良いですが、自社で管理できるのであれば、自社で管理するのが安全です。

3-3. ドメインを移行(譲渡)する場合

結果的にドメインを移行させたい場合は、契約している制作ベンダーなどから、ドメインを譲渡してもらう手続きが必要です。 手続き方法などはレジストラによって異なるので、レジストラに問い合わせるのが手っ取り早いです。 先述していますが、ドメインの譲渡は面倒です。ドメインの譲渡に対して手数料を求められること自体は、不当だとは言えません。 とはいえ、数十万円を請求されるようであれば、どういう計算でこの金額になっているのかを確認する方が良いかと思います。 まるで「ドメインを売る」ようなことを言う場合は筋違いなので、弁護士に相談することをお勧めします。

4. サーバの種類と選択肢

サーバを用意する際には、大きく分けて 3 つの選択肢があります。 それぞれにメリット・デメリットがあるので、自社の Webサイトに合わせて選ぶことになります。

4-1. レンタルサーバ

レンタルサーバは、サーバ事業者が管理しているサーバの一部を、月額料金で間借りして使うサービスです。 機器の保守やセキュリティ対策などは事業者側が行ってくれるので、利用者はサーバの管理を意識することなく、Webサイトを置くことに集中できます。 レンタルサーバは、エックスサーバー、さくらのレンタルサーバ、ロリポップ、heteml などが有名どころで、1 ヵ月数百円〜数千円という安価で気軽に借りられ、サーバの設定もとても簡単に行えるため、中小企業などで多く利用されています。 例えるなら、ビルの一画を貸してくれて、ビルや共用部の管理・修繕は管理会社がやってくれる「賃貸オフィス」のようなものです。

• メリット：安価で、契約・設定が簡単。管理画面が整っていて、専門知識が少なくても運用できる。
• デメリット：使える機能がプランの範囲に限られ、急なアクセス増や特殊な構成には対応しにくい。

4-2. クラウド(AWS / GCP / Azure)

クラウドサーバとは、クラウド事業者が持つ大量の物理サーバ資源を仮想的に切り分けて、利用者が必要な分だけ借りて使える仕組みです。 クラウドサーバも、結果的にはレンタルサーバのように「借りる」ことには変わりないのですが、一画を固定して借りるのではなく、必要な分だけ拡大・縮小されるというのが大きな違いです。 オフィスよりも、電気にたとえるとわかりやすいかもしれません。夏場や冬場はエアコンの使用で電力の消費量が上がりますが、消費が増えたからといって急に電気が足りなくなることはありません。クラウドサーバも同じで、キャンペーンや広告でアクセスするユーザーが急増しても、その都度、臨機応変に対応できる環境を整えてくれます。ただし電気代と同様に、使った分だけ費用も発生します。 クラウドサーバは AWS / GCP / Azure などが有名で、大手企業や中規模〜大規模の EC・SaaS・大規模メディア、大型キャンペーンなど、トラフィック(ユーザーのアクセス)の変動が大きい案件で利用されることが多いです。

• メリット：アクセスの増減に合わせて柔軟にスケール(拡張・縮小)でき、大規模・特殊な構成にも対応できます。
• デメリット：設計・運用に専門知識が必要で、使い方次第では費用が膨らみやすくなります。

4-3. 自社サーバ

自社サーバ(オンプレミス)は、自社内やデータセンターにサーバ機器を自社で設置し、自社で管理・運用する構成です。 機器の購入から保守、障害対応まで、すべてを自社で抱えることになります。 サーバの構成を自由に組み替えられるため、トラフィックの大きい案件などでも利用されてきましたが、そうした用途も昨今ではクラウドのほうが主流のため、現在はセキュリティ要件が極めて高い案件(金融など)以外では、なかなか選ぶ機会がなくなってきました。 他と同様に、わかりやすく例えるなら、レンタルサーバが賃貸オフィスであれば、自社サーバは自社ビルです。ビルが老朽化してもトラブルがあっても自社で解決する必要がありますが、その分、自社のセキュリティでしっかり守ることもできます。

• メリット：構成やセキュリティを自社で完全にコントロールできます。
• デメリット：機器・保守・運用要員のコストと手間が大きく、障害対応もすべて自社で抱えることになります。

5. サーバの選定基準

サーバ選びをする際には、上述のサーバの種類に加えて、サーバの契約プランに含まれる仕様や対応内容、サーバの構成内容を踏まえた上で判断する必要があります。 本セクションでは、簡単ではありますが、サーバの選定基準になり得る項目をご紹介します。

5-1. 判断軸 1：サイトタイプ

コーポレート、サービス、LP、オウンドメディア、EC、Webサービスのどれか。 タイプによって必要な機能が大きく変わります。 EC なら決済対応・在庫連動・SSL の要件が高くなり、オウンドメディアなら表示速度の優先度が上がります。

5-2. 判断軸 2：規模

月間 PV、画像や動画の容量、同時アクセス想定数 — このあたりです。 小規模なら標準層で十分。 アクセスが急増する見込みがあるなら、最初から余裕を持ったプランか、クラウド型を検討します。

5-3. 判断軸 3：必要機能

PHP・Node.js などの対応言語、CMS(WordPress 等)の対応、SSL 対応、メール機能、ステージング環境、WAF(Web Application Firewall)などです。 「あとから増やせる機能」と「最初に決めておく機能」を分けて考えると、選定が楽になります。

5-4. 判断軸 4：予算

月数百円〜数万円までレンジが広いのがサーバの特徴です。 レンタルサーバは、料金帯でおおよそ次の 3 段に分けて考えるとイメージしやすくなります。

• 安価層(月数百円)：容量・転送量・サポートは最小限。個人ブログや、ページ数の少ない小規模なコーポレートサイト・お知らせサイト向け。
• 標準層(月千円〜数千円)：容量・転送量に余裕があり、表示速度・サポートも実用十分。中小企業のコーポレート・サービスサイトの定番で、ほとんどの案件はここで足ります。
• 高速層(月数千円〜)：高速ストレージや大きな転送量で表示速度を重視する、メディア系や複数サブドメイン運用に向きます。

なおクラウドは、この料金帯とは別軸です。使った分だけ支払う従量課金で、アクセスの増減に応じて費用も上下します(「4. サーバの種類と選択肢」 参照)。EC・SaaS・大規模メディアなど、規模やトラフィックの変動が大きい案件で検討します。

「安ければ良い」でも「高ければ安全」でもなく、自社サイトの規模・目的に対して適正なコスト を見極めます。 Lesson 3-3 で詳しく扱いますが、激安は「中間マージン無し=管理工程の省略」を意味するケースが多い、と覚えておいてください。

5-5. 判断軸 5：トラブル時の対応

サポートの言語(日本語・英語)、連絡手段(電話・メール・チャット)、障害時の SLA(対応時間)、自社の業務時間との整合性。 夜間・休日にサポートがつながらないサーバを選ぶと、その時間帯の障害で何時間も止まる、というのは現場あるあるです。

5-6. どこまで自分で判断するか(判断 3 レイヤー)

ここまでの判断軸は、担当者が判断の物差しを持つ ためのものであって、すべてを担当者ひとりで決める、という意味ではありません。 案件の難易度に応じて、自分で決めてよい範囲を 3 つのレイヤーに分けて考えます(Lesson 1-1「4. Web担当者の関わり方」 の判断 3 レイヤー)。

• レイヤー 1：担当者だけで決めてよい — 小規模コーポレート・LP・お知らせ・社内向けなど、規模が小さく一般公開のみの案件。判断軸に沿って、主要なレンタルサーバから選んで構いません。
• レイヤー 2：専門家と相談して決める — 中規模オウンドメディア、複数サブドメイン、SEO 重視、画像・動画が多い案件。制作会社・運用業者と判断軸を共有して最終決定します。
• レイヤー 3：専門家に委ねる — EC・会員制・個人情報・決済・メール大量配信が絡む案件は難易度が高く、ひとりで決めるのは危険です。制作会社・SI・社内情シス・顧問専門家と一緒に決め、担当者は「自社の要件を整理する」「質問を用意する」「決まった内容を運用に反映する」役に徹します。

自社の案件がどのレイヤーかを、サーバを決める前に必ず確認してください。 担当者が主体で選べるのはレイヤー 1〜2 まで。レイヤー 3 は専門家主導の別フローに乗せます(Lesson 2-1「7. 企画段階の前提条件」、Lesson 3-5「5. その他の契約必須事項」 と接続)。

6. サーバを「ベンダーに委ねる」

6-1. サーバの外注はドメインほどのリスクがないことも

「3. ドメインは自社で取得する」 では「ドメインは自社管理が原則」と書きましたが、サーバの場合は、条件によっては「外注して構わない」です。 最初に説明したとおり、ドメインは住所で、サーバは建物のようなものです。 一度世に知らせた住所はそうそう替えが効きませんが、建物は引っ越せばよいので替えが効きます。 そのため、ドメインに比べればサーバはリスクが少ないと言えるのです。

6-2. サーバを外注する条件

現状、会社にサーバがない場合は、基本的には自社でサーバを用意するようにしましょう。 なぜかというと、Web のためだけのサーバであればまだ良いのですが、サーバはメールの送受信にも利用されます。 ドメインと同様に、何らかの要因で停止してしまうと、メールが使えなくなったり、メールの仕様によっては、これまでやりとりしたメールも消えてしまうことがあります。

メールにもサーバが必要なので、そうしたサーバを用意するのは、基本的には会社設立時です。 もし可能であれば、情報システムを担当する人員を配置するか、その役割の一時的な責任者を決めて、上述のサーバ選定基準と照らし合わせて契約することをお勧めします。

サーバを外注してよいのは、Web 用のサーバをメール用のサーバと切り離して用意する場合や、ブランド用・キャンペーン用など、既存サーバとは別に追加で用意するような場合です。

6-3. 業者にサーバを任せる場合の注意事項

サーバを業者に委ねる場合、契約内容に最低でも以下を盛り込むようにしてください。

• 定期バックアップの取得と保管(頻度・保管期間・保管場所)
• 障害時の連絡 SLA(連絡時間・対応開始までの目安)
• サーバ内データの所有権
• 契約終了時のデータ返却手順(全データを引き取れる状態)

詳細は Lesson 3-5 で扱いますが、契約段階でここを詰めておかないと、後で動けなくなります。

6-4. Web担当者はそこまで専門性に長けていなくて良い

Web担当者の中には「サーバのことが分かっていないといけない」と思いがちですが、そんなことはありません。 Lesson 1-1 でも書いたとおり、Web担当者の責任は 「すべてを自分で触ること」ではなく「適切な管理体制を作ること」 です。 サーバの技術は専門家に任せ、自分は「業者と適切に対話できる」状態を作ることです。 他者の力を上手に活用するのが、本書を通じて目指す Web担当者像です。

7. ドメイン・サーバの権限管理

契約に関しては、ドメインは自社、サーバは自社または業者としました。ただし、これは契約のお話であって、実際はドメインやサーバを誰がどのような権限を持って操作するのかを、自社内または業者を含めて、もう少し役割を分けて運用していくことになります。ここでは、契約を含めて、ドメイン・サーバに必要な役割を説明します。

7-1. ドメインの権限管理

名義(=登録上のオーナー)

契約者との違いがわかりづらいかもしれませんが、契約者は「担当者」など社内スタッフになる可能性があるのに対し、名義は原則として 自社(法人または代表者個人) が持ちます。 ここをスタッフの名義にしてしまうと、退職などの兼ね合いで名義変更が必要になり厄介です。最初から自社名義で取るのが鉄則となります。

契約者(=決済の主体)

これは前述したとおりで、自社の担当者や責任者が対象となります。 担当者が契約する場合でも、支払い方法は担当個人ではなく、会社のクレジットカードや法人口座振替などで支払うことが鉄則です。 契約者は支払いを管理し、更新が滞らないようにする役目があります。

管理者(=設定変更ができる権限者)

レジストラ管理や DNS 管理のログイン権限を持ちます。ドメインを設定したり変更したりする場合は、この管理者が対応します。 一般的には社内のシステム担当者などが対応しますが、そのような人材がいない場合は、外部に管理者権限を渡して対応してもらうことになります。

7-2. サーバの権限管理

名義(=登録上のオーナー)

中身はドメインと同じですが、サーバの場合は、外部業者にお願いするとオーナーも外部業者になります。

契約者(=決済の主体)

契約者についてもドメインと同様です。 外部業者に委託する場合は、外部業者から月々または年間でサーバ費用の請求が発生します。当然ながら、手数料が発生するのは大前提です。 ほかにも、サーバの緊急対応をどの程度求めるのかによって費用は変わりますが、詳細はまた後述します。

管理者(=設定変更や作業権限を管理)

設定変更し得るすべてのサーバ管理画面へのログイン権限を持ちます。実際にサーバを運用する担当者のアカウントを発行し、作業者を管理します。 管理者の権限で運用作業をすることも可能ですが、管理者 1 名に対して作業者を複数名にすることで、管理者不在による対応不能を回避できます。そのため、管理者だけでサーバを運用するケースは少ないと言えます。

運用担当者(=日常の手作業)

実際にサーバを管理する役割です。サーバの設定でデータベースを用意したり、ベーシック認証やプログラムのバージョン管理などを行います。 また、契約内容によっては、負荷分散の調整なども行います。

7-3. 緊急時対応(=障害・乗っ取り・失効時の動き)

基本的には、管理者と運用担当者で行う場合が多いです。 外部業者に任せていたとしても、このようなトラブル時には最終判断を自社で行う必要があり、外部業者との連絡フロー、対応時間、エスカレーション先を契約段階で決めておく必要があります。

7-4. Web担当者の権限

ここまでドメインとサーバの権限を説明してきましたが、Web担当者自身が担当する可能性があるとすれば「契約者」と「管理者」あたりになります。とはいえ「管理者」は、権限自体は持っていても、実際に管理画面を触るケースはかなり少ないと考えてよいかもしれません。

8. DNS — 見えないけど一番大事な仕組み

8-1. DNS の役割

「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(契約書のどこに書かれているか)

退職時・引き継ぎ時に、この台帳があるかどうかで、後任者の動き出しが何倍も変わります。 「7. ドメイン・サーバの権限管理」 の 5 権限フレームワークを、台帳の中に組み込んでください。

10. うっかりやりがちな 3 つの落とし穴

10-1. 業者名義でドメインを取得してもらう

「3. ドメインは自社で取得する」 の一言アドバイス(業者名義の警告)と完全連動です。 「7. ドメイン・サーバの権限管理」 の「名義」を業者に渡してしまう行為です。 その瞬間に、ドメインを「人質」にされるリスクを抱えることになります。

10-2. 1 人だけのクレジットカードで自動更新を設定する

「7. ドメイン・サーバの権限管理」 の「契約者」が個人になる事故です。 その人が辞めた瞬間、カード期限切れの瞬間、ドメイン・サーバ・SSL のすべてが失効リスクにさらされます。 法人カードか法人口座振替を必ず使ってください。

10-3. サーバとドメインを混同したまま業者と話してしまう

サーバとドメインは、どちらも基本となる概念です。 この 2 つを区別できているだけで、業者との会話がぐっと噛み合うようになります。 逆に混同したままだと、せっかくの打ち合わせがすれ違いがちです。 この記事の 「1. インターネットを街に例えて理解する」「街の例え」を頭に入れておけば、もう混同することはありません。 安心して業者と話しに行きましょう。

ドメインとサーバ、そして DNS の関係がイメージできれば、第1章の土台は十分です。 細かい用語や設定は、必要になったときにこの記事へ戻ってくれば大丈夫。 全部を一度に覚えようとしなくて構いません。 肩の力を抜いて、次の Lesson へ進んでいきましょう。