Skip to content

電源投入からウェブサイト表示までに起こること

はじめに

あなたは、パソコンの電源ボタンを押してから、最終的にブラウザでウェブページを見るまで、その間に一体何が起こっているのか考えたことはありますか?

このプロセスはまるでリレー競争のようです——ハードウェアに通電するとファームウェアが起動し、ファームウェアのチェックが完了するとオペレーティングシステムにバトンが渡され、OSが環境を整えた後にブラウザが実行可能になり、ブラウザはネットワークを通じて遠くのサーバーからウェブページを取得します。各段階は前の段階の成功に依存しており、どこかでバトンを取りこぼせば、後続のすべての処理が進みません。

この完全な経路を理解することで、コンピュータシステム全体への認識を構築でき、フルスタックエンジニアへの必須の通過点となります。

何を学ぶのか?

この記事では、実際の発生順序に従って、電源投入からウェブページ表示までの 5 つの段階を順に辿ります:

  1. ハードウェア起動(第 1 節)→ 電流がどのように CPU を目覚めさせるか
  2. ファームウェア自己診断(第 2 節)→ BIOS/UEFI がどのようにハードウェアの正常性を確認し起動デバイスを見つけるか
  3. OS 起動(第 3 節)→ カーネルがどのようにロードされ、デスクトップが表示されるか
  4. ブラウザ起動(第 4 節)→ アプリケーションがどのように OS によって実行されるか
  5. ネットワークリクエスト(第 5 節)→ URL 入力からページレンダリングまでの完全なネットワークの旅

各段階は前の段階の上に成り立っており、どれ一つ欠かせません。


1. 電源投入:ハードウェアの覚醒

1.1 電源起動

電源ボタンを押すと、電源ユニット(PSU) が動作を開始し、交流(220V)を直流(12V、5V、3.3V など)に変換して、各ハードウェア部品に給電します。

電源ボタン → 電源ユニット(PSU) → 直流出力 → マザーボード各部品へ供給

1.2 マザーボードチップセットの起動

電源が安定すると、マザーボードチップセットが動作を開始します。これはコンピュータの「総合管制官」のようなもので、各ハードウェア部品の調整を担当します。

1.3 CPU リセット

CPU はリセット信号を受け取ると、内部のすべてのレジスタとキャッシュをクリアし、あらかじめ決められたアドレスから命令の実行を開始します。このアドレスは通常 BIOS/UEFI チップを指しています。

Hardware Startup Chain
🔌
Power supply
AC power → DC power
🧩
Motherboard chipset
Coordinates hardware components
⚙️
CPU reset
Clear registers and become ready
📟
BIOS/UEFI
Run the first instruction

リレー第一走者完了 ⛳ ここまでで、ハードウェアレベルでの作業が完了しました:電源が交流を安定した直流に変換し、マザーボードチップセットが起動して各部品の調整を始め、CPU もリセットを完了してレジスタをクリアし、最初の命令を実行する準備が整いました。

しかし注意してください——この時点の CPU は、まるで「目を覚ましたばかりの赤ちゃん」のようなものです。命令を実行することはできても、自分の置かれた環境については何も知りません:コンピュータにはどれだけのメモリが搭載されているのか?グラフィックカードは使えるのか?ハードディスクはどこにあるのか?どのデバイスから OS を起動すべきなのか?これらの問いに CPU 自身が答えることはできません。

そのため、CPU がリセット後に実行する最初の命令は、固定のメモリアドレスへのジャンプです——このアドレスはマザーボードにはんだ付けされた BIOS/UEFI ファームウェアチップを指しています。この瞬間から、制御は純粋なハードウェアからファームウェアへと引き継がれます。BIOS/UEFI の役割は明確です:すべてのハードウェアが正常かチェックし、OS を見つけて起動することです。これがリレー競争の第二走者です。

2. BIOS/UEFI:ハードウェアの自己診断

