HTTP

デジタル大辞泉

エッチ‐ティー‐ティー‐ピー【HTTP】

読み方：えっちてぃーてぃーぴー

《hypertext transfer protocol》インターネット上でのデータ転送のためのプロトコル。WWWサーバーとブラウザーがHTMLファイルや画像、音声などのデータの送受信に用いられる。ハイパーテキスト転送プロトコル。

DBM用語辞典

HTTP

【英】Hypertext Transfer Protocol
別名：ハイパーテキスト・トランスファー・プロトコル

WWWでハイパーテキスト文書にリンクするためのプロトコル。先立つものとして、ウェブサイトのアドレスなど（例えば、http://marketplace.com など）

ネットワーク用語集

HTTP

Hyper Text Transfer Protocol
WWWサーバーとWWWブラウザ（Webブラウザ）などが、ファイルなどの情報を送受信するのに使うプロトコル。TCP/IPの上位層に位置する。

関連用語：

• Webブラウザ
• TCP/IP

PHP用語集

HTTP

【英】 HyperText Transfer Protocol

WWWブラウザーとWebサーバーの間でHyperText Markup Language (HTML) などのコンテンツをやり取りする際に用いられる通信プロトコル。

関連用語

• Apache Web Server
• Ajax
• GET
• POST
• WWWブラウザ ー
• BASIC認証

IT用語辞典バイナリ

HTTP

フルスペル：Hypertext Transfer Protocol
読み方：エイチティーティーピー
別名：ハイパーテキスト転送プロトコル

HTTPとは、ブラウザを使ってウェブ上の情報にアクセスするための方式（通信プロトコル）の名称である。あるいは、「通信プロトコルにはHTTPを使いますよ」と宣言する意味でURLの先頭に掲げられる文字列である。

HTTPは、通信プロトコルの一種である。「プロトコル」とは、日本語では「規約」「典礼」「実施要項」などと訳されるが、つまるところは「正確な意思疎通を図るために構築された約束事」である。たとえば外交の分野では、国旗の掲げ方や、典礼における服装やもてなし方などが、国際的に標準化され共有されている。これによって異国・異文化の賓客にもあらぬ誤解を抱かれずに正しくもてなすことができている。こうした約束事・取り決めが「プロトコル」である。そして、ITの分野においては「サーバー」と「クライアント」が（インターネットを通じて）データを扱う際の通信方式が「プロトコル」と呼ばれる。その中でもWebサーバーとWebブラウザの間のやり取りに用いられるプロトコルが「HTTP」であるというわけである。

ブラウザを使ったアクセスではHTTP（またはHTTPS）が標準的なプロトコルであるが、ブラウザを用いない「ファイル転送」においては「FTP」と呼ばれるプロトコルが多く用いられる。電子メールの送受信に用いられるプロトコルはSMTP、POP、IMAPと複数ある。

HTTPは、ファイル伝送に利用されるFTPや、電子メールのやりとりに用いられるSMTPなどと並び、インターネット上で最も頻繁に利用されるプロトコルの一種となっている。

HTTPは、WWW（World Wide Web）上でサーバー（Webサーバー）とクライアント（Webブラウザ）が、HTML文書などのデータの交換・やり取りを行うための方式として規定されている通信プロトコルである。

HTTPは、TCP上でパケット単位で情報のやりとりを行う。HTTPの大きな特徴として、基本的にステートレスな通信であり、一つの要求（リクエスト）に対して一つの応答（レスポンス）で完結するというシンプルな通信である、という点が挙げられる。リクエストを受けたWebサーバーは、HTMLで記述された文書ファイルやHTMLによって関連付けられたマルチメディアデータなどをクライアントに転送する。Webブラウザは、受信したデータを解析し、レンダリングを行って、整理されたHTML文書として画面に表示する。

HTTPにおけるデータは、制御情報を持つHTTPヘッダ部と、コンテンツデータを含むHTTPボディ部からなる単純な構造をしている。転送可能な情報の種類には、特に制限がない。

なお、「HTTPS」は、HTTPにSSL（Secure Sockets Layer）の暗号化を施し、セキュリティ性を向上させたプロトコルである。つまりHTTPSはHTTPのセキュリティ強化版としての発展型である。HTTPとHTTPSとの違いは「セキュア性」に尽きる。ちなみに、HTTPのポート番号はデフォルトでは80番であり、HTTPSのポート番号はデフォルトで443番となっている。

HTTP1.1において、HTTP要求で指定されるHTTPメソッドには、GET、POST、PUT、HEAD、DELETE、CONNECT、OPTIONS、TRACEなどがある。それぞれの意味は、GETは、相手サーバーからクライアントへのファイル伝送要求、POSTは、クライアントから相手サーバーへのデータ送信要求（HTTPボディ部を用いる）、PUTは、クライアントから相手先サーバーへのファイルのアップロード要求、HEADは、相手先サーバーのファイル更新情報の問い合わせ要求、DELETEは、相手先サーバーのファイルの削除要求、CONNECTは、プロキシの指定要求、OPTIONSは、利用可能なオプションの問い合わせ要求である。

Web上での典型的な利用の仕方としては、おおむね以下の通りである。まず、ユーザーは、Webブラウザ上で参照先ドキュメントのURL（Uniform Resource Locator）を指定する。URLは「http://server.mydomain.jp/dir/document.html」のような形をしている。「http」は、プロトコルの種類（暗号化通信の場合は、httpsとなる）、「server.mydomain.jp」は、接続先ドメイン名を意味する。Webブラウザは、ドメイン名をDNSに問い合わせ、IPアドレスを得て80番ポートに接続する。接続が成功すると、相手先のサーバーに対して、1行目に「GET /dir/document.html HTTP/1.0」のようなデータを持つ、HTTPヘッダ部を持つHTTP要求パケットを送信する。この1行をリクエスト行と呼ぶ。ここで「GET」は、HTTPメソッドの一つで、ファイルの伝送を要求するものである。次の「/dir/document.html」は伝送要求する文書名で、サーバー上の論理的なパス名で指定する（物理的なパス名と一致するとは限らない）。最後の「HTTP/1.0」は利用するHTTPプロトコルのバージョンを指定している。この要求を受信した相手先のWebサーバーは、「HTTP/1.0 200 OK」のような行（レスポンス行）を含むHTTPレスポンスを返す。ここで、「HTTP/1.0」は、HTTPプロトコルのバージョン、「200」はステータス番号で200は正常の意味である。異常の場合は200番以外の数値が返る。「OK」は、補足メッセージで、エラー時には付加的な情報を返す。要求された文書データは、HTTPレスポンスのHTTPボディ部で伝送される。ヘッダ部とボディ部の区切りは、空行1行で指定される。

WebページにアクセスするにはURL（いわゆるアドレス）が必要であり、URLの先頭には一律「http(s)」をつける必要がある。WebブラウザによってはURL表示欄（アドレスバー）上に特に「http(s)」が表示されない場合も多いが、これは単に表示が省略されているだけである。

通信方式のほかの用語一覧

TCP/IP：

finger  FTP  FYI  HTTP  HTTPS  パッシブモード  ホストアドレス

>>TCP/IPカテゴリの他の用語

PHP関数リファレンス

HTTP

この HTTP 拡張モジュールの狙いは、PHP アプリケーションのために便利で強力な機能を提供することです。
HTTP の URL、日付、リダイレクト、ヘッダおよびメッセージを 使いやすくし、クライアントの希望する言語および文字セットの ネゴシエーション手段を提供します。 また、任意のデータを送信する際にキャッシュやリジュームの機能を もたせることができます。
CURL サポート込みでビルドされている場合は、 強力なリクエスト機能を提供します。PHP 5 以降では、 複数のリクエストを平行して実行することができます。
このマニュアルでは、API リファレンスに加えて インストールや設定の方法、定義済みのグローバル定数などを 以下の節で説明しています。

インストール

設定

グローバル定数

目次

インストール — HTTP 拡張モジュールのインストールおよび設定

設定 — http モジュールの設定ディレクティブ

定数 — 定義済みの http モジュールの定数

HttpMessage — HTTP メッセージクラス

HttpMessage::__construct — HttpMessage のコンストラクタ

HttpMessage::fromString — 文字列から HttpMessage を作成する

HttpMessage::toString — 文字列表現を取得する

HttpMessage::toMessageTypeObject — メッセージの型に応じた HTTP オブジェクトを作成する

HttpMessage::guessContentType — content type を推測する

HttpMessage::detach — HttpMessage をデタッチする

HttpMessage::prepend — メッセージを先頭に追加する

HttpMessage::reverse — メッセージチェインを逆順にする

HttpMessage::send — メッセージを送信する

HttpMessage::getParentMessage — 親メッセージを取得する

HttpMessage::getType — メッセージの型を取得する

HttpMessage::setType — メッセージの型を設定する

HttpMessage::getHttpVersion — HTTP バージョンを取得する

HttpMessage::setHttpVersion — HTTP バージョンを設定する

HttpMessage::getHeaders — メッセージのヘッダを取得する

HttpMessage::getHeader — ヘッダを取得する

HttpMessage::addHeaders — ヘッダを追加する

HttpMessage::setHeaders — ヘッダを設定する

HttpMessage::getBody — メッセージの本文を取得する

HttpMessage::setBody — メッセージの本文を設定する

HttpMessage::getRequestMethod — リクエストメソッドを取得する

HttpMessage::setRequestMethod — リクエストメソッドを設定する

HttpMessage::getRequestUrl — リクエスト URL を取得する

HttpMessage::setRequestUrl — リクエスト URL を設定する

HttpMessage::getResponseCode — レスポンスコードを取得する

HttpMessage::setResponseCode — レスポンスコードを設定する

HttpMessage::getResponseStatus — レスポンスのステータスを取得する

HttpMessage::setResponseStatus — レスポンスのステータスを設定する

HttpQueryString — HTTP クエリ文字列クラス

HttpQueryString::__construct — HttpQueryString のコンストラクタ

HttpQueryString::singleton — HttpQueryString のシングルトン

HttpQueryString::get — クエリ文字列 (の一部) を取得する

HttpQueryString::mod — クエリ文字列の複製を変更する

HttpQueryString::set — クエリ文字列パラメータを設定する

HttpQueryString::toArray — クエリ文字列を配列で取得する

HttpQueryString::toString — クエリ文字列を取得する

HttpQueryString::xlate — クエリ文字列の文字セットを変更する

HttpDeflateStream — HTTP 圧縮ストリームクラス

HttpDeflateStream::__construct — HttpDeflateStream クラスのコンストラクタ

HttpDeflateStream::update — 圧縮ストリームを更新する

HttpDeflateStream::flush — 圧縮ストリームをフラッシュする

HttpDeflateStream::finish — 圧縮ストリームを終了する

HttpInflateStream — HTTP 展開ストリーム

HttpInflateStream::__construct — HttpInflateStream クラスのコンストラクタ

HttpInflateStream::update — 展開ストリームを更新する

HttpInflateStream::flush — 展開ストリームをフラッシュする

HttpInflateStream::finish — 展開ストリームを終了する

HttpRequest — HTTP リクエストクラス

HttpRequest::addCookies — クッキーを追加する

HttpRequest::addHeaders — ヘッダを追加する

HttpRequest::addPostFields — POST フィールドを追加する

