サービスを公開する仕上げが，HTTPS化と独自ドメインの接続だ．第13回で取得した独自ドメインを，第14〜15回で構築した本番環境につなぎ，通信を暗号化する．これで，ようやく『安全で信頼されるサービス』として世に出せる．
今や，HTTPSは『あったらいい』ではなく『無ければ話にならない』必須条件だ．HTTPに対応していないサイトは，ブラウザに『安全ではありません』と警告され，ユーザーは不安になって離れる．とくにお金や個人情報を扱うSaaSでは，HTTPSは絶対に欠かせない．
この記事は，本番環境を整え，いよいよ独自ドメインで安全に公開する個人開発者に向けて書いている．HTTPSの仕組み，無料SSL証明書，リバースプロキシでの自動HTTPS化，DNSでのドメイン接続，証明書の自動更新まで，安全な公開の仕上げを解説する．
扱う範囲は，HTTPSの重要性 → SSL/TLSの仕組み → 無料証明書 → DNSでドメインを向ける → リバースプロキシでHTTPS化 → 証明書の自動更新 → HTTPへのアクセス対策 → 混在コンテンツ → よくある失敗，だ．読み終えたとき，あなたは独自ドメインで安全に公開する仕上げを理解している．
なぜHTTPS化が「絶対に必須」なのか
HTTPSは，ブラウザとサーバーの間の通信を暗号化する仕組みだ．これがないと，通信内容が第三者に盗み見られたり，改ざんされたりする危険がある．パスワードやカード情報が平文で流れるなど，SaaSにとって致命的だ．
第一の理由は，当然ながらセキュリティだ．第7回の認証，第10回の課金で扱う機密情報が，暗号化されずに流れては，これまでの安全対策がすべて無意味になる．HTTPSは，それらの土台となる『通信路の安全』を担保する．
第二の理由は信頼だ．HTTPS化されていないサイトは，ブラウザが警告を出す．ユーザーは『危険なサイト』と認識し，登録も決済もせずに去る．逆に，鍵マークの付いた安全な接続は，ユーザーに安心を与える．第13回のブランディングの一部とも言える．
第三に機能と評価だ．最近のブラウザ機能の多くはHTTPSを前提とし，検索エンジンもHTTPSを評価する(第21回のSEO)．本記事のメッセージは明快だ．『HTTPS化は，安全・信頼・機能・評価のすべてに関わる，公開の絶対条件である』．
SSL/TLSの仕組み ― 何が通信を守るのか
HTTPSを支える技術がSSL/TLSだ(正確には現在はTLSだが，慣用的にSSLとも呼ばれる)．これは，通信を暗号化し，かつ『接続先が本物か』を証明する仕組みで，その証明書をSSL証明書と呼ぶ．
SSL証明書は，『このドメインの正当な所有者である』ことを証明する電子的な証明書だ．これがあることで，ブラウザは『確かにこのサイトと安全に通信している』と確認でき，鍵マークを表示する．証明書は，認証局という第三者機関が発行する．
仕組みの詳細を完全に理解する必要はないが，要点はこうだ．『独自ドメインに対してSSL証明書を取得し，それをサーバー(リバースプロキシ)に設定すると，通信が暗号化され，HTTPSになる』．第13回で独自ドメインを取得したのは，この証明書を取得できるようにするためでもあった．
かつてSSL証明書は有料で，取得も手間だった．だが今は，無料で，自動で取得・更新できる仕組みが普及し，個人でも簡単にHTTPS化できるようになった．これも第1回で触れた『個人がSaaSを作れる時代』を支える要素の一つだ．
証明書の種類を知る
SSL証明書には種類がある．最も基本的なのが『ドメイン認証(DV)』で，ドメインの所有を確認するだけで発行され，無料証明書もこのタイプだ．個人開発のSaaSなら，まずこれで十分なことがほとんどだ．
より厳格に法人の実在性まで証明する上位の証明書もあるが，価格も手間もかかる．大企業や金融系では使われるが，個人開発の初期は無料のドメイン認証証明書で問題ない．必要になったら上位を検討すればよい．
暗号化と認証の両方を担う
SSL/TLSは，通信の暗号化(盗聴を防ぐ)と，接続先の認証(なりすましを防ぐ)の両方を担う．偽のサイトに誘導されて情報を抜き取られる攻撃を防ぐ意味でも，証明書による認証は重要だ．
つまりHTTPSは，単に『暗号化されている』だけでなく『正しい相手と通信している』ことも保証する．ユーザーが安心してパスワードやカード情報を入力できるのは，この二重の保証があるからだ．
無料SSL証明書 ― 個人開発の標準
個人開発のHTTPS化で，今や標準となっているのが無料のSSL証明書だ．無料の認証局が提供する証明書を使えば，コストゼロでHTTPS化でき，しかも自動で取得・更新できる．これにより，HTTPS化のハードルは劇的に下がった．
無料証明書は，前述のドメイン認証タイプで，ドメインの所有を自動的に確認して発行される．第13回で取得した独自ドメインがあれば，その所有を証明するだけで，証明書が手に入る．有料証明書と暗号化の強度自体は変わらない．
重要なのは，これらの無料証明書が多くのリバースプロキシやツールと連携し，取得から設定，更新までを自動化できることだ．次に述べるように，リバースプロキシによっては，ほぼ設定なしで自動的にHTTPS化してくれるものもある．個人開発では，この自動化の恩恵を最大限に活用したい．
無料証明書には有効期限が短い(数か月)という特徴があるが，これは自動更新で対応する(後述)．期限切れはサービス停止に直結する重大事故なので，必ず自動更新を設定する．無料であることのわずかな手間は，自動化で完全に解消できる．
有料証明書が必要な場面は限られる
『無料で大丈夫か』と不安に思うかもしれないが，暗号化の強度は有料と同じで，技術的に劣るわけではない．個人開発のSaaSなら，無料証明書で全く問題ない．世界中の多くのサイトが，同じ無料証明書を使っている．
有料証明書が必要なのは，法人の実在証明を厳格に示したい場合や，特殊な要件があるときくらいだ．まずは無料証明書でHTTPS化し，ビジネス上の必要が生じたら上位を検討する，で十分だ．
DNSでドメインをサーバーに向ける
HTTPS化の前に，まず独自ドメインを，本番のVPSに向ける必要がある．これは第13回で触れたDNSの設定で行う．ドメインに来たアクセスが，あなたのVPSのIPアドレスに届くようにする，いわば住所と建物を結びつける作業だ．
具体的には，ドメインのDNS設定で『このドメインを，このサーバーのIPアドレスに向ける』というレコード(Aレコード等)を登録する．第13回で触れたサブドメイン(app.〜，api.〜など)も，それぞれサーバーに向ける設定をする．
DNSの設定は，反映までに少し時間がかかる(伝播)ことを思い出そう．設定してすぐ繋がらなくても慌てず，反映を待つ．ドメインが正しくサーバーに向いていることを確認してから，次のHTTPS化に進む．この順序が重要だ── ドメインがサーバーに向いていないと，証明書の取得もできない．
DNSでドメインをサーバーに向け，ブラウザで(まだHTTPの状態で)アクセスしてサービスが表示されることを確認できたら，HTTPS化の準備は整った．『ドメインがサーバーを指す』→『HTTPS化する』という順序を守って進めよう．
サブドメインも忘れずに向ける
本体ドメインだけでなく，第13回で設計したサブドメイン(app.〜，api.〜，docs.〜など)も，それぞれサーバーに向ける．使うサブドメインすべてについて，DNS設定とHTTPS化が必要になる．
ワイルドカード(すべてのサブドメインをまとめて向ける設定や証明書)を使えば，サブドメインが増えても柔軟に対応できる．第8回のテナントごとのサブドメイン構成を採るなら，このワイルドカード対応が役立つ．
wwwあり・なしを揃える
『example.com』と『www.example.com』のどちらでもアクセスできるよう，両方をサーバーに向け，片方にリダイレクト(統一)するのが親切だ．どちらか一方しか繋がらないと，ユーザーが混乱する．
通常は，どちらかを正式なURLと決め，もう一方からそこへ転送する．これも第21回のSEOで重要になる(URLの統一)．最初に決めて，一貫させておこう．
リバースプロキシでHTTPS化する ― 最も簡単な方法
ドメインがサーバーに向いたら，いよいよHTTPS化だ．最も簡単なのは，第14〜15回で立てたリバースプロキシにHTTPS化を担わせる方法だ．多くのリバースプロキシは，SSL証明書の取得・設定・更新を自動でこなす機能を持つ．
とくに，設定するだけで無料証明書を自動取得し，HTTPSにしてくれるリバースプロキシを使えば，HTTPS化は驚くほど簡単になる．ドメイン名を指定するだけで，証明書の取得から自動更新までを丸ごと任せられる．個人開発では，こうしたツールの活用が最も効率的だ．
リバースプロキシでHTTPS化すると，外部との通信(リバースプロキシまで)は暗号化され，その内側でアプリへ取り次ぐ形になる．アプリ自体はHTTPSを意識せずに済み，リバースプロキシが暗号化の責任を一手に引き受ける．第15回で『リバースプロキシを安全な入口に』と述べたが，HTTPSもその重要な役割の一つだ．
HTTPS化できたら，ブラウザでアクセスして鍵マークが表示され，警告が出ないことを確認する．鍵マークが出れば，通信は暗号化され，証明書も正しく機能している．これで，安全な接続の土台が完成する．
証明書取得にはドメインの所有確認が要る
無料証明書の自動取得では，『そのドメインを本当に管理しているか』の確認が行われる．多くは，サーバーが特定の応答を返せるか(ドメインがサーバーに向いているか)で自動確認される．だからこそ，先にDNSでドメインをサーバーに向けておく必要がある．
この確認が通れば，証明書が自動で発行・設定される．手順としては『DNSで向ける→リバースプロキシで証明書取得を指示』という流れになる．順序さえ守れば，自動でHTTPS化が完了する．
アプリ側のURL設定も合わせる
HTTPS化したら，アプリが生成するURL(メール内のリンクや，リダイレクト先など)もHTTPSにする．アプリの設定で『自分のURLはHTTPSである』と認識させ，HTTPのリンクを生成しないようにする．これを忘れると，後述の混在コンテンツや，リンク切れの原因になる．
第11回のメール内のリンクや，第7回の認証後のリダイレクトなども，すべてHTTPSになるよう設定する．サービス全体が一貫してHTTPSで動く状態を目指そう．
証明書の自動更新 ― 期限切れを絶対に防ぐ
無料証明書は有効期限が短いため，自動更新の設定が絶対に欠かせない．証明書の期限が切れると，ブラウザが『安全ではない』と強い警告を出し，ユーザーがサービスを使えなくなる．これは第13回のドメイン失効と同じく，サービス停止に直結する重大事故だ．
幸い，前述の自動HTTPS化に対応したリバースプロキシやツールは，証明書の更新も自動でこなす．期限が近づくと自動で新しい証明書を取得・適用してくれるため，一度設定すれば，あとは気にせずに済む．これが，無料証明書を安心して使える理由だ．
重要なのは，自動更新が本当に機能しているかを，一度は確認しておくことだ．設定したつもりで実は動いていなかった，という事態を避けるため，更新の仕組みが正しく動くかをチェックする．第13回のドメイン更新と同じく，ここは『設定して終わり』にせず，確実に動くことを確かめたい．
証明書の有効期限は，監視の対象にもしておくとさらに安心だ(第18回)．万一自動更新が失敗しても，期限切れ前に気づいて手動で対応できる．『自動更新＋期限の監視』の二重の備えで，証明書切れによるサービス停止を確実に防げる．
期限切れはドメイン失効と並ぶ事故
証明書の期限切れは，第13回のドメイン失効と並ぶ『うっかりによるサービス停止』の典型だ．どちらも，自動化と確認で確実に防げるものなので，最初にきちんと仕組みを作っておきたい．
数か月ごとの更新を手作業に頼ると，必ずいつか忘れる．自動更新を設定し，その動作を確認し，できれば期限を監視する── この備えで，証明書切れの悲劇は起こさずに済む．
HTTPへのアクセスをHTTPSへ統一する
HTTPS化しても，古いHTTP(暗号化なし)のURLでアクセスできる状態が残ることがある．これを放置すると，暗号化されない通信が残り，セキュリティの穴になる．HTTPでアクセスしてきたユーザーを，自動的にHTTPSへ転送(リダイレクト)する設定が必要だ．
リバースプロキシで，『HTTPで来たアクセスは，すべてHTTPSへ転送する』設定をする．これにより，ユーザーがうっかりHTTPでアクセスしても，自動的に安全なHTTPS接続に切り替わる．サービス全体を，確実にHTTPSに統一できる．
さらに進んだ対策として，ブラウザに『このサイトは常にHTTPSで接続せよ』と指示するヘッダー(HSTS)を設定する方法もある．これにより，最初からHTTPを試みることすらなくなり，より安全になる．第15回で触れたセキュリティヘッダーの一つとして，設定を検討したい．
HTTPからHTTPSへの統一は，セキュリティとSEOの両面で重要だ．暗号化されない通信を残さず，URLをHTTPSに一本化することで，安全性も検索評価(第21回)も高まる．HTTPS化したら，必ずHTTPからの転送もセットで設定しよう．
URLをHTTPSに一本化する意義
HTTPとHTTPSが両方アクセス可能だと，同じページが2つのURLで存在することになり，セキュリティだけでなくSEO上も好ましくない．HTTPSに一本化(HTTPは転送)することで，評価が分散せず，安全性も保たれる．
第13回のwwwあり・なしの統一と同じ発想で，URLは一つに揃えるのが原則だ．『正式なURLはHTTPSのこの形』と決め，それ以外はすべてそこへ転送する．一貫したURLは，安全性・SEO・ユーザー体験のすべてに効く．
混在コンテンツの解消 ― 鍵マークを完全にする
HTTPS化したのに，ブラウザの鍵マークに警告が付くことがある．その主な原因が『混在コンテンツ(Mixed Content)』だ．これは，HTTPSのページの中に，HTTP(暗号化なし)で読み込まれる要素(画像・CSS・JS等)が混ざっている状態を指す．
混在コンテンツがあると，ブラウザは『一部が安全でない』と判断し，警告を出したり，その要素の読み込みをブロックしたりする．せっかくHTTPS化しても，完全な安全と信頼の表示にならない．これを解消する必要がある．
解決は，ページ内で読み込むすべての要素を，HTTPSで読み込むようにすることだ．前述の通りアプリのURL設定をHTTPSにし，外部から読み込むリソースもHTTPSのものを使う．すべての要素がHTTPSで読み込まれれば，混在コンテンツは解消し，完全な鍵マークが表示される．
混在コンテンツは，HTTPS化の『最後の仕上げ』でつまずきやすいポイントだ．ブラウザの開発者ツールで警告を確認すれば，どの要素が原因かが分かる．一つずつHTTPSに直して，警告のない完全なHTTPS状態を目指そう．
ブラウザの警告で原因を特定する
混在コンテンツがあると，ブラウザの開発者ツールに警告が表示され，どのリソースがHTTPで読み込まれているかが分かる．これを手がかりに，原因の要素を特定して修正する．
公開前(または公開直後)に，主要なページで警告が出ていないかを確認する習慣をつけよう．鍵マークが完全な状態であることが，ユーザーに完全な安心を与える．地味だが，信頼の仕上げとして大切だ．
HTTPS化・ドメイン接続でやりがちな失敗
最後に，個人開発のHTTPS化・ドメイン接続でありがちな失敗を確認しよう．いずれも，安全性や信頼を損なうものだ．
- 証明書の自動更新を設定しない：期限切れでサービス停止
- HTTPからHTTPSへ転送しない：暗号化されない通信が残る
- 混在コンテンツを放置する：鍵マークに警告が付き信頼を損なう
- DNSの伝播を待たず焦る：繋がらないと誤解して設定をいじり混乱
- アプリのURL設定をHTTPのままにする：メールのリンク等が安全でなくなる
共通する教訓は，『ドメインをサーバーに向け，リバースプロキシで自動HTTPS化し，自動更新を設定し，HTTPからの転送と混在コンテンツの解消まで仕上げる』ことだ．HTTPS化は，安全と信頼の土台．一連の手順を漏れなく行い，完全な鍵マークで，安心してユーザーを迎えよう．
公開前にHTTPSを総点検する
公開前に，『鍵マークが警告なく表示されるか・HTTPでアクセスするとHTTPSへ転送されるか・証明書の自動更新は設定されたか・メール内のリンクもHTTPSか』を総点検しよう．HTTPS化は，これまでの認証・課金・メールの安全対策の土台だ．
通信路が安全でなければ，どんなに各機能を堅牢にしても意味がない．HTTPS化の総点検をもって，安全な公開の仕上げとしよう．これで，あなたのサービスは安心してユーザーを迎えられる．
補論 ― 安全な公開は「ドメイン＋VPS」で完成する
HTTPS化と独自ドメイン接続は，これまで積み上げてきた公開フェーズの仕上げだ．そしてこの仕上げは，独自ドメインと，自分で制御できるサーバーが揃って初めて完成する．両者があるからこそ，証明書を取得し，自動HTTPS化し，安全な公開ができる．
サービスの顔となる独自ドメインは取り扱い400種類以上のドメイン取得サービス─ムームードメイン─で取得でき，その所有があるからこそSSL証明書を取得してHTTPS化できる．DNSの設定でドメインをサーバーに向け，サブドメインやwwwの統一まで，ドメインの管理画面から柔軟に行える．そして，リバースプロキシで自動HTTPS化を担う本番環境には，高速NVMe・50種類以上のOSテンプレートに対応した国内VPS─シン・VPS─のような自分で制御できる高速VPSが最適だ．証明書の自動取得・更新を仕込み，HTTPからの転送を設定し，安全な入口を自分の手で作れる．独自ドメイン＋VPSの組み合わせが，安全で信頼される公開を可能にする．
『独自ドメインを安全につなぎ，完全なHTTPSで公開する』── これで，開発から公開までの長い道のりの，技術的な仕上げが完了した．あなたのサービスは，安全で信頼される姿で世界に立っている．だが公開はゴールではない．次回は，毎回のデプロイを自動化し，git pushで本番が更新される『CI/CDで自動デプロイ』を解説する．
よくある質問(FAQ)
Q1．HTTPS化は本当に必須ですか？
必須です．HTTPに対応していないサイトはブラウザに『安全ではありません』と警告され，ユーザーが離れます．第7回の認証や第10回の課金で扱う機密情報が暗号化されずに流れては，これまでの安全対策が無意味になります．さらにブラウザの機能や検索評価（第21回）もHTTPSを前提とするため，安全・信頼・機能・評価のすべてに関わる絶対条件です．
Q2．SSL証明書は有料のものが必要ですか？
個人開発のSaaSなら無料証明書で十分です．無料の認証局が提供する証明書は暗号化の強度も有料と同じで，自動で取得・更新できます．ドメイン認証（DV）タイプで，第13回で取得した独自ドメインの所有を確認して発行されます．有料が要るのは法人の実在証明を厳格に示したい等の限られた場面だけです．
Q3．HTTPS化の最も簡単な方法は？
リバースプロキシにHTTPS化を担わせる方法です．設定するだけで無料証明書を自動取得しHTTPSにしてくれるリバースプロキシを使えば，ドメイン名を指定するだけで取得から自動更新まで丸ごと任せられます．第14〜15回で立てたリバースプロキシに，この役割を持たせるのが個人開発では最も効率的です．
Q4．ドメインとHTTPS化，どちらを先にやる？
先にDNSでドメインをサーバーに向け，それからHTTPS化します．無料証明書の自動取得では『そのドメインを本当に管理しているか』をサーバーの応答で確認するため，ドメインがサーバーに向いていないと証明書を取得できません．DNSの反映には時間がかかる（伝播）ので，焦らず反映を待ちましょう．
Q5．証明書の自動更新は必ず必要ですか？
必須です．無料証明書は有効期限が短く，切れるとブラウザが強い警告を出してユーザーが使えなくなります（サービス停止に直結）．自動HTTPS化対応のリバースプロキシは更新も自動でこなします．設定したら一度は本当に機能するか確認し，できれば期限を監視（第18回）して二重に備えましょう．
Q6．HTTPでもアクセスできてしまいます
リバースプロキシで『HTTPで来たアクセスはすべてHTTPSへ転送する』設定をしてください．これでうっかりHTTPでアクセスしても自動的に安全な接続に切り替わります．さらにHSTSヘッダー（このサイトは常にHTTPSで接続せよとブラウザに指示）を設定すると，より安全になります．URLのHTTPS一本化は，セキュリティもSEOも高めます．
Q7．鍵マークに警告が付くのはなぜ？
混在コンテンツ（Mixed Content）が主な原因です．HTTPSページ内にHTTPで読み込まれる要素（画像・CSS・JS）が混ざっている状態です．ブラウザの開発者ツールで警告を確認すると原因の要素が分かります．アプリのURL設定をHTTPSにし，すべての要素をHTTPSで読み込めば解消し，完全な鍵マークになります．
Q8．wwwあり・なしはどう扱えばいい？
どちらでもアクセスできるよう両方をサーバーに向け，片方を正式URLと決めてもう一方からそこへリダイレクト（統一）します．一方しか繋がらないとユーザーが混乱します．これは第21回のSEOでも重要で，URLを一つに揃えることで評価が分散せず，ユーザー体験も良くなります．最初に決めて一貫させましょう．
Q9．HTTPS化すると表示が遅くなりませんか？
実用上ほとんど問題ありません．暗号化の処理は現代のサーバーでは軽く，むしろHTTPSが前提の高速化技術（HTTP/2など）を使えると速くなる面もあります．第15回のリバースプロキシで適切に設定し，第14回・第6回で触れた高速なVPSを使えば，HTTPS化による体感の遅さはまず気になりません．安全性の利益の方がはるかに大きいです．
Q10．サブドメインも個別にHTTPS化が必要ですか？
必要です．app.〜，api.〜，docs.〜など，使うサブドメインごとにDNSでサーバーへ向け，それぞれHTTPS化します．ワイルドカード対応の証明書を使えば，すべてのサブドメインをまとめて証明書でカバーでき，第8回のテナントごとのサブドメイン構成にも柔軟に対応できます．自動HTTPS化のリバースプロキシなら，サブドメイン追加時の手間も小さく済みます．
まとめ ― 完全なHTTPSで，安全に公開を仕上げる
HTTPS化と独自ドメイン接続は，安全で信頼されるSaaSの絶対の必須条件であり，公開の仕上げだ．通信を暗号化し，接続先を証明し，ユーザーに鍵マークの安心を届ける．これがなければ，認証も課金も，その安全性は成り立たない．
鍵は，『DNSでドメインをサーバーに向け』『リバースプロキシで自動HTTPS化』『証明書の自動更新を設定』『HTTPからHTTPSへ転送』『混在コンテンツを解消』することだ．そして無料証明書を活用し，コストゼロで安全を実現する．
今や，HTTPS化は個人でも簡単にできるようになった．独自ドメインと自分で制御できるVPSがあれば，自動化の恩恵を最大限に活かして，完全なHTTPSで公開できる．安全と信頼の土台を，確実に仕上げよう．
これで，開発から公開までの技術的な仕上げが完了した．だが，公開はゴールではなくスタートだ．次回は，機能を追加するたびのデプロイを自動化し，git pushするだけで本番が更新される『CI/CDで自動デプロイ』の仕組みを解説する．