BIOS/UEFI Workflow
📟
BIOS/UEFI
Click start to explore
the firmware boot flow
Intro
POST
Init
Boot
📟
What are BIOS and UEFI?
BIOS is the first program that runs after power-on and lives in a read-only chip on the motherboard. UEFI is the modern, safer successor to BIOS.
1💾BIOS (traditional)
2UEFI (modern)
💡BIOS/UEFI is like the computer gatekeeper: it wakes up first, checks that everything is healthy, and decides who, the operating system, can enter.

リレー第二走者完了 ⛳ BIOS/UEFI はその 3 つの使命を見事に果たしました:POST 自己診断によりメモリ、グラフィックカード、キーボードなどのハードウェアがすべて正常に動作することを確認し、各ハードウェアの動作モードを初期化し、起動順序に従ってハードディスク上のブートセクタを見つけました。

しかし BIOS/UEFI の役割はここまでです——本質的には「健康診断医+管制官」です。ハードウェアが正常かどうかをチェックし、どのデバイスから起動するかを決めることはできても、ファイルを管理したり、アプリケーションを実行したり、美しいデスクトップを表示したりはしません。これらの複雑なタスクには、より強力なソフトウェアによる引き継ぎが必要です——それがオペレーティングシステムです。

引き継ぎの方法は具体的です:BIOS/UEFI はハードディスクの最初のセクタ(ブートセクタ)にあるブートローダのコードを読み取り、メモリにロードし、CPU をそのコードの先頭にジャンプさせて実行を開始します。この瞬間から、制御は正式にファームウェアから OS のブートローダへと移ります。ブートローダは段階的に OS カーネルをロードし、システムサービスを起動し、最終的におなじみのデスクトップを表示します。この経路の中で最も複雑な一歩が始まります。

3. OS 起動:カーネルからデスクトップへ

Operating System Boot Flow
🖥️
Operating System
Manages hardware and software resources
the computer steward
🪟Windows
🍎macOS
🐧Linux
🤖Android
📱iOS
Intro
Bootloader
Kernel
Services
Desktop
🖥️
What is an operating system?
An operating system is the software layer that manages hardware and software resources.
1🏢Resource management
2🎮Provide interfaces
3🔒Security protection
💡The OS is like building management: it supplies utilities, assigns rooms, manages storage, and keeps security so residents, the applications, can live safely.
📊Common Operating Systems
SystemFeaturesTypical devices
🪟 WindowsRich ecosystem and broad compatibilityDesktops and laptops
🍎 macOSApple ecosystem, smooth and stableMac computers
🐧 LinuxOpen source and server-friendlyServers and embedded devices
🤖 AndroidMobile Linux platformPhones and tablets
📱 iOSApple mobile platformiPhone and iPad

リレー第三走者完了 ⛳ OS が完全に起動し、デスクトップが目の前に表示されました。この段階で行われたことを振り返ってみましょう:ブートローダがハードディスクからカーネルを読み取り、カーネルが CPU とメモリの制御権を引き継ぎ、システムサービスが順次起動し(ネットワーク、オーディオ、セキュリティセンター……)、最後にグラフィカルインターフェースがデスクトップをレンダリングしました。

この時点の OS は、通水・通電済みで管理会社が常駐するビルのようなものです——プロセス管理が各住人(プログラム)に部屋を割り当て、メモリ管理が空間を配分し、ファイルシステムが倉庫を管理し、ネットワークプロトコルスタックが対外通信を担当します。これらの「公共サービス」はすべてのアプリケーションが動作するためのインフラであり、これらなしではどんなプログラムも起動できません。

さて、あなたはインターネットを見たいと思い、デスクトップ上のブラウザアイコンをダブルクリックしました。この単純な動作の背後では、OS が一連の作業を行います:ブラウザの実行可能ファイルがハードディスクのどこにあるか探し、独立したプロセスを作成し、メモリ空間を割り当て、プログラムコードをロードします……これが OS の「プロセス管理」能力の直接的な発露です。次に、ブラウザがどのように起動されるのか見ていきましょう。