HttpRequest::addPostFile — POST ファイルを追加する

HttpRequest::addPutData — PUT データを追加する

HttpRequest::addQueryData — クエリデータを追加する

HttpRequest::addRawPostData — 生の POST データを追加する

HttpRequest::addSslOptions — SSL オプションを追加する

HttpRequest::clearHistory — 履歴を消去する

HttpRequest::__construct — HttpRequest のコンストラクタ

HttpRequest::enableCookies — クッキーを有効にする

HttpRequest::getContentType — content type を取得する

HttpRequest::getCookies — クッキーを取得する

HttpRequest::getHeaders — ヘッダを取得する

HttpRequest::getHistory — 履歴を取得する

HttpRequest::getMethod — メソッドを取得する

HttpRequest::getOptions — オプションを取得する

HttpRequest::getPostFields — POST フィールドを取得する

HttpRequest::getPostFiles — POST ファイルを取得する

HttpRequest::getPutData — PUT データを取得する

HttpRequest::getPutFile — PUT ファイルを取得する

HttpRequest::getQueryData — クエリデータを取得する

HttpRequest::getRawPostData — 生の POST データを取得する

HttpRequest::getRawRequestMessage — 名前のリクエストメッセージを取得する

HttpRequest::getRawResponseMessage — 生のレスポンスメッセージを取得する

HttpRequest::getRequestMessage — リクエストメッセージを取得する

HttpRequest::getResponseBody — レスポンスの本文を取得する

HttpRequest::getResponseCode — レスポンスコードを取得する

HttpRequest::getResponseCookies — レスポンスのクッキーを取得する

HttpRequest::getResponseData — レスポンスデータを取得する

HttpRequest::getResponseHeader — レスポンスヘッダを取得する

HttpRequest::getResponseInfo — レスポンスの情報を取得する

HttpRequest::getResponseMessage — レスポンスメッセージを取得する

HttpRequest::getResponseStatus — レスポンスのステータスを取得する

HttpRequest::getSslOptions — ssl オプションを取得する

HttpRequest::getUrl — url を取得する

HttpRequest::resetCookies — クッキーをリセットする

HttpRequest::send — リクエストを送信する

HttpRequest::setContentType — content type を設定する

HttpRequest::setCookies — クッキーを設定する

HttpRequest::setHeaders — ヘッダを設定する

HttpRequest::setMethod — メソッドを設定する

HttpRequest::setOptions — オプションを設定する

HttpRequest::setPostFields — POST フィールドを設定する

HttpRequest::setPostFiles — POST ファイルを設定する

HttpRequest::setPutData — PUT データを設定する

HttpRequest::setPutFile — PUT ファイルを設定する

HttpRequest::setQueryData — クエリデータを設定する

HttpRequest::setRawPostData — 生の POST データを設定する

HttpRequest::setSslOptions — SSL オプションを設定する

HttpRequest::setUrl — URL を設定する

HttpRequestPool — HTTP リクエストプールクラス

HttpRequestPool::attach — HttpRequest をアタッチする

HttpRequestPool::__construct — HttpRequestPool のコンストラクタ

HttpRequestPool::__destruct — HttpRequestPool のデストラクタ

HttpRequestPool::detach — HttpRequest をデタッチする

HttpRequestPool::getAttachedRequests — アタッチされているリクエストを取得する

HttpRequestPool::getFinishedRequests — 終了したリクエストを取得する

HttpRequestPool::reset — リクエストプールをリセットする

HttpRequestPool::send — すべてのリクエストを送信する

HttpRequestPool::socketPerform — ソケットアクションを実行する

HttpRequestPool::socketSelect — ソケットの選択を実行する

HttpResponse — HTTP レスポンスクラス

HttpResponse::capture — スクリプトの出力を取り込む

HttpResponse::getBufferSize — バッファサイズを取得する

HttpResponse::getCacheControl — cache control を取得する

HttpResponse::getCache — キャッシュを取得する

HttpResponse::getContentDisposition — content disposition を取得する

HttpResponse::getContentType — content type を取得する

HttpResponse::getData — データを取得する

HttpResponse::getETag — ETag を取得する

HttpResponse::getFile — ファイルを取得する

HttpResponse::getGzip — gzip を取得する

HttpResponse::getHeader — ヘッダを取得する

HttpResponse::getLastModified — 最終更新日時を取得する

HttpResponse::getStream — ストリームを取得する

HttpResponse::getThrottleDelay — throttle delay を取得する

HttpResponse::guessContentType — content type を推測する

HttpResponse::send — レスポンスを送信する

HttpResponse::setBufferSize — バッファサイズを設定する

HttpResponse::setCacheControl — cache control を設定する

HttpResponse::setCache — キャッシュを設定する

HttpResponse::setContentDisposition — content disposition を設定する

HttpResponse::setContentType — content type を設定する

HttpResponse::setData — データを設定する

HttpResponse::setETag — ETag を設定する

HttpResponse::setFile — ファイルを設定する

HttpResponse::setGzip — gzip を設定する

HttpResponse::setHeader — ヘッダを設定する

HttpResponse::setLastModified — 最終更新日時を設定する

HttpResponse::setStream — ストリームを設定する

HttpResponse::setThrottleDelay — throttle delay を設定する

http_cache_etag — ETag でキャッシュする

http_cache_last_modified — 最終更新日時でキャッシュする

http_chunked_decode — chunked-encoded データをデコードする

http_deflate — データを圧縮する

http_inflate — データを展開する

http_get_request_body_stream — リクエストの本文をストリームとして取得する

http_get_request_body — リクエストの本文を文字列として取得する

http_get_request_headers — リクエストヘッダを配列として取得する

http_date — HTTP の RFC に準拠した日付を作成する

http_support — 組み込みの HTTP サポートを調べる

http_match_etag — ETag を比較する

http_match_modified — 最終更新日時を比較する

http_match_request_header — 任意のヘッダを比較する

http_build_cookie — クッキー文字列を作成する

http_negotiate_charset — クライアントが希望している文字セットを選択する

http_negotiate_ctype — クライアントが希望している content type を選択する

http_negotiate_language — クライアントが希望している言語を選択する

ob_deflatehandler — 圧縮出力ハンドラ

ob_etaghandler — ETag 出力ハンドラ

ob_inflatehandler — 展開出力ハンドラ

http_parse_cookie — HTTP クッキーをパースする

http_parse_headers — HTTP ヘッダをパースする

http_parse_message — HTTP メッセージをパースする

http_parse_params — パラメータリストをパースする

http_get — GET リクエストを実行する

http_head — HEAD リクエストを実行する

http_post_data — エンコードされたデータを使用して POST リクエストを実行する

http_post_fields — エンコードされる前のデータを使用して POST リクエストを実行する

http_put_data — データを使用して PUT リクエストを実行する

http_put_file — ファイルを使用して PUT リクエストを実行する

http_put_stream — ストリームを使用して PUT リクエストを実行する

http_request_method_exists — リクエストメソッドが存在するかどうかを調べる

http_request_method_name — リクエストメソッド名を取得する

http_request_method_register — リクエストメソッドを登録する

http_request_method_unregister — リクエストメソッドの登録を解除する

http_request — 独自のリクエストを実行する

http_request_body_encode — リクエスト本文をエンコードする

http_redirect — HTTP リダイレクトを発行する

http_send_content_disposition — Content-Disposition を送信する

http_send_content_type — Content-Type を送信する

http_send_data — 任意のデータを送信する

http_send_file — ファイルを送信する

http_send_last_modified — Last-Modified を送信する

http_send_status — ステータスを送信する

http_send_stream — ストリームを送信する

http_throttle — HTTP 抑止処理

http_build_str — クエリ文字列を組み立てる

http_build_url — URL を組み立てる

ウィキペディア

HTTP

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2025/05/17 18:18 UTC 版)

HTTP

通信プロトコル
目的	ハイパーテキストなどの転送
開発者	ティム・バーナーズ＝リー Internet Engineering Task Force (IETF) World Wide Web Consortium (W3C)
導入	1991年 (34年前) (1991)
派生先	HTTP/2、HTTP/3、WebDAV
OSI階層	アプリケーション層
ポート	80
RFC	共通: RFC 9110, RFC 9111 HTTP/1.1: RFC 9112 HTTP/2: RFC 9113 HTTP/3: RFC 9114

HTTP
主要項目
持続的接続 圧縮（英語版） HTTPS HTTP/2 HTTP/3
リクエストメソッド
OPTIONS GET HEAD POST（英語版） PUT DELETE TRACE CONNECT PATCH（英語版）
ヘッダーフィールド（英語版）
Cookie ETag Location（英語版） リファラ DNT（英語版） X-Forwarded-For
ステータスコード
301 Moved Permanently（英語版） 302 Found 303 See Other（英語版） 403 Forbidden 404 Not Found 503 Service Unavailable
認証方式
Basic認証 Digest認証
セキュリティホール
HTTPヘッダ・インジェクション HTTPリクエストスマグリング（英語版） HTTPレスポンス分割（英語版） HTTPパラメータ汚染（英語版）
表 話 編 歴

TCP/IP群
アプリケーション層
BGP DHCP DNS FTP HTTP IMAP IRC LDAP MGCP MQTT NNTP NTP SNTP TIME POP RIP OSPF ONC RPC RTP SIP SMTP SNMP SSH Telnet TFTP TLS/SSL XMPP カテゴリ
トランスポート層
TCP UDP DCCP SCTP RSVP QUIC カテゴリ
インターネット層
IP IPv4 IPv6 ICMP ICMPv6 NDP IGMP IPsec カテゴリ
リンク層
ARP SPB トンネリング L2TP PPP MAC イーサネット IEEE 802.11 DSL ISDN カテゴリ
表 話 編 歴

HTTP（Hypertext Transfer Protocol、ハイパーテキスト・トランスファー・プロトコル）はアプリ間コネクション上のリクエスト/レスポンス型・ステートレス・メッセージ指向通信プロトコルである^[1]。

概要

TCPやQUICはアプリケーション間のコネクション型通信を提供する。HTTPはこのコネクション上を、リソース要望と返答が、メッセージ単位で、1往復のクライアントリクエスト&サーバーレスポンスという形で通信される、と定めたプロトコルである^[1]。

HTTPの発明により、インターネット上でのリソース公開とアクセスが容易になった。クライアントがサーバーとコネクションを確立し1つのHTTPメッセージを書いて送るだけで、サーバー上のリソースがHTTPメッセージとして帰ってくる。ゆえにHTTPで公開されるあらゆるリソースにHTTPという単一の手法でアクセスできるようになった。

HTTPを開発した理由でありかつ現在も広く利用される用途はWorld Wide Webである。WebサーバとWebブラウザはHTTPで主に通信しており、ブラウザからのHTTPメッセージに応答してサーバーがHTMLテキストやJavaScriptコードを送り返し、これをブラウザで表示することでウェブが成立している。

またHTTPはメッセージ形式を定める。基本的な考え方は単純で「何を」「どうして」欲しいのかを伝える。例えばリクエストメッセージ GET /apple.jpg は「apple.jpg 画像を、手に入れたい」を意味する。URLが「何を」に、メソッドが「どうして」に当たる。

World Wide WebにおけるWebページなどのリソースは、Uniform Resource Identifierによって指定される。HTTP を使用してリソースにアクセスするときは、http: が先頭についた URL を使用する。下にURL の例を挙げる。

