WebアプリでHTTPが使われる場面：HTTPSとの使い分けと判断基準

• 「常時HTTPS一択」と「HTTPでいい場面がある」の食い違い
• HTTPSが「標準」になった経緯
• HTTPとHTTPSの違いを整理する
• HTTPが現れる主なユースケース
  • ローカル開発環境
  • ロードバランサーやリバースプロキシの内側
  • 閉域イントラネットやVPN内のサービス間通信
  • IoTや組込み機器
• 使ってはいけない場面
• 判断フロー：HTTPを使っていい場面か確認する
• Mixed Content問題：HTTPSページにHTTP要素を混在させない
• 実行可能な次の一歩
• 過剰にやらなくてよいこと
• FAQ

結論: 本番でユーザーデータを扱う限りHTTPSが原則。HTTPは開発環境と信頼済みの閉域網に限る。

HTTPSがほぼ無料で使える時代に、「HTTPで十分な場面がまだ存在する」と言うと、驚かれることがあります。 実際には全部をHTTPSにすれば安全というほど単純ではなく、アーキテクチャの構造上HTTPが現れる箇所があります。 ただし「存在する」ことと「使っていい」かどうかは別の話です。この記事では両者をはっきり区別します。

§「常時HTTPS一択」と「HTTPでいい場面がある」の食い違い

HTTPSについては「例外なく常時HTTPS」と言われる一方、開発の現場ではHTTPが当たり前に使われています。方針と実務が食い違って見える場面です。

実際に効いているのは、その通信が信頼できない経路を通るかどうかです。公衆網を経由するならHTTPSが要り、同一マシン内で完結するなら経路上に盗聴者がいません。

つまり「常時HTTPS」は公開されるサービスについての原則です。この記事はその外側を扱います。

§HTTPSが「標準」になった経緯

2014年、GoogleはHTTPS化をランキングシグナルに組み込むと発表しました(Google Webmaster Central Blog)。 翌2015年にはLet’s Encryptが無料の自動証明書を提供し始め、コスト面での障壁がほぼ消えました。 2020年代に入ると、ChromeやFirefoxはHTTPサイトに「保護されていない通信」の警告を表示するようになり、今やHTTPS化は選択肢ではなく前提です。

そうした流れにもかかわらず、現場では依然としてHTTPが顔を出す場面があります。背景を理解しないまま「とりあえずHTTPS」と唱えるより、なぜHTTPSが必要なのかを知ったうえで例外を正しく評価するほうが実務の判断精度が上がります。

§HTTPとHTTPSの違いを整理する

まず土台を確認します。

2026年4月時点では、FirefoxはHTTPページでパスワード入力フォームを検知すると強制的に警告を表示します。Chrome系ブラウザも同様の挙動です。

§HTTPが現れる主なユースケース

§ローカル開発環境

localhost へのアクセスはブラウザセキュリティモデルで「安全なオリジン」扱いです(W3C Secure Contexts)。 実際、http://localhost:3000 で React や Next.js の開発サーバーを立ち上げる構成は珍しくありません。

ただし最初はHTTPで開発して後でHTTPSに切り替えればいいと考えていましたが、実際にはSameSite属性やCookieのSecureフラグ、Content Security PolicyなどをHTTPS前提で設計すると、HTTP環境では動作確認できない挙動が出てきます。可能な限り、開発環境でもHTTPSを再現するほうが後の痛みは少ないと感じています。

§ロードバランサーやリバースプロキシの内側

AWS ALBやNginx、EnvoyなどがフロントエンドのTLSを終端し、バックエンドへの転送をHTTPで行う構成は一般的です。この通信はロードバランサーとバックエンドが同一のVPCやコンテナネットワーク内にいることが前提で、外部からの盗聴経路がありません。

余談ですが、この構成はしばしばセキュリティ監査で指摘対象になります。監査者によっては「内部通信もHTTPSにすべき」と言い、開発者は「同一VPCだから問題ない」と主張する——ここは正直、賛否あります。厳密なゼロトラスト設計(NIST SP 800-207)を採用する場合は、内部通信もmTLSが推奨されます。

§閉域イントラネットやVPN内のサービス間通信

