ドメインとサーバーとは？契約・DNS・メールの管理を初心者向けに解説

ホームページの制作やリニューアルを相談すると、ドメイン、サーバー、DNS、SSLという言葉が出てきます。説明を聞いて分かったつもりでも、「どの契約を残すのか」「メールはそのまま使えるのか」「誰が更新するのか」を決める段階で迷うことがあります。大切なのは、用語を暗記することより、名前・配信先・設定・契約の関係を把握することです。

ドメインはインターネット上で使う名前、Webサーバーはページを届ける仕組み、DNSは名前に対応する情報を調べる仕組みです。同じドメインでホームページとメールを使っていても、契約先や管理者が同じとは限りません。HTTPSによる通信の保護も、契約の更新やサイトの保守とは別に確認する必要があります。

この記事では、JPRS、ICANN、MDNなどの一次資料を参照しながら、制作を依頼する側に必要な判断と管理の方法を整理します。Chromiumの公開された表示改善も紹介します。途中に登場する会社や相談文は理解のための架空例であり、Acquaが担当した案件や顧客の成果ではありません。

1． ドメイン・サーバー・DNSの違いを整理する

まず「名前」と「中身」を分けて考える

ドメインを登録することと、ホームページを公開することは別の作業です。名前を確保しただけでは、会社紹介や問い合わせページは表示されません。ページのデータを用意し、それを届けるサービスを設定し、名前から利用先を調べられる状態にして、初めて閲覧につながります。

反対に、制作途中のページが確認用URLで見えていても、自社のドメインで公開できる準備がすべて終わったとは限りません。「原稿とデザインが完成した」「配信先の準備ができた」「正式なURLで確認した」を分けて報告してもらうと、公開直前の認識違いを減らせます。

四つの役割を担当と結び付ける

最初の打ち合わせでは、次の表の右端を埋めてみてください。一社がまとめて担当していても、役割ごとの確認先を明らかにする意味があります。請求書に「ホームページ管理費」としか書かれていない場合は、その中に何が含まれるのかを確認します。

Webとメールは別々に動いていることがある

架空の設備会社が、ホームページは制作会社の用意した環境、社員メールは別の業務サービスで利用しているとします。この会社がサイトだけを作り直す場合、メールの契約まで移す必要があるとは限りません。先に現在の利用関係を調べることで、変更する範囲を小さくできます。

逆に、古いサーバーを「もうサイトには使わないから」と解約すると、そこに残るメールやデータも使えなくなる可能性があります。図解は役割を理解するための概念図であり、すべての契約構成や通信順序を表すものではありません。自社の構成は契約書と管理画面を照合して確認しましょう。

2． ドメインを選ぶ前に登録条件と管理方法を確認する

ドメイン名とURL全体を混同しない

たとえば説明用のURL「https://www.example.jp/service/」では、httpsが通信方式、www.example.jpがホスト名、/service/がページの場所を示すパスです。この例で登録する名前として考えるのはexample.jpです。「URLを変える」という相談でも、末尾のページ名だけを変えるのか、ドメインから変えるのかで影響が違います。

名刺、看板、メールアドレス、印刷物、取引先の登録情報に使う名前は、後からの変更に伴う作業を含めて判断します。短さだけでなく、口頭で伝えやすいか、会社名との関係が分かるか、似た文字の読み違いが起きないかを確認してください。候補の空き状況と、使用に関する確認も別の論点です。

すでに運用している名前があるなら、デザインの変更だけを理由に新しいドメインへ替える必要はありません。変える理由と、連絡先・印刷物・外部リンクの修正範囲を並べて検討します。会社名の変更などで別の名前を使う場合も、旧URLをいつまで維持するか、旧メールへの連絡をどう受けるかを別々に計画します。

「.jp」と「.co.jp」は登録対象が違う

JPRSの「種類と対象」では、汎用JPは日本国内に住所を持つ個人・団体・組織が登録でき、登録数に制限がないと説明されています。CO.JPは日本で登記した会社などが対象で、有限責任事業組合なども含まれます。単純に「法人ならすべてCO.JP」と覚えるのは適切ではありません。

属性型には組織の種類に応じた条件があり、原則として一組織一ドメインの扱いと例外があります。候補を決める際は最新の対象と詳細規則を確認します。登録資格があることと、会社のサービス品質が高いことは別です。末尾の種類だけで信頼性に星を付けたり、検索順位の優劣を決めたりはできません。

登録者・窓口・支払担当を一緒に決める