http://www.example.co.jp/~test/samples/index.html

最初の HTTP/0.9 ではURLを指定してコンテンツをダウンロードするのみの簡単なやりとりだったが、HTTP/1.0 で改良された。

• 様々なリクエストメソッドが追加された。POSTを使って、アップロード（クライアントからサーバへのデータの転送）が可能になった。
• NNTPやSMTPのような各種ヘッダが定義され、HTTP cookieなどの利用が可能になった。

HTTP/1.1 では複数データを効率よく転送するための持続的接続や、プロキシの利用なども想定した仕様になった。さらに HTTP/2やHTTP/3が策定された。現在ではHTTPセマンティクスと各バージョンの手続きが分離して定義されている（#規格を参照）。

このほかの点を箇条書きで示す。

• TCPのポート番号80をデフォルトとして使用する（HTTP/0.9〜1.1とHTTP/2の場合）。
• TLSで暗号化され、セキュリティを確保したHTTPは、HTTPSと呼ばれる（httpsは実際にはURIスキームの1つであり、実際のプロトコルにはHTTP over SSL/TLSまたはHTTP/3が用いられる）。
• HTTP は基本的にサーバが状態を保持しない (stateless) プロトコルだが、データベースなどを使用するWebアプリケーションにおいては状態保持が必要だったため、いわゆる Cookie（クッキー）とよばれる機構が Netscape Communications Corporation によって導入された。Cookie を使用することによって状態を管理し、セッションを維持することが可能になる。
• 行末文字はCRLFで、インターネット・プロトコル・スイートにおいてアプリケーション層に属する他の多くのプロトコルと同じである（HTTP/0.9〜1.1の場合）。

歴史

イギリスの物理学者ティム・バーナーズ＝リーは1990年末、ロバート・カイリューと共に初のWebブラウザとWebサーバを作成した。ブラウザには通信をするためのプロトコルが必要だったので、二人はHTTPの最初期のバージョンを設計した。

以来インターネットの大部分をHTTP通信が占めるようになり、1998年にはインターネット上の通信の75%がHTTPによるものになった。

最初期のHTTP/0.9の仕様書は紙に印刷すれば1枚で済むような非常に簡素なドキュメントだったが、2度のバージョンアップを経たHTTP/1.1の仕様書は実に176ページ近くの分量に膨れあがった。

HTTP/0.9

1991年に最初にドキュメント化されたバージョン^[2]。メソッドは GET しかなかった。レスポンスは単純にドキュメントの内容を返してコネクションを切断するだけで、レスポンスコードの規定もない。下記は、HTTP/0.9 のリクエストの例。

GET /index.html

HTTP/1.0

1996年5月に RFC 1945 として発表された。仕様が RFC で扱われるようになった。メソッドに POST など GET 以外のものが増えた。レスポンスはヘッダーがつくようになり、ステータスコードを含めるようになった。HTTP/0.9 と区別するため、リクエストプロトコルにバージョンを含めることになった。

HTTP/1.0のリクエスト

GET /index.html HTTP/1.0

HTTP/1.1

1997年1月に RFC 2068 として初版が発表された。その後、3回改訂され、現在はセマンティクス・キャッシングを除く部分がRFC 9112で規定されている。

名前ベースバーチャルホストのため、Hostヘッダーフィールドの規定が追加された。

HTTP/1.1のリクエスト

GET /index.html HTTP/1.1
Host: foo.example.com

HTTP/2

→詳細は「HTTP/2」を参照

HTTP/2の目標はHTTP/1.1のトランザクション・セマンティクスとの完全な後方互換性を維持したまま非同期な接続の多重化、ヘッダ圧縮、リクエストとレスポンスのパイプライン化を実現することである。Googleによって立ち上げられ^[3]、GoogleのブラウザーであるChromeだけではなく、他にも、Opera、Firefox、Amazon Silkなどが対応しているHTTP互換のプロトコルSPDYの人気が高まっていることに対応するために開発された^[4]。

HTTP/3

→詳細は「HTTP/3」を参照

HTTP-over-QUIC（hq）としてIETFが開発していた新たな通信プロトコルが、HTTP/3へと改名される。^[5] IETFが策定を進めているQUICはトランスポート層におけるプロトコルの名称であり、アプリケーション層プロトコルであるHTTP-over-QUICとの区別を明確にするため、このような名称変更に至った。^[6]

HTTP/2と比べ、多重化するストリームの取り扱いが下位層のQUICへ移行したこと^[7]、ヘッドオブラインブロッキング（英語版）を回避するためのヘッダ圧縮の変更（HTTP/3用にQPACKが開発されている）^[8]などの差異がある。

→Googleが試験的に開発していたプロトコルについては「QUIC」を参照

動作

通信の開始

他のプロトコル同様、クライアント側とサーバ側では役割が大きく異なる。HTTP通信を開始できるのはクライアント側のみである。

クライアント側がサーバにリクエストを送り、サーバがクライアントにレスポンスを返すのが最も典型的なHTTPのやりとりである。

接続

システム間でメッセージをやりとりするには接続を確立させる必要がある。HTTP/0.9～HTTP/1.1およびHTTP/2ではTCPを使用する。

HTTP/0.9ではクライアントのリクエストごとにTCP接続を確立させる必要があった。これは当時のWebサイトがシンプルなテキストベースであることが多かったためである。近年ではJavaScriptやアニメーション画像など、多数のオブジェクトが埋め込まれたWebサイトが一般的となってきており、これらのオブジェクトを取得するたびにTCP接続を確立するのはサーバやネットワークに大きな負担を強いるため、1回のTCP接続で、複数のHTTPリクエスト・レスポンスをやり取りする持続的接続がHTTP/1.0の拡張として導入された。その後、HTTP/1.1では、持続的接続がデフォルトとなった。すなわち、何も指定しなければ持続的接続となり、持続的接続を望まなければヘッダーフィールドにConnection: closeを追加する仕様となっている。

→詳細は「HTTPの持続的接続」を参照

パイプライン

クライアントは前のリクエストに対するサーバの応答を待たずに別のリクエストを発行できる。

→詳細は「HTTPパイプライン」を参照

リクエストメソッド

HTTPでは8つのメソッドが定義されている。ただし、実際のHTTP通信ではGETとPOSTメソッドが大部分を占める。

→「en:Request method」も参照

HTTPメソッドの一覧

メソッド	HTTP/0.9	HTTP/1.0	HTTP/1.1
GET	○	○	○
POST		○	○
PUT		△	○
HEAD		○	○
DELETE		△	○
OPTIONS			○
TRACE			○
CONNECT			○

GET

指定されたURIのリソースを取り出す。HTTPの最も基本的な動作で、HTTP/0.9では唯一のメソッド。

POST

→「POST (HTTP)（英語版）」も参照

GETとは反対にクライアントがサーバにデータを送信する。Webフォームや電子掲示板への投稿などで使用される。GETの場合と同じく、サーバはクライアントにデータを返すことができる。

PUT

指定したURIにリソースを保存する。URIが指し示すリソースが存在しない場合は、サーバはそのURIにリソースを作成する。画像のアップロードなどが代表的。

DELETE

指定したURIのリソースを削除する。

OPTIONS

サーバを調査する。例えば、サーバがサポートしているHTTPバージョンなどを知ることができる。

HEAD

GETと似ているが、サーバはHTTPヘッダのみ返す。クライアントはWebページを取得せずともそのWebページが存在するかどうかを知ることができる。例えばWebページのリンク先が生きているか、データを全て取得することなく検証することができる。

TRACE

サーバまでのネットワーク経路をチェックする。サーバは受け取ったメッセージのそれ自体をレスポンスのデータにコピーして応答する。WindowsのTracertやUNIXのTracerouteとよく似た動作。

CONNECT

TCPトンネルを接続する。暗号化したメッセージをプロキシサーバを経由して転送する際に用いる。当初、ネットスケープコミュニケーションズによって考案されたものがIETFドラフトTunneling TCP based protocols through Web proxy serversとして公開され^[9]、RFC 2817 に取り込まれた。その後、RFC 7230 で定義が更新されている^[10]。

HTTPの仕様以外で定義しているメソッドは、IANAのHypertext Transfer Protocol (HTTP) Method Registry^[11]で管理されている。WebDavで使用するものや、 RFC 5789 のPATCHメソッド（英語版）などがある。

サーバの連携

バーチャルホスト

1つのサーバーで複数のホスト名に対するHTTPリクエストを受け付ける機能である。

インターネット人気に伴い多くの企業がWebサイトを持ち始めたが、当時はまだまだ企業が自前のWebサーバを運用するのは人員、効率の問題で難しく、ISPのサーバでホスティングをしていた。また、1社ごとに専用サーバを用意するほどのことでもないため、1台のサーバで複数のWebサイトを運用していた。

しかし、IPアドレスのみで相手を特定するHTTP/1.0はこれに対応できなかった。例えば、ある1台のサーバに foo.example.com と bar.example.com という2つの仮想Webサーバがあり、クライアントは http://foo.example.com/index.html にアクセスしたいとする。この場合はDNSサーバに foo.example.com のIPアドレスを問い合わせ、次にそのIPアドレスを使って該当サーバにアクセスし、GET index.html を要求することになる。しかし同じサーバ上にある bar.example.comもIPアドレスは同じであり、もし両方の仮想サーバに index.html というファイルが存在すれば、クライアントがどちらにアクセスしようとしているのか、判別できない。

対策としてはそれぞれにIPアドレスを付与する方法もあるが、IPv4の資源を無駄にすることになる。この問題を解決するため、HTTP/1.1でHostヘッダーフィールドが追加され、名前ベースバーチャルホストが用いられるようになった。

名前ベースバーチャルホストのため、以下のようにHTTPリクエストでホスト名を指定する。

• HTTP/1.1: Hostヘッダーフィールドでホスト名を指定する。
• HTTP/2およびHTTP/3: :authority疑似ヘッダーフィールドでホスト名を指定する。

リダイレクト

→「リダイレクト (HTTP) § HTTPリダイレクト」も参照

別のURIに対して再度のメソッド実行を要求する機能である。301 Movedや303 See Otherなどのリダイレクトを指示するステータスコードとURIを受け取り、クライアントはこのURIに再度メソッドを実行する。

クッキー

→詳細は「HTTP cookie」を参照

HTTPメッセージ

リクエストとレスポンスでやり取りされるデータは、HTTPメッセージと呼ばれる。クライアントからリクエストHTTPメッセージを送り、サーバーからレスポンスHTTPメッセージを返す。

HTTPメッセージは以下で構成される^[12]。

• コントロールデータ
• ヘッダー
• コンテント
• トレイラー

なおHTTP/1.1では、コントロールデータをリクエスト行・ステータス行として表現し、コンテントを格納する部分をメッセージボディまたは単にボディと呼ぶ。

ヘッダー・コンテント・トレイラーは空となる場合もある。

下にもっとも単純なクライアントとサーバ(www.google.co.jp:80)とのやり取りの例を挙げる。

クライアントのリクエスト:

GET / HTTP/1.1
Host: www.google.co.jp

