01-04_サーバー
出典: 制作部署マニュアル サーバー（自動ミラー・正本は /Users/oogushiyuuki/manual-terasu）
まずここだけ：この章のゴール
「サーバー」「ホスティング」「ドメイン」「DNS」「SSL」── 制作をやっているとよく出てくるけど、一度もちゃんと理解したことがない人向けの章。専門知識ゼロから、この章一本で「HPが世界に公開される仕組み」が全部分かるように、日常の例えだけで説明していく。
結論を先に言うと、TERASUの作り方は「速くて・安全で・落ちにくくて・しかも安い」。WordPressより劣るどころか、より洗練された配信方法を使っている。その理由がこの章を読むと腹落ちする。
覚えるべきキーワードは5つだけ。
| 言葉 | ひとことで言うと | 例え |
|---|---|---|
| サーバー | HPのデータを置いておくコンピュータ | HPを置く「土地・建物」 |
| ホスティング | そのサーバーを貸し出すサービス | 土地・建物を借りる「不動産屋」 |
| ドメイン | サイトの住所（例: terasu.scale-group.co.jp） | 「〇〇県〇〇市〇〇町1-2-3」 |
| DNS | 住所から本当の場所を引く電話帳 | 「住所 → 地図上の座標」変換係 |
| SSL | 通信を暗号化する鍵（鍵マーク・https） | 中身が見えない「封筒・宅配ボックス」 |
→ この5つの関係が分かれば、サーバー周りは8割理解したのと同じ。順番に潰していく。
サーバーとは / ホスティングとは
サーバー ＝ 「HPを置いておく土地・建物」
私たちが作るHPは、結局のところ HTML・CSS・画像といったファイルの集まり。このファイルを自分のパソコンの中に置いているだけだと、見られるのは自分だけ。世界中の人に見てもらうには、24時間365日ずっと電源が入っていて、誰からアクセスが来ても応答できるコンピュータにファイルを置く必要がある。
その「ずっと起きていて、頼まれたらHPを渡してくれるコンピュータ」がサーバー。
イメージは「24時間営業の店舗」。お客さん（＝見に来た人）が来たら、いつでもシャッターが開いていて、商品（＝HP）を渡してくれる。深夜だろうと正月だろうと閉まらない。これがサーバー。
| 自分のPC | サーバー |
|---|---|
| 電源を切ったら見られない | 24時間ずっと起きている |
| 自分しかアクセスできない | 世界中からアクセスできる |
| 1人来ても固まることがある | 同時に大勢来ても捌ける |
ホスティング ＝ 「サーバーを貸してくれるサービス」
「じゃあサーバーを自分で買って、24時間動かすの？」── 普通はやらない。電気代もかかるし、故障対応も大変。だからサーバーを貸してくれる業者を使う。これがホスティング（＝レンタルサーバー）。
例えるなら「店舗の土地・建物を貸してくれる不動産屋」。自分で土地を買って建物を建てなくても、月いくらで借りれば、すぐ営業を始められる。
つまり整理すると：
- サーバー ＝ HPを置く「箱（コンピュータ）」
- ホスティング ＝ その箱を貸し出す「サービス」
→ TERASUはこのホスティングに Cloudflare Pages（クラウドフレア・ページズ） を使っている。これは後で詳しく説明する。
HPが見られる仕組み（ブラウザとサーバーの会話）
「HPを見る」とき、裏で何が起きているか。これはやり取りの順番で理解すると一気に分かる。
| 順 | 誰が | 何をする |
|---|---|---|
| あなた | ブラウザ（Chrome等）に terasu.scale-group.co.jp と打つ |
|
| ブラウザ | 「このHP（のファイル）ちょうだい」とサーバーにお願いしに行く | |
| サーバー | 「はいどうぞ」とHTML・CSS・画像を返す | |
| ブラウザ | 受け取ったファイルを組み立てて画面に表示する |
つまりブラウザは「注文する人」、サーバーは「商品を渡す店」。あなたがURLを打つ＝注文票を出す、サーバーがファイルを返す＝商品を渡す。この往復が、世界中で1秒間に何億回も起きている。
→ ポイントは 「ブラウザが取りに行って、サーバーが渡す」 という一方通行の関係。HPはサーバーに「置いてあるだけ」で、見たい人が自分で取りに来る、という形を覚えておけばいい。
静的サイト vs 動的サイト（TERASUは静的）
ここはTERASUの強みの核心。サイトには2種類の作り方がある。
静的（せいてき）サイト ＝ 「完成品を棚に並べておく」
あらかじめ完成させたHTMLを、そのまま置いておく方式。誰かが見に来たら、できあがっているファイルをそのまま渡すだけ。
例えるなら「お弁当屋さんで、作り置きのお弁当を棚から取って渡す」。注文が来た瞬間にはもう完成しているから、出すのが速い。レジで「はいどうぞ」と渡すだけ。
TERASUのHPはこの静的サイト。 HTML・CSS・JavaScriptを作って、完成したものをCloudflareに置いておく。
動的（どうてき）サイト ＝ 「注文が来てから毎回作る」
アクセスが来るたびに、サーバーがその場でページを組み立てる方式。WordPress（ワードプレス）が代表例。データベースから記事を引っ張ってきて、毎回HTMLを生成してから渡す。
こちらは「注文が入ってから厨房で一から作る定食屋」。できたては良いが、毎回調理する分だけ提供は遅くなるし、厨房（サーバー）が忙しいと待たされる。コンロ（データベース）が壊れたら何も出せない。
どっちが優れている？ → 用途次第。HPなら静的が強い
「動的（WordPress）の方が高機能では？」と思うかもしれないが、HP（コーポレートサイト・LP）を作るなら静的の方が明確に有利。劣っているのではなく、目的に対してより洗練された作り。
| 観点 | 静的（TERASU） | 動的（WordPress等） |
|---|---|---|
| 表示速度 | 速い（完成品を渡すだけ） | 毎回組み立てる分だけ遅い |
| 安全性 | 高い（その場で動く処理がない＝攻撃の入口が少ない） | データベース・管理画面が狙われやすい |
| 落ちにくさ | 落ちにくい（複雑な仕組みがない） | DBやサーバー処理が止まると表示不能 |
| コスト | 安い（無料枠で運用可能） | サーバー・DB維持に費用がかかる |
| 更新のしやすさ | ファイルを差し替えて再公開 | 管理画面からポチポチ更新できる |
WordPressが「劣っている」のではなく、ブログを毎日大量更新する人には便利。でもTERASUが作るような「会社の顔・サービス紹介・LP」は、内容がコロコロ変わらない。だから毎回作り直す必要がない＝静的で十分、むしろ速くて安全で安い。これは技術的な"格上げ"であって妥協ではない。
→ お客さんに説明するときも「WordPressより速くて安全で、落ちにくい最新の作り方です」とポジティブに伝えてOK。実際そうだから。
TERASUのホスティング ＝ Cloudflare Pages
TERASUのHPを置いている場所が Cloudflare Pages。「クラウドフレアが提供する、HP専用の置き場サービス」と思えばいい。
Cloudflareって何者？
Cloudflare（クラウドフレア）は、世界中にサーバーを持っている巨大なインフラ会社。世界のWebサイトのかなりの割合がここを通っている。その中の Pages が、静的サイトを置いて公開するためのサービス。
なぜ TERASU は Cloudflare Pages を使うのか
| 理由 | 中身 |
|---|---|
| ** 高速** | 世界中のサーバーから配信（後述のCDN）。日本からでも一瞬で表示される |
| 無料枠が強い | 個人〜中小規模ならほぼ無料で運用できる。サーバー代がかからない |
| ** SSL自動** | 鍵マーク（https）が自動で・無料で付く。設定不要 |
| ** 落ちにくい** | 1台壊れても世界中の他サーバーが肩代わり。実質止まらない |
| GitHubと連携 | コードを更新すると自動で公開される（後述の自動デプロイ） |
CDN ＝ 「世界中に支店がある配送網」
Cloudflareが速い最大の理由が CDN（シーディーエヌ／Content Delivery Network）。
普通のサーバーは「東京に1店舗だけ」のようなもの。アメリカの人が見ると、わざわざ東京まで取りに行くから遅い。CDNは「世界各地に支店（コピー）を置いておく」仕組み。見に来た人は一番近い支店からHPを受け取れる。だから世界中どこからでも速い。
→ TERASUは静的サイトなので、このCDNと相性が抜群。完成品をそのまま世界中の支店にばら撒いておけるから、爆速で・落ちにくい。
GitHub連携で「自動デプロイ」される流れ
TERASUの制作物は GitHub（ギットハブ） というコード保管庫で管理している。デプロイ（＝公開）の流れはこう：
| 順 | 何が起きるか |
|---|---|
| 制作者がコードを直して GitHubに保存（push） する | |
| GitHubの変更を Cloudflare Pages が自動で検知する | |
| Cloudflareが自動でビルド（公開の準備）して本番に反映する | |
| 数十秒後、本番URLに最新版が出る |
つまり「コードを保存するだけで、勝手に公開される」。FTPで手作業アップロード…のような昔ながらの面倒がない。これがモダンな制作フローの気持ちよさ。
→ デプロイ（deploy）＝「公開・反映する」という意味の業界用語。「デプロイした？」＝「公開した？」と覚えればOK。
ドメインとは / DNSとは（超重要）
ここが一番つまずきやすい。でも例え一発で分かるので、ゆっくりいこう。
ドメイン ＝ 「サイトの住所（覚えやすい名前）」
terasu.scale-group.co.jp のような文字列がドメイン。これは人間が覚えやすいように付けたサイトの住所・名前。
でも実は、サーバーには本当の所在地として IPアドレス（例: 104.21.55.123 のような数字）が割り当てられている。ブラウザが最終的に通信する相手は、この数字のIPアドレス。
例えるなら、ドメイン（terasu.scale-group.co.jp）＝「〇〇商店という店名」、IPアドレス（104.21.x.x）＝「その店の実際の住所・座標」。人は店名で覚えるけど、配達するには本当の住所が要る。
| ドメイン | IPアドレス |
|---|---|
terasu.scale-group.co.jp |
104.21.55.123（例） |
| 人間が覚える名前 | コンピュータが使う実際の番地 |
| 店名・ブランド名 | 地図上の正確な位置 |
DNS ＝ 「名前から番地を引く電話帳」
問題は「ドメイン（名前）しか知らないのに、どうやって本当の番地（IPアドレス）にたどり着くの？」ということ。これを解決するのが DNS（ディーエヌエス／Domain Name System）。
DNSは「電話帳」や「住所録」。あなたが「〇〇商店さんに荷物を届けたい」と言うと、「〇〇商店なら住所は△△ですよ」と教えてくれる。DNSは「terasu.scale-group.co.jp なら、IPは 104.21.x.x ですよ」と教えてくれる。
実際の流れ：
| 順 | 何が起きるか |
|---|---|
ブラウザに terasu.scale-group.co.jp と入力する |
|
| ブラウザがDNS（電話帳）に「このドメインのIPアドレス教えて」と聞く | |
| DNSが「IPは 104.21.x.x です」と答える | |
| ブラウザがそのIPのサーバーにHPを取りに行く | |
| サーバーがHPを返して、画面に表示される |
→ つまり毎回HPを見るたびに、裏で「名前 → 番地」の変換が一瞬で行われている。普段は意識しないが、これがインターネットの土台。
ネームサーバー / Aレコード / CNAMEレコード（用語を例えで）
DNS設定をいじるとき出てくる用語。それぞれ役割を例えで押さえる。
| 用語 | 役割 | 例え |
|---|---|---|
| ネームサーバー | そのドメインの「電話帳をどこが管理するか」の指定 | 「うちの住所録はこの電話帳会社に任せる」という宣言 |
| Aレコード | ドメインをIPアドレス（数字）に結びつける1行 | 「店名 → 番地（〇〇市1-2-3）」の登録 |
| CNAMEレコード | ドメインを別の名前に結びつける1行（転送・別名） | 「この店名はあっちの店名と同じ場所ですよ」の登録 |
ネームサーバー＝どの電話帳を使うかの大元の設定。Aレコード／CNAMEレコード＝その電話帳の中に書く「1行1行の登録内容」。Cloudflareを使う場合、独自ドメインのネームサーバーをCloudflareに向けるか、CNAMEでCloudflareの住所を指すことで、HPと住所が結びつく。
独自ドメインをHPに繋ぐ流れ（全体像）
「お客さんが買った 〇〇.com を、作ったHPに繋ぐ」までの流れ：
| 順 | やること |
|---|---|
ドメインを取得する（お名前.com / Cloudflare Registrar 等で 〇〇.com を買う） |
|
| DNSを設定する（そのドメインを Cloudflare に向ける＝ネームサーバー or CNAME設定） | |
Cloudflare PagesにドメインをConnectする（「このHPは 〇〇.com で公開します」と登録） |
|
| DNS反映を待つ（数分〜最大数時間。後述） | |
SSLが自動で付く＆ 〇〇.com でHPが表示される（公開完了） |
→ 難しく見えるが、要は「ドメイン（名前）を買って → 電話帳（DNS）に"このHPはここ"と書いて → 反映を待つ」だけ。
SSL / HTTPS（鍵マーク）
SSL ＝ 「通信を暗号化する仕組み」
URLの先頭が https:// になっていて、ブラウザのアドレスバーに鍵マークが出るアレ。これは SSL（エスエスエル） で通信が暗号化されている印。
例えるなら「中身が見えない封筒や宅配ボックス」。SSLが無い（
http://）と、やり取りの中身がハガキのように丸見え。SSLが有る（https://）と、封筒に入って鍵がかかっているので、途中で誰かに盗み見られても中身が読めない。
なぜ必須なのか
| 理由 | 中身 |
|---|---|
| ** 情報を守る** | 問い合わせフォームの名前・電話・メールが盗み見られない |
| ** 警告を出さないため** | SSLが無いとブラウザが「保護されていない通信」と警告を出す。お客さんが不安になって離脱する |
| 信頼の証 | 鍵マークがあるだけで「ちゃんとした会社」に見える |
| SEOに効く | Googleはhttps（SSLあり）のサイトを検索順位で優遇する。無いと不利 |
今どきSSLが無いサイトは「怪しい・危ない・古い」と見なされる。SSLは"あったら良い"ではなく"無いと致命的"。
TERASUなら自動でSSLが付く
ここがCloudflareの嬉しいところ。SSLは自分で証明書を買ったり設定したりする必要がない。Cloudflare Pagesに独自ドメインを繋ぐと、SSLが自動で・無料で付与される。
→ つまり制作者は SSLについて特別な作業をほぼしなくていい。ドメインを繋げば勝手に鍵マークが付く。これも「速くて安全で安い」TERASUの作りの一部。
TERASUの全体構成（今と未来）
ここまでの話を、TERASU全体の構成として一枚にまとめる。
今の構成
制作物（静的HTML/CSS/JS） → GitHub（コード保管） → Cloudflare Pages（ホスティング＝CDN配信＋SSL自動） → 独自ドメイン（DNS設定） → 公開
- HPは静的サイトとして作る
- コードはGitHubで管理
- Cloudflare Pagesが世界中のCDNから配信し、SSLも自動
- 独自ドメインをDNSで繋いで公開
これからの構成 ：Cloudflare for SaaS（マルチテナント）
TERASUはこれからたくさんのクライアントHPを量産していく。1社ごとに別々のプロジェクトを作っていくと管理が大変になる。そこで将来は Cloudflare for SaaS（フォー・サース） という仕組みで、1つの基盤で大量のドメインをまとめてさばく方針。
例えるなら、今は「お店ごとに1棟ずつ建物を建てる」やり方。これからは「1つの巨大なショッピングモールに、各店舗のテナントを入れる」やり方（＝マルチテナント）。1基盤で何百・何千ものクライアントHPと独自ドメインを効率よく配信できる。
| 観点 | 今（Pages） | 未来（for SaaS） |
|---|---|---|
| 構成 | 案件ごとに個別ホスティング | 1基盤に大量テナントを相乗り |
| 例え | 店ごとに1棟建てる | 巨大モールにテナント入居 |
| 強み | シンプル・始めやすい | 大量のドメインを効率配信 |
→ 制作メンバーが今すぐ全部を理解する必要はない。「将来は1つの基盤でクライアントHPをまとめて配信する方向に進む」とだけ頭の隅に置いておけばOK。
公開までの流れ（実務まとめ）
ここまでの知識を、実際の公開作業の順番として通しで並べる。これがTERASUの標準フロー。
| 順 | フェーズ | 何をするか |
|---|---|---|
| 制作 | 静的HTML/CSS/JSでHPを作る | |
| GitHubへ保存 | コードを GitHub に push する | |
| 自動デプロイ | Cloudflare Pagesが検知して自動で公開準備 | |
| 仮URLで確認 | 〇〇.pages.dev という仮の本番URLで表示チェック |
|
| 独自ドメイン接続 | Cloudflare Pagesに 〇〇.com を Connect |
|
| DNS反映待ち | ドメインがHPに向くまで数分〜数時間待つ | |
| SSL自動付与 | 鍵マーク（https）が自動で付く | |
| 公開完了 | 〇〇.com でHPが世界に公開される |
「push（保存）するだけで
.pages.devで確認できて、ドメインを繋いでDNSが反映されればSSL付きで公開」── これがTERASUの公開フロー。手作業のアップロードや証明書設定がない分、速くてミスも少ない。
→ 〇〇.pages.dev（Cloudflareが自動で用意する仮URL）は、独自ドメインを繋ぐ前に動作確認できる便利な仮住所。本番公開前のプレビューとして必ずここで確認する。
よくある疑問（FAQ）
Q. ドメインとサーバーは別物なの？
A. まったくの別物。 ドメインは「住所・名前」、サーバーは「実際にHPが置いてある建物」。
「住所（ドメイン）」を買っても、そこに「建物（サーバー＝Cloudflare Pages）」が無ければHPは表示されない。逆も同じ。両方をDNSで結びつけて初めて公開される。ドメイン代とホスティング代は別々にかかる、と理解しておけばいい。
Q. なぜDNSの反映に時間がかかるの？
A. 世界中の電話帳が一斉に更新されるまで、タイムラグがあるから。
DNS（電話帳）の情報は、世界中の中継地点にコピーされてキャッシュ（一時保存）されている。住所を変更しても、各地のコピーが新しい情報に入れ替わるまで時間がかかる。だから「設定したのにまだ繋がらない」は故障ではなく正常。数分で反映されることもあれば、最大で数時間〜1日程度かかることもある。
→ 「設定が間違ってる！」と焦る前に、まず待つ。反映待ちは正常な現象。
Q. サーバー代（ホスティング代）はいくら？
A. TERASU構成（Cloudflare Pages）なら、基本は無料枠で運用できる。 個人〜中小規模のHPなら、Cloudflare Pagesの無料枠に収まることがほとんど。ドメイン代（年間1,000〜数千円程度）は別途かかるが、サーバー代そのものは大きな負担にならない。これも「安く作れる」TERASUの強みの一部。
Q. 「デプロイ」って何？
A. 「公開する・反映する」という意味。 コードを直して本番に出すことを「デプロイする」と言う。「デプロイした？」＝「もう公開した？」。
Q. .pages.dev のURLと独自ドメインの違いは？
A. .pages.dev はCloudflareが自動でくれる"仮の住所"、独自ドメインは"正式な住所"。 仮URLでも普通に表示できるが、お客さんに見せる本番は独自ドメイン（例 〇〇.com）で公開する。仮URLは公開前の確認用と覚えておく。
Q. 静的サイトだとブログや問い合わせフォームは作れないの？
A. 作れる。 問い合わせフォームは外部サービスやCloudflareの仕組みで実現でき、ブログも記事を静的ファイルとして書き出せば対応できる。「静的＝何もできない」ではなく、「動的な処理は必要な部分だけ外部に任せて、土台は速くて安全な静的で作る」のが今どきのやり方。
まとめ・チェックリスト
結論：TERASUの「静的サイト × Cloudflare Pages × GitHub自動デプロイ」は、速くて・安全で・落ちにくくて・安い、洗練された作り方。WordPressに劣るのではなく、HP制作という目的に対して最適な構成を選んでいる。
この章を読んで、以下が自分の言葉で説明できれば合格：
- [ ] サーバー＝HPを置く建物、ホスティング＝それを貸す不動産屋、と説明できる
- [ ] HPが表示される流れ（ブラウザが取りに行く→サーバーが返す）を順番に言える
- [ ] 静的サイトと動的サイトの違い、TERASUが静的な理由（速い・安全・安い・落ちにくい）を言える
- [ ] TERASUのホスティングは Cloudflare Pages、コード管理は GitHub だと知っている
- [ ] CDN＝世界中に支店がある配送網、という例えを説明できる
- [ ] ドメイン＝住所・名前、IPアドレス＝実際の番地、DNS＝名前から番地を引く電話帳、と説明できる
- [ ] ネームサーバー・Aレコード・CNAMEのざっくりした役割が分かる
- [ ] SSL/HTTPS＝通信を暗号化する封筒、無いと「保護されていない通信」警告＆SEO不利、と言える
- [ ] CloudflareならSSLが自動で付くと知っている
- [ ] 公開フロー（制作→GitHub→自動デプロイ→.pages.devで確認→ドメイン接続→DNS反映待ち→SSL自動→公開）を順に言える
- [ ] DNS反映に時間がかかるのは正常（電話帳のコピー更新待ち）と理解している
- [ ] 将来は Cloudflare for SaaS でクライアントHPをマルチテナント配信する方針、と頭の隅にある
全部 なら、もう「サーバー周りが分からなくて手が止まる」ことはない。お客さんにも自信を持って「速くて安全な最新の作り方です」と説明できる。
【TERASU方針】サーバーは Cloudflare Pages 一択
TERASUのHPは、顧客の状況にかかわらず必ず Cloudflare Pages を使う。
| パターン | 方針 |
|---|---|
| 顧客がサーバーを持っていない | Cloudflare Pages に新規デプロイ |
| 顧客がXserver・さくら・ロリポップ等を使っている | そのサーバーは使わない。Cloudflare Pages にデプロイ |
| 顧客が「既存サーバーにそのまま入れてほしい」と言ってきた | 断ってOK。Cloudflare Pages の優位性（速度・安全・コスト）を説明して理解してもらう |
| 顧客がWordPressで更新したいと言ってきた | TERASU HPとは別の話。TERASUが作る「会社の顔・LP」はCloudflare Pages。WordPressが必要な案件（ブログ大量更新等）はスコープ外 |
この方針を徹底する理由：
- GitHub自動デプロイ・修正無制限の仕組みが、Cloudflare Pages前提で設計されている
- 他社サーバー環境への対応は、環境ごとに作業が変わり工数が読めない
- サーバー管理・トラブル対応のコストが上がり、月額1.5万での運用が成り立たなくなる
「顧客のサーバーに合わせる」=TERASU の仕組みが壊れる。サーバー選定はTERASUが決める前提で進める。