制作会社が申請を代行する場合も、登録者として誰の情報を使うのか、自社が継続利用するための手続きは何かを確認します。担当者の個人アドレスだけで契約を管理すると、退職や長期不在の際に連絡を追えなくなることがあります。社内で責任を持つ部署と代理担当を決めておきましょう。

JPドメインの申請は指定事業者を通じて行う仕組みです。JPRSの登録FAQも確認し、依頼先が提供するサービスと手続きを把握してください。見積もりでは初年度の登録費だけでなく、更新費、管理代行の範囲、窓口変更時の手続きまで書面に残すと、毎年の判断がしやすくなります。

3． サーバーは容量よりも運用条件から選ぶ

Webサーバーはページを届ける仕組み

MDNのWebサーバーの説明では、サーバーはハードウェアとソフトウェアの両面で説明されています。ブラウザーからの要求を受けて、文書などを返す役割です。ファイルを配信するだけの構成と、プログラムやデータベースを使ってページを作る構成では、管理するものも変わります。

発注側がすべての設定値を覚える必要はありません。ただし「サイトのファイルだけ保存しているのか」「データベースも必要なのか」「外部サービスが止まると使えない機能はどれか」は把握したい情報です。バックアップや引き継ぎの対象を判断する入口になります。

プラン名より必要な機能と担当範囲を比べる

共用サーバー、専用環境、クラウドなどの名前だけで適否は決まりません。会社案内を中心にするのか、会員機能や予約を持つのか、大きなファイルを配るのかによって条件が変わります。想定する利用、必要な機能、許容できる停止時間を制作側へ伝え、候補を絞ります。

比較表には容量だけでなく、バックアップの対象と保管期間、復元の申請方法と費用、問い合わせ窓口の時間、障害情報の案内、管理画面の権限を入れましょう。「バックアップあり」でも、誰がどの状態まで戻すのかが決まらなければ、復旧の準備ができたとはいえません。具体的な復元手順を確認することが大切です。

Web制作サービスに配信環境が含まれる場合は、別のレンタルサーバー契約が必要かどうかを先に確認します。自社で追加契約してから「この制作方法では使わない」と分かると、不要な費用が発生します。将来そのサービスを離れる場合に、文章、画像、データ、ドメインをどう引き継げるかも選定時の質問に含めてください。

安い初年度料金と継続費用を分ける

費用を比較するときは、契約期間、更新時の金額、税、追加機能、移行作業、保守作業を同じ条件に揃えます。月額表示だけを並べると、長期契約の割引や別料金の作業を見落とします。ここでは変動する料金を一律の相場として載せず、見積もり時点の公式条件を確認する方法を勧めます。

架空の比較例では、A案は環境の利用料だけ、B案は利用料に更新作業と月次確認を含むとします。この二案は総額だけでは比較できません。自社で担当する作業をA案に足し、B案の対象外作業も確認してから比べます。運用費は「場所を借りる費用」と「人が作業する費用」に分けると説明を受けやすくなります。

4． DNSを変える前にWebとメールへの影響を調べる

DNSは名前に対応する情報を調べる仕組み

JPRSのDNS用語解説を出発点にすると、DNSはドメイン名に関する情報を扱う仕組みと理解できます。Webの接続先だけを登録する場所ではありません。メールの配送先など、同じドメインを使う別のサービスに必要な情報も管理されます。

DNSの管理画面を開ける人が、ドメインを登録した人やWebを制作した人と同じとは限りません。請求先から推測せず、実際にどのサービスで情報を管理しているかを確認します。「ドメインを移す」という表現を使う場合も、登録の管理窓口を変えるのか、DNSの管理先を変えるのか、Webの配信先だけ変えるのかを具体化してください。

レコードごとの役割を見て変更対象を絞る

DNSに登録する情報はレコードと呼ばれ、種類ごとに役割が違います。次の表は相談のための整理です。ここに書かれた名前だけを見て、実際の値を変更する手順書としては使わないでください。サービス側の指示と現在の設定を照合し、技術担当者が変更対象を確定します。

特にメールについては、JPRSのMXレコード解説も参照できます。MXを残すだけでメールの全機能が保証されるわけではなく、送信に関係する設定や利用サービスの条件も確認が必要です。用途の分からない値を「古そうだから」と消すことは避け、設定した担当者と目的を調べます。

反映は一律の秒数で約束しない

DNSには、問い合わせで得た情報を一時的に保持するキャッシュがあります。JPRSのキャッシュ解説を踏まえると、変更した情報がすべての利用者に同時に見えると考えるのは適切ではありません。設定の種類や保持されている情報などにより、確認する場所で見え方が異なることがあります。