この例では、リクエスト行とヘッダーにフィールドが1項目あるのみで、ボディは空でトレーラーも無い。 リクエスト行はメソッド、リクエストターゲット、HTTPバージョンの3つの要素から構成され、それぞれスペースで区切られる。 メソッドはGET、リクエストターゲットは「/」、HTTPバージョンは1.1である。

GETはリソースを取得するためのメソッドであり、リクエストターゲットの「/」はURIのパス部分であってルートリソースを対象にしたリクエストであることを示している。

サーバのレスポンス:

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html
Set-Cookie: PREF=ID=72c1ca72230dea65:LD=ja:TM=1113132863:LM=1113132863:S=nNO7MIp
W2o7Cqeu_; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.co.jp
Server: GWS/2.1
Date: Sun, 10 Apr 2005 11:34:23 GMT
Connection: Close

<html><head><meta http-equiv="content-type" content="text/html; charset=Shift_JI
 S"><title>Google</title><style><!-- 
……以下省略 -->

先頭のステータス行はHTTPバージョン、ステータスコード、ステータスメッセージから構成される。 ステータスコードの「200」は処理の成功を表し、これを補足するメッセージが「OK」である。

2行目以降にヘッダフィールドが続く。 さらに空行を挟んで、レスポンスボディとなる。 このレスポンスにもトレーラーは無い。

HTTPヘッダフィールド

ヘッダの各要素は

フィールド名: 内容

のペアで構成される。

ブラウザの情報を表すUser-Agent、使用候補言語を表すAccept-Language、他ページへのリンクを辿った場合にそのリンク元ページのURLを表すRefererなどが代表的なフィールドである。

なお、リクエスト時のHostヘッダはHTTP/1.1では必須であるが、HTTP/1.0ではなくてもよい。 ただし、サーバがバーチャルホストを利用している場合は、Hostヘッダがないとリソース取得に失敗するので、たとえHTTP/1.0を使用していてもHostヘッダを付加しなければならない。

HTTPヘッダフィールドの一覧

リクエストヘッダ

ヘッダ	概要	HTTP/0.9	HTTP/1.0	HTTP/1.1
Accept	クライアントの受け入れ可能コンテンツタイプを示す		○	○
Accept-Charset	クライアントの受け入れ可能文字セットを示す		○	○
Accept-Encoding	クライアントの受け入れ可能文字エンコーディングを示す		○	○
Accept-Language	クライアントの受け入れ可能言語を示す		○	○
Authorization	クライアントの認証情報を示す		○	○
Cookie	クライアントの状態管理情報をサーバに返す
Cookie2	HTTP/1.1のSet-Cookie2ヘッダの受け入れ可能をサーバに知らせる
Expect	クライアントがサーバに期待する動作を示す			○
From	リクエスト発行者個人の情報を示す。一般的に電子メールアドレスを使用する		○	○
Host	要求しているオブジェクトがあるホストを示す			○
If-Match	if文を用い条件が真の場合のみリクエストを処理するようサーバに要求する			○
If-None-Match	If-Matchの逆で条件が真でない場合のみリクエストを処理する要求			○
If-Range	条件が真の場合のみ指定したオブジェクトの範囲を返すようサーバに要求する			○
If-Modified-Since	指定日時以降にオブジェクトが変更されている場合のみリクエストを処理するよう要求する		○	○
If-Unmodified-Since	If-Modified-Sinceの逆で真でないときのみ実行する			○
Max-Forwards	リクエストの中間システム経由数を最大いくつまでかを指定する			○
Proxy-Authorization	クライアントがプロキシサーバに対して自身の認証を行う			○
Range	オブジェクト全体でなくリソースの一部を要求する			○
Referer	リクエストの出所を示す。一般的にはユーザの辿ったWebページのURLが用いられる		○	○
TE	レスポンスの受け入れ可能転送エンコーディングを示す			○
User-Agent	クライアントのWebブラウザなどの情報を示す		○	○

レスポンスヘッダ

ヘッダ	概要	HTTP/0.9	HTTP/1.0	HTTP/1.1
Accept-Ranges	オブジェクトの一部に対するリクエストをサーバが受け入れ可能か示す			○
Age	オブジェクトの経過時間を秒単位で返す			○
ETag	オブジェクトのエンティティタグ値を示す			○
Location	オブジェクトの場所を示す		○	○
Proxy-Authenticate	プロキシサーバがクライアントに認証を要求するときに用いる			○
Retry-After	リクエストの再試行をいつ行うかをクライアントに通知する		○	○
Server	サーバのベンダー名、バージョン番号を示す		○	○
Set-Cookie2	サーバがクライアントにCookieを送信するときに用いる
Vary	サーバがレスポンス内容を決定する際にリクエストURI以外に用いたヘッダのリストを示す			○
WWW-Authenticate	クライアントに対してリクエストの再発行を要求する。認証情報も含まれる		○	○

一般ヘッダ

ヘッダ	概要	HTTP/0.9	HTTP/1.0	HTTP/1.1
Cache-Control	メッセージの経由する中間キャッシュの動作を指示する			○
Connection	当該の接続に対するオプションを指示する			○
Date	メッセージの作成日時を示す		○	○
Pragma	メッセージに関する追加情報を示す		○	○
Trailer	メッセージボディの後に追加のヘッダーが表れることを示す			○
Transfer-Encoding	クライアントの転送を目的としたオブジェクトのエンコーディングを示す			○
Upgrade	通信相手に別のプロトコルにアップデートするよう要求する			○
Via	プロキシサーバなど中継地点を示す。			○
Warning	メッセージに関する追加情報を示す。通常はキャッシュの問題を警告するときに使われる			○

エンティティヘッダ

ヘッダ	概要	HTTP/0.9	HTTP/1.0	HTTP/1.1
Allow	オブジェクトがサポートするHTTPメソッドを示す		○	○
Content-Encoding	オブジェクトのエンコーディングを示す		○	○
Content-Language	オブジェクトの言語（人間の言語）を示す		○	○
Content-Length	オブジェクトのサイズをバイト単位で示す		○	○
Content-Location	オブジェクトの場所を示す			○
Content-MD5	オブジェクトのメッセージダイジェストを運ぶ			△
Content-Range	メッセージボディで運ばれるオブジェクトの範囲を示す			○
Content-Type	オブジェクトのタイプを示す		○	○
Expires	オブジェクトの有効期限の日時を示す		○	○
Last-Modified	オブジェクトが最後に変更された日時を示す		○	○

Accept

サーバのレスポンスに含まれるメッセージボディで受け入れることが出来るコンテンツタイプと各コンテンツタイプの相対的な優先度を指定するリクエストヘッダ。指定できるコンテンツタイプはIANAによって定義されている。

Accept: text/plain; q=0.5, text/html,
	text/x-dvi; q=0.8, text/x-c

上記のようにAcceptヘッダには行をわけて複数のコンテンツタイプを指定できる。上記の例はいずれの4のコンテンツタイプのいずれも受け入れ可能であることを示す。0.5や0.8といった数字は品質係数で0〜1の範囲の数値である。数値の指定がなければ1.0となる。

• text/plain; q=0.5
• text/html
• text/x-dvi; q=0.8
• text/x-c

Accept-Charset

レスポンスで返されるメッセージボディの文字コードを指定するリクエストヘッダ。Acceptと同じく複数指定でき品質係数も設定できる。定義済み文字セットはIANAが管理している。

Accept-Charset: UTF-8, *; q=0.8

この例だとクライアントはUTF-8を優先的に希望しているが他の文字セットとの相対優先度0.8で受け入れている。ただしサーバからのレスポンスのHTTPヘッダそのものの文字コードは常にISO-8859-1である。

Accept-Encoding

クライアントが受信できるメッセージボディのエンコーディングを指定する。

Accept-Encoding: gzip, deflate

この例ではクライアントはgzip、またはzlibフォーマットに対応している。ただし必ずしもここで指定されたエンコーディングでメッセージボディが返ってくるとは限らない。

Accept-Encodingで指定可能なエンコーディングは、IANAがHTTP Content Coding Registryとして管理されている^[13]。

Accept-Language

レスポンスの言語（人間の言語）に対する優先度を指定する。言語の指定にはIETF言語タグを用いる。書き方は他のAccept-群と変わらず。

Accept-Language: en-gb, en; q=0.8

上記の例はまずイギリス英語を要求し、利用できない場合はその他の英語を要求する。

Accept-Ranges

Acceptで始まる他のヘッダフィールドと違いレスポンスヘッダである。現在の仕様では2つの指定方法しかない。

Age

リソースの推定経過時間を表示するレスポンスヘッダ。キャッシュサーバーはAgeヘッダの値からキャッシュしたリソースが有効かどうかを判定する。

Allow

Authentication-info

ユーザ認証のやりとりの最後で用いられる、成功したレスポンスのサーバが含めることの出来るレスポンスヘッダ。

Authorization

サーバに対するクライアント自身の認証を行うことが出来る。

Cache-Control

キャッシングの動作を指定するためのマスターヘッダ。

Connection

接続に対するオプションを指定する。その値には以下が使用される。

keep-alive

持続的接続を行う。

close

持続的接続を行わない。

upgrade

他のプロトコルへのアップグレードを希望する。

Content-Encoding

Content-Language

リソースの表現に用いられる言語の明示に使われる。言語の指定はAccept-Languageヘッダと同じ。

Content-Length

Content-Location

Content-MD5

メッセージボディが変更されず宛先に届いたことの保証に用いる。MD5によるハッシュ値をヘッダー値に記載する。ただし悪意の改ざんに対しては当然MD5も改ざんされるのであまり機能はしない。どちらかといえば偶発的な変化が生じていないことの保証をしている^[14]。RFC 7231で廃止された^[15]。

Content-Range

ダウンロードの再開に用いられる。

Content-Type

→「メディアタイプ」も参照

メッセージボディに含まれるオブジェクトタイプを示す。次の例はリソースがテキストファイル、文字セットはISO-8859-4を使用していることを示している。

Content-Type: text/plain; Charset=ISO-8859-4

Cookie

→詳細は「HTTP cookie」を参照

クライアントがHTTP状態管理を望む場合にサーバから受け取ったクッキーを以後のリクエストに次の例のようなヘッダを付加する。

Cookie: $Version="1"; NAME="VALUE";
        $Path="/shopping"; $domain="www.shop.com"+
        $Port="80"

$VersionはHTTPのバージョン、NAMEはクッキーの名前である。$から始まるクッキー名は使用が禁止されている。

Cookie2

基本的にCookieヘッダとCookie2ヘッダは別物である。

Date

サーバがメッセージを生成した日時を示す。リソースの更新日時を示すLast-Modifiedヘッダとは別である。

HTTP/1.1では次のような形式を用いる。これはRFC 7231の7.1.1.1. Date/Time Formatsで定義されている。HTTP/1.1の以前の版であるRFC 2616では、日時の形式の定義にRFC 1123を参照していた（内容は同等である）。

Date: Sun, 06, Nov 1994 08:49:37 GMT

HTTP仕様ではレスポンスにDateヘッダを含めることを求めている。ただしレスポンスのステータスがサーバエラーの場合にはDateヘッダは返らない。

ETag

主にキャッシングのパフォーマンスを向上する目的で使われる。

Expect

サーバに対して特定の動作の期待を知らせる。用途としてはクライアントがサーバに対して100 Continueステータスを返すことを期待する場合に使われる。