4. ブラウザを開く:アプリケーションの起動

4.1 アプリケーションの起動プロセス

ブラウザのアイコンをダブルクリックすると、OS は以下の処理を行います:

  1. 実行可能ファイルの検索:ファイルの関連付けに基づいて、ブラウザの .exe(Windows)または実行可能ファイルを見つける
  2. プロセスの作成:ブラウザ用に新しいプロセスを作成する
  3. プログラムのロード:ブラウザのコードをハードディスクからメモリに読み込む
  4. 初期化:ブラウザのメインスレッド、レンダリングエンジン、ネットワークエンジンなどを起動する
ブラウザ起動プロセス:
┌─────────────────────────────────────┐
│  1. アイコンをダブルクリック        │
│  2. OS がブラウザの実行可能ファイルを検索  │
│  3. ブラウザプロセスを作成           │
│  4. ブラウザコードをメモリにロード    │
│  5. 各モジュールを初期化(レンダリング、ネットワーク、JS)│
│  6. ブラウザウィンドウを表示         │
└─────────────────────────────────────┘

4.2 ブラウザの主要構成要素

現代のブラウザは複雑な「オペレーティングシステム」であり、主に以下の部分で構成されています:

モジュール機能
ユーザーインターフェースアドレスバー、タブ、ブックマークなど
ブラウザエンジンUI とレンダリングエンジンの調整
レンダリングエンジンHTML/CSS の解析、ウェブページの表示
JavaScript エンジンJavaScript コードの実行
ネットワークモジュールHTTP リクエストの送信
UI バックエンド基本 UI コンポーネントの描画
データストレージCookie、LocalStorage など
Browser Architecture -- Click a Module for Details
🎨User interface
🔗Browser engine
📄Rendering engine
JavaScript engine
🌐Network module
💾Data storage

リレー第四走者完了 ⛳ ブラウザが正常に起動しました。OS は独立したプロセスを作成し、メモリ空間を割り当て、ブラウザ自身の各モジュールも初期化が完了しました:レンダリングエンジンは HTML/CSS の解析準備が整い、JavaScript エンジンはスクリプトの実行準備が整い、ネットワークモジュールはデータの送受信準備が整いました。

この時点のブラウザは、エンジンがかかった車に例えられます——エンジンは回転し、ダッシュボードは点灯し、ナビゲーションシステムは準備完了していますが、車はまだその場に停まったままです。運転手(あなた)がまだ「どこに行くか」を伝えていないからです。ブラウザのウィンドウは今は空白で、アドレスバーにはカーソルが点滅し、あなたの入力を待っています。

アドレスバーに https://www.example.com と入力して Enter を押すと、インターネット全体を横断する旅が始まります。ブラウザのネットワークモジュールがこのリクエストを引き継ぎます:まず URL の構造を解析し、DNS でドメイン名を IP アドレスに変換し、ネットワークを越えて遠くのサーバーと TCP 接続を確立し、暗号化通信路をネゴシエートし、HTTP リクエストを送信し、サーバーの応答を待ち、最後に受け取った HTML/CSS/JS コードをレンダリングエンジンに渡してウェブページとして描画します。これはリレー経路全体で最もステップが多く、最も多くのプロトコルが関わる区間です——そして Web 開発者が最も理解しておく必要がある区間でもあります。

5. URL へのアクセス:ネットワークリクエストの全過程

5.1 URL とは?

URL(Uniform Resource Locator) はリソースのアドレスです。実際の住所が場所を特定するように、インターネット上のリソースを特定するために使われます。

URL の構造:
┌─────────────────────────────────────────────────────────┐
│  https://  │  www.example.com  │  /path/to/page  │ ?query=1 │
│  プロトコル  │      ドメイン      │     パス       │  クエリ  │
└─────────────────────────────────────────────────────────┘
  • プロトコル(Protocol):どの方式でアクセスするか(http、https、ftp など)
  • ドメイン(Domain):サーバーのアドレス
  • パス(Path):サーバー上のリソースの位置
  • クエリ(Query):追加パラメータ