公開予定は「設定ボタンを押す時刻」と「必要な確認を終える時刻」を分けます。変更前の設定、変更内容、担当者、確認方法、問題時に戻す判断を記録してください。確認が取れる前に旧環境を解約すると、原因の切り分けや復元が難しくなります。具体的な移行の依頼範囲は制作会社変更時の引き継ぎガイドで整理できます。

架空の確認記録では、「社内回線では旧画面、携帯回線では新画面を確認。どちらのURLも記録し、DNS担当へ照会中」と書けます。この段階で表示の違いをキャッシュだけの問題と断定しないことも大切です。Web側の配信やブラウザーの保存情報など、別の要因がないかを担当者が調べ、確認済みの事実と原因の仮説を分けます。

5． HTTPSと証明書は保護する範囲を理解する

現在の通信保護はTLSを基本に説明する

管理画面では「SSL設定」「SSL証明書」という名称が使われることがありますが、現在のHTTPSの説明ではTLSを基本に考えます。MDNのTLS解説は、認証、通信の暗号化、改ざんなどに対する完全性の保護を整理しています。名称が残っていることと、古いSSL方式を使うことは同じではありません。

一方、HTTPSを設定しただけで、管理者のパスワード、サーバー内の保存データ、プログラムの不具合まで一括して守られるわけではありません。通信の保護、アカウント管理、更新、バックアップをそれぞれ担当する必要があります。見積もりで「セキュリティ対応」と書かれていたら、具体的な対象を尋ねましょう。

公開例：Chromeが鍵アイコンの見直しを発表した理由

Chromiumは2023年5月2日の公式記事で、鍵の表示がサイトそのものの信頼性を保証すると受け取られやすい問題を説明し、表示の変更を発表しました。これはブラウザー開発元が公表した設計の事例であり、Acquaの顧客事例ではありません。

この例から読み取れるのは、技術的に通信が保護されていることと、運営者や掲載内容を信用できることを分けて伝える必要性です。ここで過去の発表を取り上げるのは設計上の判断を学ぶためであり、現在のすべての端末で同じアイコンが表示されると説明するためではありません。確認手順は実際のブラウザーに合わせます。

証明書の設定後も対象と更新を確認する

証明書では、公開する名前が対象に含まれているか、有効な状態で提供されているか、自動更新が動く条件は何かを確認します。wwwの有無や別のサブドメインがある場合は、それぞれを確認対象にします。「無料」「自動」という言葉だけで、利用条件や作業担当の確認を省略しないことが大切です。

公開試験では実際のURLを開き、証明書の警告、画像などの読み込み、リンク先やフォームの動作を確認します。異常が出た際に閲覧者へ警告を無視して進むよう案内するのではなく、運用側が原因を確認します。更新通知を受ける人、エラーを調べる人、契約先へ連絡する人をあらかじめ決めておきます。

6． 新規公開は契約・設定・確認を順番に進める

契約前に現在の利用と完成条件を一覧にする

新規制作でも、すでに会社のメールや予約サービスにドメインを使っている場合があります。最初に現在の利用を確認し、変更しないものを決めます。Webサイトを作るために新しい名前が必要なのか、既存の名前を活用できるのかは、その後で判断します。

完成条件は「トップページが表示される」だけでは足りません。正式なURL、必要なページ、スマートフォン表示、問い合わせの受付と通知、担当者による管理、更新の連絡を並べます。契約と公開確認の担当を分ける場合は、誰が最後の公開判断をするかも指定してください。確認者の予定まで含めると公開日を調整しやすくなります。

依頼書では作業と契約を分けて書く

架空の依頼文なら、「既存メールは継続し、Webの公開先を新環境に変更したい。ドメイン登録の契約は現状を確認してから判断する。DNSの変更案、証明書の準備、切り替え後の確認項目を提示してほしい」と書けます。単に「サーバーを全部移してください」と伝えるより、見積もる範囲が明確になります。

依頼書には現状資料、希望する変更、触らない範囲、希望時期、確認担当、問題時の連絡経路を入れます。分からない箇所は推測で埋めず「未確認」としてください。調査が必要な範囲を先に見積もってもらえば、作業開始後に契約者が不明だと分かる事態にも備えやすくなります。

公開後は画面と業務の両方を確かめる

制作担当の端末で確認できた後は、会社側も普段使う端末と回線で確認します。表示された画面、確認したURL、時刻を記録し、メールや通知については送信と受信を区別します。試験用データを使い、試験してよい宛先と時間を事前に合意してから実施してください。