Expect: 100-continue

サーバが期待に応じられない場合は417 Expectation Failedを返す。クライアントがいくつかのプロキシ経由で通信している場合、各プロキシサーバはExpectヘッダの一切の修正を許されない。

Expires

オブジェクトの有効期限を示す。このヘッダで指定された日時までキャッシュはレスポンスのコピーを保持し、リクエストに対するレスポンスとして返すことができる。サーバがオブジェクトのキャッシュを望まない場合にはExpiresヘッダに過去の日時を設定することが多い。仕様では1年以上先の日時は設定できない。

Expires: Thu, 28 Aug 2010 16:00:00 GMT

Cache-Controlヘッダのmax-ageディレクティブはExpiresヘッダより優先されるため注意が必要である。

From

リクエストを発行したユーザを特定することが出来る。1990年代では電子メールアドレスを設定することが多かったが、迷惑メールの問題もあり現在では殆ど使われていない。

From: user@example.com

Host

主にレンタルサーバのサポートを目的としてHTTP/1.1で導入された。現在ではHostヘッダを利用できない場合、レンタルサーバのWebサイトとまともな通信ができないと言ってよい（詳細はHTTP#歴史を参照）。

If-Match

ETagが一致した場合のみ、メソッドを実行するようにサーバに要求する。例えばウィキペディアを編集する際、記事のソースを取得し、書き換える際の間に別のユーザが既に編集していないかを判断するときなどに用いられる。

→「if文」も参照

1. 利用者：AがHTTPの記事を取得。ETagは1234。
2. 利用者：BがHTTPの記事を取得。ETagは1234。
3. 利用者：AがHTTPのETagを再度取得。先ほど取得したETag: 1234と現在のETag: 1234が一致。
4. 利用者：AがHTTPの記事を編集。ETagは1256になる。
5. 利用者：BがHTTPのETagを再度取得。先ほど取得したETagと現在のETagはマッチせず。
6. サーバは利用者：Bの書き込みを拒否。

If-Modified-Since

指定日時以降にオブジェクトが変更されている場合のみ、メソッドを実行するようにサーバに要求する。通信量の削減に効果がある。

If-None-Match

If-Matchの逆で、ETagが一致しない場合のみの実行を要求する。

If-Range

クライアントがキャッシュにオブジェクトの一部分を持っている場合にパフォーマンスを向上できる。

If-Unmodified-Since

If-Modified-Sinceの逆で、指定時刻以降に変更がない場合のみの実行を要求する。

Last-Modified

レスポンスでオブジェクトの最終更新日時を示す。リクエスト時のIf-Modified-Sinceヘッダと組み合わせることで、効率的な通信が可能になる。

Location

サーバがクライアントにリダイレクト先URLを知らせる際に用いられる。一般的にステータスコードが3xx代のレスポンスと共に使われるが201 Createdのレスポンスでも使うことができる。Content-Locationヘッダと名前が似ているが全く関係のない別のヘッダであるため注意。

Max-Forwards

プロキシサーバなどを経由する際の最大ホップ数を指定する。二重ループなどでサーバから応答が得られない場合の問題解決の際、OPTIONメソッドやTRACEメソッドと共に用いられる。

HTTPステータスコード

ステータスコードはサーバからのレスポンスで、リクエストの結果を通知する。3桁の数字から成り、おおまかな分類として、1xxは「情報」、2xxは「成功」、3xxは「リダイレクト」、4xxは「クライアントエラー」、5xxは「サーバエラー」を示す。

→詳細は「HTTPステータスコード」を参照

セキュリティ技術

いくつかの観点でセキュリティに関する追加機能が存在する。

HTTPS

→詳細は「HTTPS」を参照

セキュアな通信路でHTTP通信を行うことを通常HTTPSと言う。

HTTP認証

→詳細は「HTTP認証」を参照

HTTPの中で認証を行う仕組みが用意されている。

Basic認証

HTTP/1.1で定義されている最も単純なセキュリティ技術である。「基本認証を用いるくらいならなにも使わない方がまし」と主張する人もいる^[16]。平文で認証情報を送信する仕組みであるため、TLS (HTTPS)など安全を確保した通信路での利用が望ましい。通常サーバはステータスコード401で応答する。

→詳細は「Basic認証」を参照

Digest認証

→詳細は「Digest認証」を参照

規格

HTTPはIETFを始めとした標準化団体により規格化されている。以下はその一部である。

	セマンティクス	キャッシュ	手続き
HTTP/1.1	RFC 9110	RFC 9111	RFC 9112
HTTP/2			RFC 9113
HTTP/3			RFC 9114

歴史的には各バージョンが独立して規格化されてきた。しかし現行の3バージョン（v1.1, v2, v3）が共通のセマンティクスを維持していたことから、これを独立した規格とする活動が推進され現在の形になっている^[17]。

派生・拡張プロトコル

HTTPSのほか、以下のようなHTTPのセマンティクスを利用するプロトコル、HTTPの構文を元とするプロトコルなどが存在する。以下はその一例である。

• WebDAV: HTTP上でファイル転送を実現するプロトコル。
• WebSocket: 双方向通信プロトコル。
• Internet Printing Protocol (IPP): プリンタの制御と印刷データの伝送を行うプロトコル。
• UPnPでは、HTTPをUDP上で使用するHTTPUや、マルチキャストで使用するHTTPMUが規定された。
• Hyper Text Coffee Pot Control Protocol (HTCPCP): エイプリルフールのジョーク。コーヒーポットの制御機能を有するプロトコル。

なお、このようなHTTPの利用に関する文書として RFC 9205 Building Protocols with HTTP (BCP 56)が存在する。

脚注

[脚注の使い方]

1. ^ ^{a b} "The Hypertext Transfer Protocol (HTTP) is a family of stateless, application-level, request/response protocols ... HTTP is a stateless request/response protocol for exchanging 'messages' across a connection." RFC 9110.
2. ^ The HTTP Protocol As Implemented In W3
3. ^ Sebastian Anthony (2012年3月28日). “S&M vs. SPDY: Microsoft and Google battle over the future of HTTP 2.0”. ExtremeTech. 2014年9月23日閲覧。
4. ^ Jerome Louvel (2011年10月6日). “Can the rise of SPDY threaten HTTP?”. Restlet. 2014年9月23日閲覧。
5. ^ “Gigazine『UDPベースの「HTTP-over-QUIC」が新HTTPバージョン「HTTP/3」に名称変更される』”. GIGAZINE (2018年11月14日). 2018年11月14日閲覧。
6. ^ IETF Meetingの資料スライド
7. ^ “QUICの話 (QUICプロトコルの簡単なまとめ)”. ASnoKaze blog (2018年10月31日). 2019年5月12日閲覧。 “後述のストリームの管理がQUICレイヤに移り、それにあわせフレームの変更やQUICストリームの利用方法の定義”
8. ^ “QUICの話 (QUICプロトコルの簡単なまとめ)”. ASnoKaze blog (2018年10月31日). 2019年5月12日閲覧。 “ヘッドオブラインブロッキング避けるために、HPACKをQUIC用に改良したQPACKを用いる”
9. ^ “RFC 2817 Upgrading to TLS Within HTTP/1.1” (2000年5月). 2019年4月26日閲覧。 “The CONNECT method was originally described in a Work in Progress titled, "Tunneling TCP based protocols through Web proxy servers", by Ari Luotonen of Netscape Communications Corporation.”
10. ^ “RFC 7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing” (2014年6月). 2019年4月26日閲覧。 “This specification also updates the use of CONNECT to establish a tunnel, previously defined in RFC 2817, and defines the "https" URI scheme that was described informally in RFC 2818.”
11. ^ Hypertext Transfer Protocol (HTTP) Method Registry
12. ^ RFC 9110, 6. Message Abstraction
13. ^ HTTP Content Coding Registry
14. ^ “RFC 1864 The Content-MD5 Header Field” (英語). Internet Engineering Task Force (1995年10月). 2021年1月30日閲覧。 “This document specifies a data integrity service that protects data from accidental modification while in transit from the sender to the recipient.”
15. ^ “RFC 7231 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content” (英語). Internet Engineering Task Force (2014年6月). 2021年1月30日閲覧。 “The Content-MD5 header field has been removed because it was inconsistently implemented with respect to partial responses.”
16. ^ 『HTTPプロトコル―セキュア&スケーラブルなWeb開発』 Stephen Thomas 著、葛西 重夫 訳、ソフトバンクパブリッシング^{[要ページ番号]}
17. ^ “JPNIC News & Views vol.1647【臨時号】第103回IETF報告 [第4弾] トランスポートエリア関連報告 ～HTTP over QUICからHTTP/3への改称～”. 日本ネットワークインフォメーションセンター (2018年12月13日). 2021年6月28日閲覧。

関連項目

ウィクショナリーにHTTPの項目があります。

• HTTP/2
• HTTPステータスコード
• FTP
• WebDAV
• Webサーバ
• ウェブブラウザ
• アプリケーションサーバ
• Representational State Transfer (REST)
• HTTPヘッダ・インジェクション
• Hyper Text Coffee Pot Control Protocol
• バーチャルホスト

外部リンク

• 『HTTP』 - コトバンク
• HTTP - IT用語辞典 e-Words

表 話 編 歴 セマンティック・ウェブ
背景	データベース ハイパーテキスト インターネット オントロジー 意味ネットワーク World Wide Web
サブトピック	データウェブ データ空間（英語版） ハイパーデータ（英語版） Linked Data (en)  ルールベースシステム（英語版）
アプリケーション	Semantic analytics Semantic broker Semantic computing Semantic mapper Semantic matching Semantic publishing Semantic reasoner Semantic search Semantic service-oriented architecture Semantic wiki
関連項目	集団的知性 記述論理（英語版） フォークソノミー ジオタギング 情報アーキテクチャ 知識抽出（英語版） ナレッジマネジメント 知識表現 図書館2.0（英語版） メタデータ マインドマップ ODBC 参照 トピックマップ Web 2.0 ウェブエンジニアリング（英語版） ウェブ・サイエンス・トラスト（英語版）
標準	文法とサポート技術 HTTP IRI URI RDF triples RDF/XML JSON-LD Turtle（英語版） TriG（英語版） Notation3 N-Triples TriX（英語版） (非W3C標準) RRID SPARQL XML スキーム、オントロジー、ルール Common Logic OWL RDFS Rule Interchange Format Semantic Web Rule Language ALPS セマンティック注釈 eRDF GRDDL マイクロデータ（英語版） マイクロフォーマット RDFa SAWSDL Facebook Platform 共通語彙 DOAP Dublin Core FOAF Schema.org SIOC SKOS マイクロフォーマット語彙 hAtom hCalendar hCard hProduct hRecipe hResume hReview
カテゴリ

表 話 編 歴 URIスキーム
公式	aaa aaas about（英語版） acap cap cid crid data dav dict dns fax file（英語版） ftp geo（英語版） go Gopher h323 http https iax im imap info ldap mailto mid news nfs nntp pop rsync pres rtsp sip sips sms snmp tag tel telnet tftp urn view-source（英語版） wais ws xmpp
非公式	afp aim apt bolo（英語版） bzr callto coffee cvs daap dsnp ed2k feed fish gg git gizmoproject irc ircs itms javascript ldaps magnet mms msnim postal2 secondlife skype spotify ssh svn sftp smb steam webcal winamp wyciwyg xfire ymsgr
プロトコル一覧（英語版）