5.2 URL アクセスの完全なプロセス

https://www.example.com にアクセスするとき、以下のことが起こります:

Full URL Access Flow
Browser
1URL parsing
2DNS lookup
3TCP three-way handshake
4TLS handshake
5Send HTTP request
6Server processing
7Return HTTP response
8Browser rendering
Server

第一段階:URL 解析

ブラウザはまず URL を解析し、プロトコル、ドメイン、パスなどの情報を抽出します。

URL 解析プロセス:
https://www.example.com/index.html

プロトコル: https
ドメイン: www.example.com
パス: /index.html

第二段階:DNS 解決

コンピュータはネットワークを通じてサーバーにアクセスしますが、ネットワークが使うのは IP アドレス(例:93.184.216.34)であり、ドメイン名ではありません。そのため、ドメイン名を IP アドレスに変換する必要があります。このプロセスを DNS 解決と呼びます。

DNS 解決フロー:
┌─────────────────────────────────────────────────────────┐
│  ブラウザキャッシュ → hosts ファイル → ローカルDNSキャッシュ → DNS サーバー │
└─────────────────────────────────────────────────────────┘

実際のプロセス:
1. ブラウザがキャッシュをチェック(最近アクセスしたか?)
2. OS が DNS キャッシュをチェック
3. DNS サーバーにクエリリクエストを送信
4. DNS サーバーが IP アドレスを返す

第三段階:TCP 接続の確立

IP アドレスを取得したら、ブラウザはサーバーと TCP 接続を確立します。TCP はトランスポート層のプロトコルで、データの信頼性のある転送を保証します。

TCP スリーウェイハンドシェイク:
┌─────────────────────────────────────────────────────────┐
│  クライアント → サーバー:SYN(同期リクエスト)          │
│  サーバー → クライアント:SYN-ACK(確認+同期)          │
│  クライアント → サーバー:ACK(確認)                    │
│                        ↓                                │
│  接続確立完了!                                          │
└─────────────────────────────────────────────────────────┘

HTTPS の場合、さらに TLS/SSL ハンドシェイクを行い、暗号化通信路を確立します。

第四段階:HTTP リクエストの送信

接続が確立したら、ブラウザはサーバーに HTTP リクエストを送信します:

HTTP リクエスト形式:
┌─────────────────────────────────────────────────────────┐
│  GET /index.html HTTP/1.1                              │
│  Host: www.example.com                                 │
│  User-Agent: Mozilla/5.0...                             │
│  Accept: text/html                                     │
│                                                         │
│  (空行)                                               │
└─────────────────────────────────────────────────────────┘

よく使われる HTTP メソッド:

メソッド意味用途
GETリソースの取得ウェブ閲覧
POSTデータの送信ログイン、フォーム送信
PUTリソースのアップロードファイルアップロード
DELETEリソースの削除データ削除

第五段階:サーバーによるリクエスト処理

サーバー(通常は Web サーバー、例:Nginx、Apache)はリクエストを受け取った後:

  1. リクエストの解析:クライアントが何を求めているか理解する
  2. ビジネスロジックの処理:バックエンドプログラム(Python、Node.js、Java など)を呼び出す
  3. データベースのクエリ:必要なデータを取得する
  4. レスポンスの生成:データを HTML、JSON などの形式に組み立てる
サーバー処理フロー:
┌─────────────────────────────────────────────────────────┐
│  1. Web サーバーがリクエストを受信 (Nginx/Apache)       │
│  2. パスに基づいて対応するハンドラを見つける              │
│  3. バックエンドコードを実行 (API、ビジネスロジック)      │
│  4. 必要に応じてデータベースにクエリしデータを取得       │
│  5. レスポンスを組み立て (HTML/JSON/CSS/JS)             │
│  6. HTTP レスポンスを返す                               │
└─────────────────────────────────────────────────────────┘

