【発展】物理層から通信が成立するまで(電力・Ethernet・Wi-Fi・Bluetooth)
アプリ開発者が普段意識しない「ケーブル・電波・電力」の層を俯瞰し、開発者目線で知っておくと設計判断や障害対応に役立つ最低限のポイントをまとめる
- この章で学ぶこと:電力の供給から Ethernet・Wi-Fi・Bluetooth までの物理層・データリンク層で何が起きているかを俯瞰し、アプリ開発者が知っておくと役立つ点(遅延・電波干渉・省電力設計)を整理する。
- なぜ学ぶのか:通常の Web 開発では意識しない領域だが、モバイル・IoT・オフィス内アプリで「なぜか遅い」「特定の環境で動かない」といった問題の原因はここにあることが多く、設計段階で仮説を立てられるようになる。
- Web 開発のどの領域か:発展トピック。本章を飛ばしても
b01以降の学習に支障はない。興味があるときに読めばよい。
前提:
b00-3-network-basicsを読み終えていること。所要時間: 40 分(読解 30 分+確認クイズ 10 分)
到達目標: 「Wi-Fi が不安定なオフィスで SNS アプリのレスポンスが遅くなる」現象に対して、物理層・リンク層・ネットワーク層のどこに原因がありうるか仮説を立てられる状態。
なぜアプリ開発者が物理層を知るのか
HTTP・TCP・IP はすべて最終的に電気信号か電波として運ばれる。普段は抽象化されていて意識しないが、以下のような場面では物理層の知識が効いてくる。
- 社内 Wi-Fi が混雑してレスポンスが不安定なとき、原因仮説を立てるため
- 医療・工場などの現場で使う端末が Bluetooth 機器(血圧計・バーコードリーダー)と連携するとき
- モバイル回線(4G/5G)での利用を想定した際のタイムアウト設計
- データセンターの電力・冷却コストがクラウド料金に反映されていることを理解するため
本章は「開発者として最低限押さえたいポイント」に絞って解説する。電気工学の深い理解は不要。
電力:すべては電気から始まる
すべてのコンピューター・ルーター・基地局は電気で動いている。通信の土台として、次の区別だけ押さえる。
AC と DC
- AC(交流): 家庭のコンセントから来る電気。日本は 100V・50/60Hz。
- DC(直流): コンピューター内部で使う電気。5V・12V・3.3V などが一般的。
ノート PC や Wi-Fi ルーターの AC アダプターは「AC を DC に変換する装置」である。サーバーも同じく電源ユニット(PSU)で AC → DC 変換を行い、CPU や SSD に供給する。
データセンターの電力
クラウド(AWS・GCP・Azure)のサーバーは、データセンターと呼ばれる巨大な施設で運用される。データセンターの運用コストの半分以上は電力と冷却が占める。
- PUE(Power Usage Effectiveness): 総消費電力 ÷ IT 機器の消費電力。1.0 が理想で、Google・Meta のデータセンターは 1.1 前後、一般的なデータセンターは 1.5〜1.8。
- 冗長化: 商用電源の障害に備え、UPS(無停電電源装置)と発電機を多重化している。
- 再生可能エネルギー: 大手クラウドは再エネ 100% への移行を進めており、サービス選定の基準になることがある。
開発者への影響: サーバーレス・CDN・キャッシュを活用すると「無駄な電力消費」を減らせる。これはコスト削減にも環境負荷低減にも直結する。
有線 LAN(Ethernet)
最も枯れていて安定した通信方式。
規格
| 規格 | 速度 | 主な用途 |
|---|---|---|
| 100BASE-TX | 100 Mbps | 古いオフィス機器 |
| 1000BASE-T(ギガビット) | 1 Gbps | 現代の家庭・オフィス標準 |
| 10GBASE-T | 10 Gbps | データセンター・ワークステーション |
| 100GbE / 400GbE | 100〜400 Gbps | クラウドのバックボーン |
特徴
- 全二重通信: 送受信を同時に行える(かつての半二重とは異なる)。
- PoE(Power over Ethernet): LAN ケーブル 1 本で通信と電力供給を両立できる。監視カメラや Wi-Fi アクセスポイントの設置でよく使われる。
- レイテンシ: 社内 LAN では通常 1 ミリ秒未満。Wi-Fi と比べて圧倒的に安定する。
開発者への影響
開発・配信サーバー間の通信は基本的に有線 Ethernet。AWS の EC2 ↔ RDS 間も、物理的には Ethernet(しばしば 25GbE 以上)で接続されている。
無線 LAN(Wi-Fi)
ケーブルを引かない便利さと引き換えに、干渉・減衰・共有の宿命を抱えている。
主な規格
| 規格名 | IEEE 名 | 周波数帯 | 最大速度(理論値) |
|---|---|---|---|
| Wi-Fi 4 | 802.11n | 2.4 / 5 GHz | 600 Mbps |
| Wi-Fi 5 | 802.11ac | 5 GHz | 6.9 Gbps |
| Wi-Fi 6 | 802.11ax | 2.4 / 5 GHz | 9.6 Gbps |
| Wi-Fi 6E | 802.11ax | 6 GHz 追加 | 9.6 Gbps |
| Wi-Fi 7 | 802.11be | 2.4 / 5 / 6 GHz | 46 Gbps |
2.4GHz と 5GHz と 6GHz の違い
| 帯域 | 特徴 |
|---|---|
| 2.4 GHz | 遠くまで届く・壁を越えやすい。ただし電子レンジ・Bluetooth・他の家電と干渉しやすい |
| 5 GHz | 高速・空いている。ただし壁で減衰しやすく遠距離に弱い |
| 6 GHz | Wi-Fi 6E 以降で利用可能。最もクリーンで高速。対応機器はまだ限定的 |
開発者への影響
- Wi-Fi は 共有媒体 である。同じアクセスポイントにぶら下がる端末が増えると 1 台あたりの実効帯域が下がる。
- Wi-Fi は パケットロスが発生する前提で設計されている。TCP が再送してくれるため多くのアプリは気づかないが、動画通話や WebSocket では体感に現れる。
- ユーザーが移動するアプリ(訪問看護・営業支援)では Wi-Fi から 4G/5G へ切り替わる瞬間に IP アドレスが変わる。再接続ロジックを入れておくことが重要。
モバイル回線(4G・5G)
屋外・移動中の通信はセルラー網を使う。
| 世代 | 最大速度(理論値) | レイテンシ |
|---|---|---|
| 3G(UMTS) | 数 Mbps | 100〜500 ms |
| 4G / LTE | 〜1 Gbps | 30〜50 ms |
| 5G | 10 Gbps 以上 | 1〜10 ms |
低レイテンシ は 5G の重要な特徴で、遠隔医療・自動運転・AR/VR のような「応答性が命」のアプリを成立させる。通常の Web アプリでは 4G で十分なケースが多いが、長いレイテンシ前提で楽観的 UI(Optimistic UI)を実装するなどの設計で対応する。
Bluetooth
近距離・低速・低消費電力が特徴。Wi-Fi が「家〜オフィス全体」だとすると、Bluetooth は「机の上・身体の近く」の通信。
Classic と LE
- Bluetooth Classic(BR/EDR): 音声・音楽のストリーミングで使用。消費電力が大きめ。
- Bluetooth Low Energy(BLE): IoT・医療機器で普及。コイン電池で数年動くほどの低消費電力が特徴。
ペアリングとセキュリティ
- ペアリング時に鍵を共有し、以降は暗号化通信になる。
- 公開鍵暗号を使った Secure Connections モードが現在の標準。
- 古い LE(Just Works モード)はパスキーなしで接続するため、機密データのやり取りには使用しない。
Mesh ネットワーク
Bluetooth Mesh は複数のデバイスが互いを中継してネットワーク全体に信号を届ける仕組み。スマート照明・ビル管理システムなどで使われる。
開発者への影響
Web アプリから直接 Bluetooth 機器を操作したい場合、Web Bluetooth API が Chromium 系ブラウザで利用できる(Safari は非対応)。現場端末との連携を考える際は、ネイティブアプリ(iOS/Android)での実装と比較検討することが多い。
物理層から Web アプリへのつながり
ここまでの層を縦に積むと、1 回の HTTP リクエストは次のように多層の橋渡しを受けている。
アプリ層 HTTP (b00-2・b06 で扱う)
↓
トランスポート層 TCP/UDP (b00-3 で扱う)
↓
ネットワーク層 IP (b00-3 で扱う)
↓
データリンク層 Ethernet/Wi-Fi/Bluetooth (本章)
↓
物理層 ケーブルの電気信号・電波・光ファイバーの光
↓
電力 AC/DC・発電所・データセンター
普段は最上段(HTTP)だけを書けば済むが、どこかの層で物理的な制約が出ると最上段まで影響する。「アプリは変わっていないのに遅くなった」というとき、犯人が下の層にいる可能性を思い出せる状態を目指す。
【アーキテクチャ】コラム:エッジコンピューティングと物理距離
課題: 光は 1 秒に約 30 万キロ進むが、地球の裏側までは理論値でも片道 66 ms の遅延が避けられない。物理的な距離は光速で律速される。
解決策の方向性:
- CDN: 静的リソースをユーザーに近いエッジサーバーに配置。代表:CloudFront・Cloudflare。
- エッジコンピューティング: 計算そのものもエッジで実行。代表:Cloudflare Workers・AWS Lambda@Edge・Fastly Compute@Edge。
- マルチリージョンデータベース: データ自体を世界に分散。代表:AWS DynamoDB Global Tables・CockroachDB・Spanner。
本カリキュラムの選択: SNS のレイテンシ要件はミリ秒級ではなく数十〜100ms で十分なため、CloudFront による CDN のみを採用し、アプリ本体は 1 リージョンで運用する。エッジコンピューティングは運用コストが上がるためスコープ外とする。
【セキュリティ】コラム:公衆 Wi-Fi と電波盗聴
脅威: Wi-Fi の電波は空間を飛ぶ。WPA2/WPA3 で暗号化されていない、または古い WEP を使っている Wi-Fi では、近くにいる攻撃者が電波を傍受するだけで通信内容を読み取れる恐れがある。
具体例: カフェの「パスワードなし Wi-Fi」は一切の暗号化がないため、同じ Wi-Fi にいる攻撃者が
Wiresharkで全パケットを可視化できる。HTTP で送った情報は丸見えになる。防御:
- すべての通信を HTTPS にする(HSTS を含む)。これで Wi-Fi 層の盗聴は無効化される。
- 不特定多数が使う Wi-Fi では VPN を使うか、モバイル回線を優先する。
- 自社オフィスの Wi-Fi は WPA3 を採用し、ゲスト用と業務用のネットワークを分離する。
アプリ側でできる最大の防御は「HTTPS を強制する」こと。b17(ホスティング)で AWS ACM と CloudFront による HTTPS 化を扱う。
よくある詰まりポイント
- 「Wi-Fi が 1 Gbps と表示されているのに実効速度が 200 Mbps しか出ない」のは通常のこと。電波の利用効率・干渉・共有端末数で実効帯域は理論値の 20〜50% になることが多い。
- Bluetooth Classic と BLE は互換性がない。イヤホンは Classic、Apple Watch のような低消費電力機器は BLE、と用途で分かれる。
- PoE は便利だが、給電能力(PoE/PoE+/PoE++)と消費機器のワット数が合わないと動かない。カメラやアクセスポイントを導入する際は双方のスペックを確認する。
- 5G は「速い」印象が強いが、低レイテンシ と 多数接続 も主要な特徴。IoT や工場自動化の文脈では後者が重要になる。
参考リソース
- Wi-Fi Alliance — Wi-Fi 世代一覧
- Bluetooth SIG — 公式仕様
- Cloudflare Learning — How does the internet work?
- AWS — What is a data center?
- 『マスタリング TCP/IP 無線 LAN 編』(オーム社)— 日本語で無線 LAN を体系的に学べる
確認クイズ
Q1. データセンターの PUE が 1.5 とはどういう意味か。 A. IT 機器の 1.5 倍の電力を使っている B. IT 機器の消費電力の 1.5 倍が施設全体の消費電力 C. 冷却効率が 1.5 倍 D. 電力料金が 1.5 倍
正解: B. IT 機器の消費電力の 1.5 倍が施設全体の消費電力
解説: PUE(Power Usage Effectiveness)は「総消費電力 ÷ IT 機器の消費電力」で定義される。1.0 が理想だが、冷却や照明などの補助電力が必ず必要なため、実際は 1.1〜1.8 の範囲に収まる。低いほど省エネなデータセンター。
Q2. PoE(Power over Ethernet)の用途として代表的なものはどれか。 A. データセンター内のサーバー間通信 B. 家庭用のスマートフォン充電 C. 監視カメラ・Wi-Fi アクセスポイントの設置 D. 5G 基地局の電源
正解: C. 監視カメラ・Wi-Fi アクセスポイントの設置
解説: PoE は LAN ケーブル 1 本で通信と電力供給を両立できるため、天井や壁に設置する機器(監視カメラ・アクセスポイント・IP 電話)で広く使われる。電源工事が不要になるメリットが大きい場面。
Q3. Wi-Fi の 2.4GHz 帯と 5GHz 帯の違いを説明せよ。
正解: 2.4GHz は遠くまで届きやすく壁を越えやすい反面、電子レンジや Bluetooth などと干渉しやすい。5GHz は高速で空いているが壁で減衰しやすく遠距離に弱い。
解説: 周波数が低いほど電波は回り込みやすく遠くまで届く性質がある。高い周波数ほど直進性が強くなる代わりに帯域を広く使えて高速になる。用途によって使い分けるのが一般的。
Q4. Bluetooth Classic と Bluetooth Low Energy(BLE)の最大の違いは何か。
正解: 消費電力。Classic は音声ストリーミングなど継続的な通信向けで電力を多く使うが、BLE は間欠通信で極めて低消費電力であり、コイン電池で数年動く機器を実現できる。
解説: Classic はワイヤレスイヤホンのようなリッチな通信、BLE は血圧計・心拍計・Apple Watch の通知のような省電力が重要な機器で使い分けられている。互換性はないため、機器選定時に用途を見極める必要がある。
Q5. モバイル回線で 4G から 5G に進化したことによる主な利点はどれか。 A. 速度の向上のみ B. 速度・低レイテンシ・多数接続の 3 点 C. 消費電力の低下 D. 通信料金の低下
正解: B. 速度・低レイテンシ・多数接続の 3 点
解説: 5G の 3 大特徴は eMBB(高速大容量)・URLLC(超低遅延)・mMTC(多数同時接続)。Web アプリでは低レイテンシが UX 改善に、多数接続は IoT で効く。速度だけが利点だと誤解されやすい点。
Q6. ユーザーが移動するモバイルアプリで考慮すべき点はどれか。
正解: Wi-Fi から 4G/5G へ切り替わる瞬間に IP アドレスが変わるため、再接続ロジックとリトライ設計が必要。
解説: WebSocket などの永続接続は IP が変わると切断される。TCP の接続も再確立が必要になるため、楽観的 UI・オフライン対応・再送制御を織り込んでおくことでユーザー体験を損ねずに済む。
Q7. エッジコンピューティングが解決しようとしている根本的な問題は何か。
正解: 光速による物理的なレイテンシの下限。地球の裏側との通信は片道 66ms が理論下限となるため、ユーザーに近い場所で処理することでこれを回避する。
解説: 光速は縮められない。そのため「距離そのものを短くする」のがエッジの本質。CDN は静的リソースを、エッジコンピューティングは計算そのものをユーザーに近い場所へ配置する。
Q8. 公衆 Wi-Fi での通信が危険といわれる主な理由と、アプリ側でできる最大の防御策を答えよ。
正解: 理由は電波が空間を飛ぶため同じ Wi-Fi にいる攻撃者が盗聴できる点にある。最大の防御策はすべての通信を HTTPS 化することで、Wi-Fi 層の盗聴を無効化できる。
解説: WPA3 暗号化のない Wi-Fi でも HTTPS で通信していれば、攻撃者にはランダムなバイト列しか見えない。HSTS を併用することで最初の HTTP リクエストも発生させないよう防御を完全にする。
Q9. Wi-Fi の実効速度が理論値より大幅に低くなる主な理由はどれか。 A. 暗号化処理のオーバーヘッド B. 電波の利用効率・干渉・共有端末数 C. ルーターの CPU 性能 D. ISP の帯域制限
正解: B. 電波の利用効率・干渉・共有端末数
解説: Wi-Fi は有限な周波数帯を複数端末で共有するため、接続台数・干渉源の多さ・壁による減衰で実効帯域が理論値の 20〜50% になるのが普通。オフィスの混雑時に遅くなるのはこれが主因。
Q10. 本章の内容のうち、本カリキュラムで構築する SNS アプリの開発・運用に直接関わるものはどれか。
正解: HTTPS の徹底(Wi-Fi 層の盗聴対策)と、CDN(エッジ)の活用によるレイテンシ改善。
解説: Ethernet の規格や Bluetooth の詳細は SNS アプリには直接関わらない。しかし、HTTPS と CDN の選択は物理層の制約に由来する設計判断なので、本章の知識が判断材料になる。b17(ホスティング)で実装を扱う。
生きているコード
本ドキュメントで扱ったパターンの完全な動作コードは、メンター側リポジトリの参照ブランチで確認できます。
- 対応 Week: W2
- 参照ブランチ:
- W2:
reference/week-2 - 対応 checklist 項目: (直接対応なし)
ブランチの作り方・見方は b00-curriculum-map を参照してください。
- 1. 📄Web とは何か
- 2. 📄URL を打ってから画面が表示されるまで
- 3. 📄ネットワーク基礎(TCP/IP・DNS・HTTPS)
- 4. 📄【発展】物理層から通信が成立するまで(電力・Ethernet・Wi-Fi・Bluetooth)
- 5. 📄WSL2・Docker セットアップ詳細(Windows 向け)
- 6. 📄環境構築の段階的導入(macOS / Windows)
- 7. 📄カリキュラム全体マップ(Week × 教材 × 参照ブランチ × 要求チェックリスト)
- 8. 📄このカリキュラムの使い方(SQL・Python・Dify経験者向け)
- 9. 📄シェル・ターミナル基礎
- 10. 📄Windows で完全にゼロから始める開発環境構築(Week 1)
- 11. 📄Git基礎
- 12. 📄GitHubワークフロー
- 13. 📄パッケージ管理(pnpm workspace)
- 1. 📄AWSインフラ基礎
- 2. 📄AWS Budget Alert の設定(Month 5 Week 17)
- 3. 📄環境変数管理
- 4. 📄Bastion EC2 と SSH ProxyJump(Month 5 Week 18)
- 5. 📄CI/CD基礎
- 6. 📄ECR への Docker イメージ push と App EC2 デプロイ(Month 5 Week 19)
- 7. 📄テスト設計の基本
- 8. 📄CloudFront + S3 + ALB で公開する(Month 5 Week 20)
- 9. 📄CLAUDE.md・プロジェクト設定
- 10. 📄PR レビュー 5 観点ルーブリック(全 Week 共通)
- 11. 📄タスク分解・仕様の書き方
- 12. 📄Playwright で E2E テスト(Month 6 Week 22)
- 13. 📄生成コードのレビュー・デバッグの勘所
- 14. 📄Trivy で脆弱性スキャン(Month 6 Week 23)
- 15. 📄CloudWatch Logs の読み方と運用(Month 6 Week 23)
- 16. 📄PDF ポートフォリオの自動生成(Month 6 Week 24)