表 話 編 歴 Webインタフェース
サーバサイド	プロトコル HTTP v2 v3 暗号化 WebDAV CGI SCGI（英語版） FCGI AJP（英語版） WSRP（英語版） WebSocket APIs C NSAPI（英語版） C ASAPI C ISAPI Java Servlet CIL System.Web.IHttpHandler（英語版） Python WSGI Ruby Rack（英語版） JavaScript JSGI（英語版） Perl PSGI Lua WSAPI（英語版） トピックス Webサービス アプリケーションサーバ リソース (WWW) Open API（英語版） サーバサイドスクリプト Webhook
クライアントサイド	Browser APIs ActiveX Browser Helper Object Google Native Client WebAssembly Web API（英語版） W3C Canvas CORS（英語版） File API（英語版） Geolocation（英語版） IndexedDB Microdata（英語版） SVG WebGPU WebRTC WebSocket WebVTT Web Messaging（英語版） ウェブストレージ Web Worker XMLHttpRequest オーディオ ビデオ クロノス WebCL WebGL その他 Gears Web SQL Database（英語版） WebUSB（英語版） トピックス Ajax DHTML Mashup Web IDL（英語版）
関連項目	ウェブページ 静的 動的 Open Web Platform（英語版） Web APIセキュリティ（英語版） ウェブアプリケーション RIA SPA PWA
ウェブユーザインタフェース

典拠管理データベース: 国立図書館	フランス BnF data ドイツ イスラエル アメリカ

MILLENNIUM PARADE

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2025/03/25 14:40 UTC 版)

この項目では、音楽プロジェクトについて説明しています。同名のアルバムについては「THE MILLENNIUM PARADE」をご覧ください。

常田大希 > MILLENNIUM PARADE

MILLENNIUM PARADE
別名	millennium parade（旧称） ꉈꀧ꒒꒒ꁄꍈꍈꀧ꒦ꉈ ꉣꅔꎡꅔꁕꁄ[1]
出身地	日本
ジャンル	オルタナティブ、ポップ
活動期間	2019年 -
レーベル	アリオラジャパン（2019年-） エピック・レコード, RCAレコード（2024年-）
公式サイト	MILLENNIUM PARADE Official website
メンバー	常田大希（ボーカル・ギター・チェロ） ほか

MILLENNIUM PARADE
YouTube
チャンネル	MILLENNIUM PARADE Official YouTube Channel
活動期間	2020年 -
ジャンル	音楽
登録者数	44.2万人
総再生回数	1億6780万回
YouTube Creator Awards 登録者100,000人 2020年
チャンネル登録者数・総再生回数は 000000002024-10-29-00002024年10月29日時点。
テンプレートを表示

MILLENNIUM PARADE（ミレニアムパレード）は、King Gnuのメンバーでもある常田大希が主宰する音楽プロジェクト。愛称は「ミレパ」。常田自身のソロプロジェクトDaiki Tsuneta Millennium Parade（DTMP）を前身とし、2019年に結成された^[2]。

概要

“世界から見た東京の音”をテーマとし、自身のクリエイティブチームPERIMETRONと共に、様々なアーティストやクリエイターを巻き込み発信する音楽プロジェクトである。

2019年よりmillennium paradeとして活動を開始。

2021年には自身初となるアルバム、THE MILLENNIUM PARADEをリリース。完全生産限定盤では、12inchのスペシャルBOXに、初回限定盤、オリジナル小鬼フィギュア3体、また『構想盤』としてDTMP時代にリリースされた楽曲を収録したカセットテープが収められていて、millennium paradeの世界観を敷き詰めた内容になっている^[3]。

2024年、EPIC USおよびRCA UKの2社との契約を発表すると同時に、全大文字表記の「MILLENNIUM PARADE」へと改名した^[4]。この改名に先がけ、各種配信サービス等にてmillennium parade名義で配信されていた楽曲のアーティスト名が彝文字を使用した「ꉈꀧ꒒꒒ꁄꍈꍈꀧ꒦ꉈ ꉣꅔꎡꅔꁕꁄ」に変更された^[1]。同時に、同名義の楽曲のジャケットアートワークやミュージックビデオのサムネイルなども古びた見た目のものに差し替えられた^[1]。

メンバー

曲によってボーカルやプレイヤーは変動するが、主なメンバーは以下の通り^[5]。

• 常田大希（PERIMETRON主宰者、King Gnu）：作曲、ボーカル、チェロ、ギター、プロデューサー
• 佐々木集（PERIMETRON）：クリエイティブ・ディレクター、デジタルアーティスト 、アジテーター、ラップ、エレクトリックベース
• 森洸大（PERIMETRON）：デザイナー、アートディレクター、サンプラー、アジテーター、ラップ
• OSRIN（PERIMETRON）：映像作家
• 新井和輝（King Gnu）：エレクトリックベース、シンセベース、コントラバス
• 勢喜遊（King Gnu）：ドラム、ビートメイキング、サンプラー
• 宮川純：鍵盤楽器、シンセサイザー

その他のメンバー

主にmillennium parade期にグループの中心となって活動していたメンバーは以下の通り。

• ermhoi（Black Boboi）：ボーカル、作詞
• MELRAW/安藤康平：サックス、ギター、ヴォコーダー
• 江﨑文武（WONK）：鍵盤楽器、オルガン、ピアノ、オーケストラプログラミング
• 石若駿：ドラム、シンセベース
• 神戸雄平（PERIMETRON）：デジタルアーティスト、3DCGアニメーター
• 常田俊太郎：ヴァイオリン、オーケストラプログラミング

ディスコグラフィ

millennium paradeのディスコグラフィ

リリースリスト
↙スタジオ・アルバム	2
↙シングル	7
↙先行配信	8
↙楽曲提供・参加作品	3

シングル

	発売日	タイトル	ボーカル	規格	収録アルバム	備考
millennium parade
1st	2019年5月22日	Veil	ermhoi	デジタル・ダウンロード	-
2nd	2019年6月28日	Plankton			THE MILLENNIUM PARADE
3rd	2019年9月27日	Stay!!!	Chara		-
4th	2019年12月6日	lost and found	ermhoi		THE MILLENNIUM PARADE
5th	2020年4月22日	Fly with me	ermhoi、HIMI、森洸大、長塚健斗	CD、アナログ盤、デジタル・ダウンロード		[注 1]
6th	2020年10月2日	Philip	中野裕太、常田大希	デジタル・ダウンロード
7th	2021年8月18日	U	Belle(中村佳穂)	CD、デジタル・ダウンロード
8th	2022年6月1日	Secret Ceremony/No Time to Cast Anchor	ermhoi、timetheft			[注 2]
9th	2023年5月17日	W●RK/2◯45	椎名林檎、常田大希	CD、デジタル・ダウンロード		[6]
MILLENNIUM PARADE
1st	2024年5月10日	GOLDENWEEK		デジタル・ダウンロード
2nd	2024年7月26日	M4D LUV
3rd	2024年10月18日	KIZAO	Rauw Alejandro、Tainy、常田大希

先行配信

	発売日	タイトル	ボーカル	収録アルバム	オリコン最高位（DS[7]）
1st	2021年1月8日	2992	ermhoi	THE MILLENNIUM PARADE	42位
2nd	2021年1月22日	FAMILIA	井口理、常田大希		40位
3rd	2021年2月5日	Bon Dance	ermhoi		-
4th	2021年7月12日	U	Belle(中村佳穂)		1位
5th	2022年5月20日	Secret Ceremony	timetheft、ermhoi		33位
6th	2022年5月27日	No Time to Cast Anchor	ermhoi		41位
7th	2023年4月1日	W●RK	椎名林檎、常田大希		4位

アルバム

	発売日	タイトル	販売形態	規格品番	収録曲
Daiki Tsuneta Millennium Parade 名義（APOLLO SOUNDSレーベル）
1st	2016年7月20日	http://	CD	APLS-1608	全20曲 Angya Ennui Mannequin WWW θ Onibi Heroine Kowloon com Down&Down #blank Mirror Neuron Ice will not burn. Sweet Complex Internet meme Dr.Brodsky Ludovico Technique Prêt Porter Kink
millennium parade 名義（Ariolaレーベル）
1st	2021年2月10日	THE MILLENNIUM PARADE	CD	BVCL-1136	→詳細は「THE MILLENNIUM PARADE § 収録曲」を参照
			CD+Blu-ray	BVCL-1134/5 （初回生産限定盤）
			CD+Blu-ray+カセット+グッズ	BVCL-1130/3 （完全生産限定盤）
	2021年8月21日		アナログ盤（12inch2枚組）	BVJL-51/2 （完全生産限定盤）

楽曲提供・参加作品

楽曲提供

• Numero Tokyo「Emporio Armani×菅原小春」ファッションムービー^[8]
• New Balance×Chari Co×BEAMS T^[9]

参加作品

発売日	収録曲	収録作品名	アーティスト	販売形態	備考
Daiki Tsuneta Millennium Parade 名義
2017年9月6日	Interlude #1(feat. Daiki Tsuneta Millennium Parade)	Castor	WONK	CD・配信
2017年11月22日	bit	MONK’ｓ Playhouse	Daiki Tsuneta Millennium Parade
2018年3月28日	革命前夜 Remix by Daiki Tsuneta Millennium Parade	from JAPAN２	Tempalay	LP+7インチシングル	アナログ盤のみ収録。
millennium parade 名義
2020年6月24日	Fly with me	THEME SONGS+O.S.T. GHOST IN THE SHELL:SAC_2045	millennium parade × ghost in the shell: SAC_2045	アナログ盤
	Fly with me(opening ver.)
2021年7月30日	U	竜とそばかすの姫 オリジナル・サウンドトラック	millennium parade × Belle	配信	配信版のみ収録。
2022年2月9日(日本国内)	U（English Version）	"BELLE" Original Motion Picture Soundtrack			Uの英語版。 歌唱はカイリー・マクニール（英語版） が担当[10]。
2022年9月23日(日本国内)	U（Chinese Version）	"BELLE" Original Motion Picture Soundtrack [Chinese Edition]			Uの中国語版。 歌唱はNeekoが担当。
	U（German Version）	"BELLE" Original Motion Picture Soundtrack [German Edition]			Uのドイツ語版。 歌唱はララ・トラウトマン（ドイツ語版） が担当。
	U（Norwegian Version）	"BELLE" Original Motion Picture Soundtrack [Norwegian Edition]			Uのノルウェー語版。 歌唱は ハンナ・ストームが担当。

タイアップ

起用年	曲名	タイアップ
2019年	lost and found	『Dior and RIMOWA』コラボレーションムービー[11]
2020年	Fly with me	Netflix独占配信アニメーション『攻殻機動隊 SAC_2045』オープニングテーマ[12]
	Philip	『adidas CASUAL Collection』ウェブCMソング[13]
2021年	2992	NHKスペシャルシリーズ『2030 未来への分岐点』テーマ音楽[14]
	FAMILIA	映画『ヤクザと家族 The Family』主題歌[15]
	Trepanation	映画『ホムンクルス』メインテーマ[16]
	U	映画『竜とそばかすの姫』メインテーマ[17]
	Fly with me	映画『攻殻機動隊 SAC_2045 持続可能戦争』主題歌[18]
	Bon Dance	『第34回東京国際映画祭』フェスティバルソング[19]