第六段階:HTTP レスポンスの返却

サーバーは HTTP レスポンスを返します。これにはステータスコード、レスポンスヘッダー、レスポンスボディが含まれます:

HTTP レスポンス形式:
┌─────────────────────────────────────────────────────────┐
│  HTTP/1.1 200 OK                                       │
│  Content-Type: text/html                               │
│  Content-Length: 1234                                  │
│                                                         │
│  <!DOCTYPE html>                                       │
│  <html>...</html>                                      │
└─────────────────────────────────────────────────────────┘

よく使われるステータスコード:

ステータスコード意味
200成功
301/302リダイレクト
404リソースが見つからない
500サーバーエラー

第七段階:ブラウザによるページレンダリング

ブラウザはレスポンスを受け取った後、ページのレンダリングを開始します:

Browser Rendering Pipeline
1
HTML parsing
Parse HTML text into the DOM tree, the document object model
2
CSS parsing
Parse CSS rules into stylesheets and compute final styles for each element
3
Build render tree
DOM tree + style rules = render tree containing visible elements
4
Layout calculation
Compute the exact position and size of each element on the page
5
Paint
Draw text, colors, images, borders, and other pixels into buffers
6
Composite and display
Combine layers into the final frame and send it to the screen through the GPU
  1. HTML の解析:DOM ツリーを構築
  2. CSS の解析:スタイルを計算し、レンダリングツリーを構築
  3. JavaScript の実行:ページ内の JS コードを実行
  4. ページの描画:コンテンツを画面に表示
ブラウザレンダリングプロセス:
┌─────────────────────────────────────────────────────────┐
│  1. HTML 解析 → DOM ツリー                             │
│  2. CSS 解析 → スタイルルール                           │
│  3. DOM + CSS → レンダリングツリー                      │
│  4. レイアウト計算 → 各要素のサイズと位置                │
│  5. 描画 → ピクセルを画面に表示                         │
│  6. 合成 → 複数レイヤーを結合表示                       │
└─────────────────────────────────────────────────────────┘

リレー最終走者完了 ⛳ ついにウェブページが目の前に表示されました!この最終段階でどれだけのステップを経てきたか振り返ってみましょう:ブラウザが URL を解析してプロトコルとドメインを抽出し、DNS の段階的なクエリでドメイン名を IP アドレスに変換し、TCP スリーウェイハンドシェイクでサーバーとの信頼性のある接続を確立し、さらに TLS ハンドシェイクで暗号化通信路を確立し、HTTP リクエストを送信し、サーバーがビジネスロジックを処理し、データベースをクエリし、レスポンスデータを組み立てて返し、最後にブラウザのレンダリングエンジンが HTML を DOM ツリーに解析し、CSS をスタイルルールに計算し、両者を統合してレンダリングツリーにし、レイアウトを計算し、ピクセル単位で画面に描画しました。

さて、視点を引いて、このリレー競争の全貌を最初から最後まで見渡してみましょう。電源ボタンを押した瞬間から数えると:電流がハードウェアを目覚めさせ(第 1 走者)→ ファームウェアがデバイスをチェックし起動ディスクを見つけ(第 2 走者)→ OS がカーネルからデスクトップまで完全に起動し(第 3 走者)→ ブラウザがアプリケーションとして OS によって実行され(第 4 走者)→ ネットワークリクエストがインターネットを越えてデータを取得しページにレンダリングしました(第 5 走者)。5 走者は互いに密接に連携し、各走者は前の走者の成果の上に成り立っており、どれか一つでも欠ければ、目の前のこのウェブページを見ることはできません。

次に、この 5 つの段階を一つの完全なフローチャートでつなぎ合わせ、それらの依存関係を直感的に見てみましょう。

6. 完全なフローの振り返り