外部インターネットに接続しない工場の生産管理システムや、企業のオンプレミスサーバー間通信では、証明書管理のコストとメリットを天秤にかけた結果、HTTPが選ばれることがあります。 ここで重要なのは「閉じているから安全」ではなく、内部の侵害者や横断侵害(ラテラルムーブメント)のリスクをどう評価するかです。

§IoTや組込み機器

RAM・フラッシュが数百KB〜数MBのMCUでTLSスタックを走らせるのは現実的でない場合があります。 ただし2026年4月時点では、Mbed TLS(旧PolarSSL)など組込み向けの軽量TLS実装が整備されており、「リソースが足りない」は年々言い訳しにくくなっています。

§使ってはいけない場面

以下のシナリオでのHTTPは「リスクの受け入れ」ではなく「過失」と判断される可能性があります。

個人情報保護法については個人情報保護委員会のガイドライン、GDPRについては欧州委員会のGDPRページを参照してください(2026年4月時点)。

§判断フロー：HTTPを使っていい場面か確認する

§Mixed Content問題：HTTPSページにHTTP要素を混在させない

HTTPSで配信されるページ内に、HTTPで読み込むスクリプト・画像・APIリクエストが1つでもあるとMixed Contentが発生します。

• Passive Mixed Content(画像・動画): ブラウザは警告を出すが読み込む
• Active Mixed Content(スクリプト・フレーム・XHR/fetch): ブラウザがブロックする

fetch("http://api.example.internal/data") をHTTPSページから呼び出すと、Chromeはネットワーク接続を拒否します。バックエンドが内部HTTPであっても、ブラウザから直接呼び出す場合はHTTPSが必要です。この場合の解決策は、HTTPSで受けるプロキシ(BFF: Backend For Frontend)を挟むことです。

§実行可能な次の一歩

現在のプロジェクトを確認するための最小チェックリストです。

1. Chrome DevToolsのSecurityパネルを開き、Mixed Contentの警告がないか確認する
2. curl -I http://your-app.example.com を実行し、301 Moved Permanently で https:// へのリダイレクトが返るか確認する
3. ロードバランサー内部通信のHTTPについて、VPCのセキュリティグループ・ACLで外部からの443以外のアクセスを遮断しているか確認する
4. 開発環境で mkcert(FiloSottile/mkcert)を使い、ローカルでもHTTPSを有効にする
5. Cookieに Secure と HttpOnly が付いているかDevToolsのApplicationタブで確認する

Webのセキュリティ設定は技術選定やアーキテクチャ判断と密接に絡みます。制度面の管理措置に興味があれば、給与明細の控除項目を読む：社会保険料と税金の仕組みのように「文書が現実を動かす」場面を理解する視点も、セキュリティ文書の整備に役立ちます。

§過剰にやらなくてよいこと

• ローカル開発環境に証明書を入れる必要は必ずしもありません —— HTTPS前提の機能を検証するときだけで足ります
• 社内の閉じた検証環境を全部HTTPS化する必要はありません —— 経路が信頼できるなら、優先順位は下がります
• 証明書を有料のものにする必要はありません —— 無料の自動発行で要件を満たせる用途がほとんどです
• HTTPを使うたびに罪悪感を持つ必要もありません —— 判断すべきは「その経路に第三者が入りうるか」の一点です

§FAQ

Q. 社内システムだからHTTPでいい、という判断は正しいですか? A. ネットワーク構成次第です。インターネットに接続しない完全な閉域ならリスクは低くなりますが、社内PCがVPN経由でアクセスする構成や、クラウド上のプライベートサブネットの場合は「社内」の定義が曖昧です。ゼロトラストの観点では、物理的な境界に依存しない認証・暗号化が推奨されます。

Q. ローカル開発環境もHTTPSにすべきですか? A. できればそうすべきです。mkcert を使えば数分で自己署名証明書を信頼済みにできます。特にSameSite=Strict CookieやHTTPS専用APIを扱う場合は、開発段階からHTTPS環境で再現することでデバッグコストが下がります。

Q. Let’s Encryptの証明書は本当に無料ですか? A. 2026年4月時点では無料です。ただし発行には公開ドメインが必要で、プライベートIPや内部ホスト名には発行できません。その場合はプライベートCAを立てるか、ACMEプロトコルに対応したプライベートCA製品(例