2022年	Secret Ceremony	Netflix独占配信アニメーション『攻殻機動隊 SAC_2045 SEASON2』オープニングテーマ[20]
	No Time to Cast Anchor	Netflix独占配信アニメーション『攻殻機動隊 SAC_2045 SEASON2』エンディングテーマ[20]
	Mannequin[注 3]	展覧会「アンディー・ウォーホル・キョウト/ANDY WARHOL KYOTO」テーマソング[21]
2023年	W●RK	テレビ東京系アニメ『地獄楽』オープニングテーマ[22]
	Secret Ceremony	映画『攻殻機動隊 SAC_2045 最後の人間』主題歌[23]
	No Time to Cast Anchor
2024年	GOLDENWEEK	PlayStation 『PLUSE Elite ワイヤレスヘッドセッド』北米タイアップソング[24]

受賞歴

年	賞	受賞
2020年	MTV VMAJ 2020	最優秀オルタナティブビデオ賞／Best Alternative Video「Fly with me」[25]
2021年	MTV VMAJ 2021	最優秀コラボレーションビデオ賞／Best Collaboration Video「U」[26]
2022年	SPACE SHOWER MUSIC AWARDS 2022	BEST GROUP ARTIST[27]
		BEST MOVIE SONG「U」[27]
		BEST CG/ANIMATION VIDEO「Bon Dance」[27]
	第14回CDショップ大賞 2022	入賞『THE MILLENNIUM PARADE』[28]
		コメント大賞『THE MILLENNIUM PARADE』[28]
2023年	MTV VMAJ 2023	最優秀コラボレーションビデオ賞／Best Collaboration Video「W●RK」[29]

ライブ

ワンマンライブ

公演年	公演名	公演日	会場
2019	“millennium parade Launch Party”	2019年5月22日(水)	恵比寿LIQUIDROOM
	millennium parade live 2019	2019年12月3日(火)	なんばHatch
		2019年12月5日(木)	新木場STUDIO COAST
2020	millennium parade 3D LIVE 2020	2020年12月23日(水)	東京国際フォーラム・ホールA
2021	millennium parade Live 2021 "THE MILLENNIUM PARADE"	2021年10月2日(土)	東京ガーデンシアター
		2021年10月3日(日)
		2021年10月4日(月)
		2021年10月6日(水)	大阪フェスティバルホール
		2021年10月7日(木)
2024	"WHO AND HOW TOUR 2024" ※全公演中止[30]	2024年11月2日 (土)	Lunario del Auditorio Nacional（メキシコ）
		2024年11月4日 (月)	The Fonda Theater（アメリカ）
		2024年11月7日 (木)	Irving Plaza（アメリカ）
		2024年11月9日 (土)	Danforth Music Hall（カナダ）
		2024年11月14日 (木)	Festsaal Kreuzberg（ドイツ）
		2024年11月16日 (土)	Le Trianon（フランス）
		2024年11月18日 (月)	HERE at Outernet（イギリス）
		2024年11月20日 (水)	TivoliVredenburg Ronda（オランダ）
		2024年12月19日 (木)	東京ガーデンシアター（日本）
		2024年12月20日 (金)

フェス

• SXSW 2021（2021年4月27日、Twitchにてオンライン開催）^[31]
• Splendour XR（英語版）（2021年7月25日、Sansar（英語版）バーチャルライブ）^[32]
• FUJI ROCK FESTIVAL'21（2021年8月20日、苗場スキー場）^[33]

展覧会

『#014 ヌーミレパーク（仮）』DIRECTED BY PERIMETRON

常田大希が率いるKing Gnuとmillennium paradeの世界観をPERIMETRONとともに再現した、Ginza Sony Park（東京都銀座）にて開催されたプログラム。ミュージックビデオで実際に使用された小道具の展示、ミュージックビデオに登場した3DCG映像の再現、ライブで使用された3D映像の投影など、様々な細部まで拘った作品が展示された^[34][35]。

Sony Park展 「④映画は、森だ。」 with millennium parade

2021年6月26日-9月30日にGinza Sony Park（東京都銀座）にて開催されたプログラム「Sony Park展」の展示の一つ。Sony Park展では、岡崎体育、奥田民生、東京スカパラダイスオーケストラ、millennium parade、YOASOBI、Creepy Nutsの6組のアーティストが体験型企画を展開。ゲーム、音楽、映画、エレクトロニクス、半導体、金融の6つのテーマのうち、millennium paradeは映画を担当し、8月16日-27日に展示を行った。PERIMETRONとともに期間限定ミニシアターの「THE MILLENNIUM PARADE THEATER」を展示し、Bon DanceのMVとスペシャル映像が上映された^[36]。

また、同内容のプログラム「Sony Park展 KYOTO」は2022年11月11日-23日に京都新聞印刷工場跡にて開催された^[37]。

MANGA in New York presented by Ginza Sony Park Project

2023年10月27日-11月5日にGinza Sony Park Projectがニューヨークにて開催したプログラム。一乗ひかる、寺田克也、たかくらかずき、平岡政展、ますだみく、millennium paradeの6組のアーティストが6つのテーマ「Pioneer」「Dreams」「Diversity」「Creativity」「Curiosity」「Sincerity」に合わせ、６つのオリジナルストーリーのマンガを制作^[38]。millennium paradeの制作した『DREAM PILL - ドリーム・ピル』は、2045年の東京をイメージした仮想世界「混沌東京」で享楽的な生活を送る少年Ａがドリームピル（夢見る薬）を手にして新たな没入体験を得る内容となっている^[39]。

出演

NHK紅白歌合戦出場歴

番組名	日付	曲目	備考
第72回NHK紅白歌合戦	2021年12月31日	U	millennium parade × Belle（中村佳穂）として初出場。

テレビ

• ミュージックステーション　テレビ朝日系列
  • 「Fly with me」(2021年2月19日)
• CDTV ライブ! ライブ!　TBSテレビ系列
  • 「Fly with me」「FAMILIA」(2021年3月1日)

脚注

[脚注の使い方]

脚注

1. ^ CD版と配信版の「millennium parade × ghost in the shell:SAC_2045 version」はフライングドッグから、アナログ盤と配信版の「millennium parade version」はアリオラジャパンからリリース。
2. ^ CDは全形態フライングドッグ、配信はアリオラジャパンからリリース。
3. ^ Daiki Tsuneta Millennium Parade名義の楽曲。

出典