「送信完了画面が出た」という結果と、「受付担当が通知を受け取れた」という結果は別です。担当者が返事できる状態まで確認して、業務としての公開を判断します。メールの文面や返信経路の整理は問い合わせ自動返信メールのガイドも参照してください。確認結果は制作担当と社内担当の双方が見られる場所に残します。

7． 更新期限と担当交代に備えて運用する

自動更新でも通知先と支払方法を点検する

ICANNの更新・期限切れFAQは、有効期限の把握、連絡先と支払情報の更新、契約先の条件確認を案内しています。初回登録と更新の料金が異なることも説明されています。なお、ICANNのgTLDに関する制度の期限や回復条件を、そのままJPドメインへ当てはめてはいけません。

社内では、自動更新の設定だけでなく、その結果を誰が確認するかを決めます。カードの期限切れ、通知先の変更、請求書の承認待ちなど、契約を続けるための実務を点検してください。ドメイン、サーバー、メールが別契約なら、更新月も別々です。一つの請求が済んだことですべて完了とは判断しません。

担当交代はログインできるうちに進める

架空の引き継ぎ例として、総務担当が交代する際に契約一覧を渡しても、二要素認証が前任者の端末にしか届かなければ、新担当は操作できません。契約名義、連絡先、権限、認証方法、緊急時の復旧手続きを、サービスの正式な手順で移します。共通パスワードを大勢へ送る方法で解決しないようにします。

新担当が必要な画面を確認でき、通知が届くことを確かめてから、旧担当の権限を見直します。外部の制作会社が管理する場合も、契約終了時に受け取る情報と変更の方法を決めておきましょう。通常の更新と点検の進め方はWordPress保守チェックリストに整理しています。

見えない・届かないときは症状を分けて記録する

障害の相談では「サーバーが壊れた」と原因を先に決めず、どのURLで何が起きたか、いつからか、誰の端末で再現するかを伝えます。Web全体が見えないのか、一ページだけなのか、メールの送信と受信のどちらに問題があるのかで、調べる入口が変わります。

直前の変更、警告文、契約の状態、公式の障害案内を確認し、担当者へ共有します。原因が不明なままDNS、証明書、プログラムを同時に変えると、何が効いたのか分からなくなります。まず現状を記録し、調査する担当と次の連絡時刻を決めることが、復旧作業と社内説明の両方に役立ちます。

メール自体に異常があると、そのメールだけを使った連絡は届かない可能性があります。緊急時に使う電話や別の連絡手段を、平常時に契約先と合意しておきます。復旧後も「直った」で閉じず、実施した変更、確認した範囲、再発防止として残る作業を受け取れば、次の担当者も同じ情報から判断できます。

8． 管理表と相談メモを作り、任せられる状態にする

管理表には秘密の値ではなく確認先を残す

管理表の目的は、誰が何を確認できるかを分かるようにすることです。パスワード、認証コード、秘密鍵、カード番号を一般の共有表に書く必要はありません。アクセスを制限した保管方法を別に用意し、管理表にはその管理担当と正式な確認方法を記録します。

相談時は「分かること」と「調べてほしいこと」を分ける

説明用の相談メモなら、「会社サイトと社員メールで同じドメインを利用中。請求書は二社分ある。サイトを更新したいが、DNSの管理先は未確認。現在の構成調査と、メールを維持した変更範囲の提案を希望」と書けます。最初から技術的な結論を用意する必要はありません。

契約書や管理画面を共有する際は、必要な箇所を担当者と相談し、認証情報や第三者の個人情報を不用意に添付しないようにします。調査後には、構成図、変更する項目、費用の前提、確認手順、継続管理の担当を受け取りましょう。説明を聞くだけで終えず、自社で保管できる形にすることが次の判断につながります。

仕組みを理解したら、最初に一つの契約を確かめる

最初からすべての用語に詳しくなる必要はありません。まず自社のドメイン名、更新の契約先、次の期限、連絡を受ける担当を確認してください。その次に、Webとメールの利用先、DNSを変更できる担当を調べます。不明な項目が見つかれば、それ自体が相談する内容になります。

仕組みの理解は、制作会社へ仕事を任せるための土台です。契約の継続、変更の判断、公開後の確認を社内と制作側で分担できれば、担当者が替わっても情報を引き継げます。名前を登録して公開するところで終えず、次の更新と変更まで見通した管理表を作ることから始めましょう。