プロセス全体をつなげてみましょう:

From Pressing Power to Seeing a Web Page -- Full Chain
🔌Hardware startup
Power → motherboard → CPU → BIOS
🔍Firmware self-test
POST → initialize → find boot disk
💻System boot
Bootloader → kernel → services → desktop
🌐Browser startup
Create process → load code → ready
📡Network request and rendering
DNS → TCP → HTTP → render
電源投入からウェブサイトアクセスまでの完全なフロー:

┌──────────────────────────────────────────────────────────────────┐
│  1. 電源投入                                                      │
│     └── 電源起動 → マザーボード起動 → CPU リセット → BIOS/UEFI 実行 │
├──────────────────────────────────────────────────────────────────┤
│  2. BIOS/UEFI 起動                                               │
│     └── ハードウェア自己診断 → 起動デバイス探索 → ブートローダ読み取り │
├──────────────────────────────────────────────────────────────────┤
│  3. OS 起動                                                      │
│     └── ブートローダ → カーネルロード → サービス起動 → デスクトップ表示 │
├──────────────────────────────────────────────────────────────────┤
│  4. ブラウザを開く                                                │
│     └── アイコンダブルクリック → プロセス作成 → プログラムロード → ウィンドウ表示 │
├──────────────────────────────────────────────────────────────────┤
│  5. URL アクセス                                                  │
│     └── URL 解析 → DNS 解決 → TCP 接続 → HTTP リクエスト         │
│         → サーバー処理 → HTTP レスポンス → ブラウザレンダリング → ウェブページ表示 │
└──────────────────────────────────────────────────────────────────┘

全経路を見渡すと、興味深い法則に気づくでしょう:各段階で解決する問題はまったく異なり、背後にある技術分野もまったく異なります。第 1 走者は電子工学の領域——電源変換、回路設計、信号伝送。第 2 走者はファームウェアプログラミング——低レベルのコードでハードウェアを直接操作。第 3 走者はオペレーティングシステムの世界——プロセススケジューリング、メモリ管理、ファイルシステム、これらはコンピュータサイエンスの中核的課題です。第 4 走者はアプリケーション開発——ブラウザのような複雑なソフトウェアアーキテクチャをどのように設計するか。第 5 走者はコンピュータネットワークフロントエンド開発を横断——DNS、TCP/IP、HTTP などのネットワークプロトコルから、HTML/CSS/JS の解析とレンダリングまで。

これは「フルスタックエンジニア」になぜ幅広い知識が必要なのかも説明しています:あなたが書いたすべてのフロントエンドコードは、最終的にこの経路全体を通ってユーザーに届けられます。経路の各環を理解することで、問題に直面したときに素早く切り分けられます——ネットワーク層の問題か?サーバーの問題か?それともブラウザレンダリングの問題か?

以下の知識マップはこれらの技術分野を整理し、今後の深い学習への道しるべとなります。

7. 知識マップ

この章で扱う知識分野:

コンピュータシステム概観
├── ハードウェア基礎
│   ├── 電源 (PSU)
│   ├── マザーボードチップセット
│   └── CPU
├── BIOS/UEFI
│   ├── POST 自己診断
│   ├── 起動順序
│   └── ブートローダ
├── オペレーティングシステム
│   ├── カーネル (Kernel)
│   ├── システムサービス
│   └── デスクトップ環境
├── アプリケーション
│   ├── プロセス管理
│   └── プログラムロード
└── ネットワーク通信
    ├── DNS 解決
    ├── TCP/IP プロトコル
    ├── HTTP プロトコル
    └── ブラウザレンダリング

学習を続ける

特定の段階を深く理解したい場合は、以下を続けて学習してください:

  • トランジスタから CPU へ:コンピュータハードウェアの基礎を理解する
  • オペレーティングシステム(プロセス/メモリ/ファイルシステム):OS を深く理解する
  • コンピュータネットワーク:ネットワークプロトコルを深く理解する