1. ^ ^{a b c} “常田大希のヴィジョンを考察　MILLENNIUM PARADE改名の背景、新章の狙い”. Rolling Stone Japan(ローリングストーン ジャパン）. CCCミュージックラボ. 2024年5月6日閲覧。
2. ^ “King Gnu常田大希、新プロジェクト・millennium paradeで世界へ”. CINRA.NET (2019年5月31日). 2021年3月30日閲覧。
3. ^ “millennium paradeが初アルバムリリース、12月には国際フォーラムで有観客ライブ”. 音楽ナタリー. ナターシャ. 2024年5月6日閲覧。
4. ^ Inc, Natasha. “常田大希率いるMILLENNIUM PARADEが欧米レーベル2社と契約、世界進出を本格化”. 音楽ナタリー. 2024年5月4日閲覧。
5. ^ “millennium paradeの2021年2月1日の投稿”. www.instagram.com. 2021- 02-06閲覧。
6. ^ Inc, Natasha. “millennium parade × 椎名林檎「地獄楽」主題歌の配信決定、CDシングルには別のコラボ曲収録”. 音楽ナタリー. 2023年3月19日閲覧。
7. ^ “millennium paradeのデジタルシングル売上TOP7作品”. ORICON NEWS. 2024年7月18日閲覧。
8. ^ “WONK所属レーベル〈epistroph〉がアパレル・ラインを立ち上げ。ローンチ・イベントも開催”. Spincoaster (2017年1月13日). 2021年3月30日閲覧。
9. ^ “new balance × CHARI&CO × BEAMS T in NEW YORK CITY”. BEAMS. 2021年3月30日閲覧。
10. ^ mllnnmprdのツイート、2022年3月12日閲覧。
11. ^ “常田大希 millennium parade、”東京の街”をテーマに、DIORとのコラボレーションが実現「今までで一番いい曲が書けた」”. DE COLUM (2019年11月18日). 2021年3月30日閲覧。
12. ^ “常田大希が描き出す純度の高い“驚き” millennium parade「Fly with me」から感じた比類なき創造性を考察”. Real Sound (2020年5月1日). 2021年3月30日閲覧。
13. ^ “常田大希、millennium paradeの新曲を起用したadidas×アルペン共同キャンペーンのWEB CMに登場”. M-ON! MUSIC (2020年9月18日). 2021年3月30日閲覧。
14. ^ “常田大希率いるmillennium parade、NHKスペシャルシリーズテーマ曲「2992」先行配信　地上波初パフォーマンスも”. Real Sound (2021年1月7日). 2021年3月30日閲覧。
15. ^ “millennium paradeが綾野剛主演のヤクザ映画に主題歌提供、ボーカルは井口理”. 音楽ナタリー (ナターシャ). (2020年10月26日). https://natalie.mu/music/news/402134 2020年10月26日閲覧。 
16. ^ “millennium parade、映画「ホムンクルス」で綾野剛主演作と2回目のタッグ”. 音楽ナタリー (ナターシャ). (2021年2月17日). https://natalie.mu/music/news/416692 2021年2月17日閲覧。 
17. ^ “「竜とそばかすの姫」メインテーマはmillennium parade×中村佳穂、常田大希「最高に刺激的な製作」”. 音楽ナタリー (ナターシャ). (2021年6月3日). https://natalie.mu/music/news/430855 2021年6月4日閲覧。 
18. ^ “劇場版「攻殻機動隊 SAC_2045」11月12日公開、ビジュアル＆特報が解禁”. コミックナタリー. 2021年9月9日閲覧。
19. ^ “millennium parade「Bon Dance」が東京国際映画祭のフェスティバルソングに”. 音楽ナタリー. 2021年9月22日閲覧。
20. ^ ^{a b} “millennium parade「攻殻機動隊 SAC_2045」シーズン2で再び主題歌「誇りに思います。ただいま!」”. 音楽ナタリー. 2022年2月24日閲覧。
21. ^ “常田大希インディーズ時代の楽曲が「アンディ・ウォーホル・キョウト」展テーマソングに”. 音楽ナタリー. 2022年6月8日閲覧。
22. ^ “millennium parade × 椎名林檎、TVアニメ「地獄楽」オープニング主題歌に決定（常田大希＆椎名林檎コメントあり / 動画あり）”. 音楽ナタリー. 2023年2月26日閲覧。
23. ^ 株式会社インプレス (2023年8月24日). “「攻殻機動隊 SAC_2045 最後の人間」が11月公開。シーズン2のBD BOXも”. AV Watch. 2023年8月24日閲覧。
24. ^ “ミレパ新曲がPlayStationヘッドフォンのキャンペーンソングに、常田大希がCM出演（動画あり）”. 音楽ナタリー. 2024年5月11日閲覧。
25. ^ “「MTV VMAJ」米津玄師、あいみょん、King Gnu、ジェネ、BABYMETAL、DISH//、NiziU、JO1ら受賞”. 音楽ナタリー. (2020年10月30日). https://amp.natalie.mu/music/news/402798 2024年1月12日閲覧。 
26. ^ “「MTV VMAJ 2021」星野源、BTS、NiziU、BE:FIRST、ミレパ×Belle、ランぺ、YOASOBIら受賞”. 音楽ナタリー. (2021年10月29日). https://amp.natalie.mu/music/news/451399 2024年1月12日閲覧。 
27. ^ ^{a b c} “YOASOBI、藤井風、ミレパ「スペシャアワード」で複数受賞！BMSG、マカえん、LEXらライブ披露”. 音楽ナタリー. (2022年3月16日). https://amp.natalie.mu/music/news/469748 2024年1月12日閲覧。 
28. ^ ^{a b} “Official髭男dismとWurtSが「CDショップ大賞」受賞”. 音楽ナタリー. (2022年3月3日). https://natalie.mu/music/news/468030 2024年1月12日閲覧。 
29. ^ “Mrs. GREEN APPLE「MTV VMAJ」史上初の4冠「本当にうれしいです！」”. 音楽ナタリー. (2023年11月23日). https://amp.natalie.mu/music/news/550298 2024年1月12日閲覧。 
30. ^ “MILLENNIUM PARADE 『WHO AND HOW TOUR 2024』 開催中止のお詫びとお知らせ”. 2024年8月26日閲覧。
31. ^ Inc, Natasha. “millennium parade、Awich、D.A.N.出演した「SXSW 2021」の映像配信”. 音楽ナタリー. 2024年1月7日閲覧。
32. ^ “millennium parade、デジタル音楽フェス＜Splendour XR＞に出演”. BARKS (2021年7月26日). 2024年1月7日閲覧。
33. ^ “millennium parade、初出演のフジロックで圧巻のステージ！ BelleやKing Gnu・井口理も登場”. THE FIRST TIMES. 2024年1月7日閲覧。
34. ^ “『#014 ヌーミレパーク(仮)』DIRECTED BY PERIMETRON - Ginza Sony Park”. Ginza Sony Park. 2021年2月1日閲覧。
35. ^ “#014 『ヌーミレパーク(仮)』 DIRECTED BY PERIMETRON”. Sony Park. 2024年1月6日閲覧。
36. ^ “『#014 ヌーミレパーク(仮)』DIRECTED BY PERIMETRON - Ginza Sony Park”. Ginza Sony Park. 2021年2月1日閲覧。
37. ^ “Sony Park展 KYOTO program”. Sony Park. 2024年1月6日閲覧。
38. ^ “Ginza Sony Park Project がニューヨークで『MANGA in New York』開催！ー マンガとソニーのテクノロジーを掛け合わせ、新しい体験を生み出す実験的エキシビション”. プレスリリース・ニュースリリース配信シェアNo.1｜PR TIMES (2023年10月6日). 2024年1月6日閲覧。
39. ^ NYS (2023年11月1日). “MANGA in New York その心は？”. 2024年1月6日閲覧。

外部リンク

• MILLENNIUM PARADE Official website
• MILLENNIUM PARADE (@mllnnmprd) - X（旧Twitter）
• MILLENNIUM PARADE (@mllnnmprd) - Instagram
• MILLENNIUM PARADE Official YouTube Channel - YouTubeチャンネル
• MILLENNIUM PARADE (@mllnnmprd_) - TikTok

表 話 編 歴 King Gnu
常田大希 (Vocal/Guitar/Cello/Programming) - 勢喜遊 (Drums/Sampler) - 新井和輝 (Bass/Synth bass) - 井口理 (Vocal/Keyboard)
スタジオ・アルバム	Srv.Vinci時代 1.Mad me more softly - Mini1.トーキョー・カオティック King Gnu改名後 1.Tokyo Rendez-Vous - 2.Sympa - 3.CEREMONY - 4.THE GREATEST UNKNOWN
シングル	CD 1.Prayer X - 2.三文小説/千両役者 -3.BOY - 4.一途/逆夢 - 5.カメレオン - 6.Stardom - 7.SPECIALZ 配信限定 1.Flash!!! - 2.白日 - 3.飛行艇 - 4.傘 - 5.泡 - 6.カメレオン
ラジオ	RADIO GNU - King Gnu 井口理のオールナイトニッポン0(ZERO) (井口単独)
関連項目	MILLENNIUM PARADE - Ariola Japan - PERIMETRON
カテゴリ

表 話 編 歴 Sony Music Labels
所属アーティスト	Awkmiu - SixTONES - 中島健人 - 米津玄師 - Reol - ≒JOY - Vaundy - 石原詢子 - 伍代夏子 - 藤あや子 Sony Music Records adieu - Anly - the GazettE - KID PHENOMENON - ゲーム実況者わくわくバンド - 郷ひろみ - 米米CLUB - 石井竜也 - 近藤真彦 - 崎山蒼志 - 櫻坂46 - Survive Said The Prophet - スカイピース - supercell - SUPER BEAVER - sumika - TiU - DISH// - 中川翔子 - なとり - 22/7 - 日向坂46 - BABYMONSTER - MAN WITH A MISSION - miwa - むﾄ - 紫今 - 吉本坂46 - Ryubi Miyase - ロザリーナ - 生田絵梨花 - UVERworld - DOPING PANDA - フィロソフィーのダンス - モノンクル - 森七菜 - YUI - FLOWER FLOWER - Little Glee Monster - osage - asmi - ALI - 加藤ミリヤ - キタニタツヤ - くじら - 清水翔太 - ZILLION - 當山みれい - TOOBOE - 星街すいせい - MACO - MAISONdes - yama - 遊助 - Iris - 乃木坂46 Epic Records Japan 秋山黄色 - Aqua Timez - 杏 - アンジェラ・アキ - いきものがかり - 吉岡聖恵 - HIROBA - 石崎ひゅーい - 宇多田ヒカル - 小袋成彬 - クアイフ - 坂口有望 - シャイトープ - 鈴木愛理 - 鈴木雅之 - 菅田将暉 - センチミリメンタル - ダイスケ - トミタ栞 - 仲間由紀恵 - ノースリーブス - 花冷え。 - 松下奈緒 - ももすももす - 緑黄色社会 - 渡辺美里 - 2PM - CHANSUNG (From 2PM) - JUNHO (From 2PM) - Jun. K (From 2PM) - NICHKHUN (From 2PM) - TAECYEON (From 2PM) - WOOYOUNG (From 2PM) - BURNOUT SYNDROMES - DEEN - J.Y. Park - LMYK - NEXZ - NiziU - SIX LOUNGE - Stray Kids - T.M.Revolution - 西川貴教 - wacci - YOAKE - YUKI Ki/oon Music 音羽-otoha- - グソクムズ - グループ魂 - ゴスペラーズ - J-100 - 黒沢薫 - エナメル・ブラザーズ - 安岡優 - シド - マオ from SID - 電気グルーヴ - 石野卓球 - 中村弘二 - ねぐせ。 - 羊文学 - 八木海莉 - リーガルリリー - ASIAN KUNG-FU GENERATION - Cody・Lee(李) - DJみそしるとMCごはん - KANA-BOON - L'Arc〜en〜Ciel - Lenny code fiction - PELICAN FANCLUB - POLYSICS - Suchmos - TAIKING - Hedigan's - THIS IS JAPAN - UNICORN - 奥田民生 - ABEDON SME Records 浜田省吾 - Fairlife - 愛奴 - 久保田利伸 - Skoop On Somebody - ポルノグラフィティ - Tama - DEPAPEPE - 押尾コータロー - 岸谷香 - 西野カナ - 私立恵比寿中学 - 岡崎体育 - 中嶋ユキノ - 足立佳奈 - 橋本裕太 - DATS - milet - 米津玄師 - 尾崎裕哉 - ザ・リーサルウェポンズ - MHRJ - Anonymouz - idom - 麗奈 - 梅田サイファー - BLUE ENCOUNT - w.o.d. - tripleS Sony Music Associated Records access - amazarashi - 上ノ堀結愛 - 宇都美慶子 - Uru - Girls2 - CHEMISTRY - Cö shu Nie - ササノマリイ - THE JET BOY BANGERZ - Shohei Takagi - シユイ - 女王蜂 - SPYAIR - TUBE - 前田亘輝 - 春畑道哉 - DEEP - DEEP SQUAD - 中島美嘉 - PEOPLE 1 - ヒトリエ - 福原遥 - フジファブリック - フレンズ - ぼっちぼろまる - Myuk - Lucky² - 凛として時雨 - TK from 凛として時雨 - 凛として時雨 ピエール中野 - LONGMAN - Omoinotake - Creepy Nuts - ざきのすけ。 - JUJU - Leola - DJ和 - ナナヲアカリ - 音莉飴 - 神山羊 - ネクライトーキー - FOMARE Ariola Japan 浅井健一 - SHERBETS - EXIT - OH MY GIRL - OH MY GIRL BANHANA - OKAMOTO'S - 川口レイジ - King Gnu - MILLENNIUM PARADE - Qyoto - Kep1er - コアラモード. - 聖飢魔II - デーモン閣下 - ZEROBASEONE - Damian Hamada's Creatures - CHEHON - NU'EST - 遥海 - 平井堅 - BREIMEN - Brainchild's - 松たか子 - ましまろ - MISIA - 三阪咲 - 優里 - IVE - 角松敏生 - 小田和正 - ザ・クロマニヨンズ - 甲本ヒロト - 真島昌利 Sony Music Direct 石原詢子 - 五輪真弓 - 伊藤蘭 - 伍代夏子 - 清水ミチコ - パク・ヒョンビン -藤あや子 - 南野陽子 - ユン・サンヒョン - 吉田兄弟 - 若林ケン SACRA MUSIC ASCA - =LOVE - Aimer - 楠木ともり - ClariS - 斉藤朱夏 - 斉藤壮馬 - 佐藤ミキ - SawanoHiroyuki[nZk] - 三月のパンタシア - スピラ・スピカ - Special for Princess! - SennaRin - 玉置成実 - TrySail - halca - FLOW - Who-ya Extended - FictionJunction - PENGUIN RESEARCH - MIMiNARI - 安田レイ - LiSA - ReoNa
関連項目	ソニー・ミュージックエンタテインメント (日本) - ソニーグループ - THE FIRST TAKE - ポケットモンスター (アニメ) - MUSIClock
カテゴリ:ソニー・ミュージックエンタテインメント (日本)

Weblio日本語例文用例辞書

「http://」の例文・使い方・用例・文例

• 私どものウェブサイトhttp://www.example.comは、あなたに必要な情報を全てお伝えします。
• http://www.niehs.nih.gov/kids/lyrics/ballgame.htmでこの歌のメロディーを聴くことができます。
• 展覧会はhttp://asagaonokai.jpで見ることができる。
• 滝(たき)田(た)さんの英語の日記は http://www.wildlifedirect.org/asuka/ で読むことができる。
• 2006年，日本に戻り，田辺市熊(くま)野(の)ツーリズムビューロー(http://www.tb-kumano.jp/en/)の職員になる。
• 同協会の携帯サイトのURLはhttp://www.m-moudouken.netだ。
• 英語落語オフィシャル・サイト　http://eigo-rakugo.com