初心者向け

🚀 はじめに この記事でわかること 「証明書（SSL/TLS証明書）とは何か？」の基礎 ブラウザが「このサイトは本物だ」と判断する仕組み 証明書がないと何が危険なのか HTTPS の理解につながる最初の一歩 ✅ 概要解説 証明書とは何か？ 一言でいうと、 「このサイト（通信相手）は本物ですよ！」と証明する身分証明書のようなもの です。 ブラウザ（Chrome、Safari、Edge など）は、Web サイトにアクセスするときに必ず 「本当にそのサイトと通信しても大丈夫？」 と確認します。 そのとき使われるのが SSL/TLS 証明書 です。 何のためにあるのか？ 証明書には主に 2つの役割があります。 相手の正体（サイトの運営者）を確認する → 「このサイトは“本物の example.com” だよ」と証明 通信を暗号化するための“鍵”を安全に交換する → 誰にも見られないように、暗号化の準備をする つまり証明書は “信頼の証” と “暗号化の鍵の受け渡し” を同時に行う仕組み と言えます。 証明書がないとどうなる？ ブラウザのアドレスバーに ⚠️「保護されていない通信」 と出る パスワードや住所などの入力情報が 盗まれやすくなる サイトを装った偽物（フィッシング）に騙される可能性が上がる とくに Wi‑Fi（カフェ・学校など）では 盗み見リスクが大幅に増える どんな場面で使われている？ 実はあなたがスマホを使っているほぼ全ての場面で活躍しています。 ネットショッピング SNS（X、Instagram、TikTok） Gmail や Outlook などのメール オンライン授業、Web 会議 銀行や政府系サイト いまや Web サイトの 90％以上は HTTPS（証明書あり）で通信 しています。 ※HTTPS = 証明書を使った暗号化通信の仕組み ...

🚀 はじめに この記事でわかること TLS/SSL（ティーエルエス／エスエスエル）がどんな役割をしているのか https がなぜ「安全」と言われるのか 初心者でも理解しやすい身近なたとえで“暗号化”のイメージがつく ✅ 概要解説 TLS/SSLとは何か 一言で言うと、 あなた（ユーザー）とサイトの間でやり取りする情報に「鍵をかける」仕組み です。 インターネットでは、文字や画像などのデータが世界中のネットワークを通って移動します。その途中で、悪い人が盗み見ようとする可能性があります。 TLS/SSL は、その情報を暗号化（第三者が読めなくなる状態） にし、改ざんされていないかもチェックします。 「https://」から始まるサイトは、この TLS/SSL が使われている安全な通信です。 何のためにあるのか TLS/SSL には主に 3 つの役割があります。 盗み見防止（暗号化） メッセージを「暗号文」に変えて送るため、途中で盗み見られても読めません。 なりすまし防止（証明書） 本物のサイトかどうかを証明する「Web サイトの身分証明書」が使われます。 改ざん防止 途中でデータが書き換えられていないかチェックできます。 TLS/SSL がないとどうなるのか もし TLS/SSL が無いと… あなたの入力したパスワードが丸見え クレジットカード番号も盗まれるリスク 偽サイトに誘導されても気付きにくい 途中でデータを書き換えられても気付けない つまり、安心してネットを使えなくなってしまうのです。 どんな場面で使われる？ ログインページ（ID / パスワード入力） ネットショッピング（クレジットカード情報） お問い合わせフォーム メールサービス Web API・アプリ間通信 など 今では、ほぼすべての Web サイトで TLS/SSL が標準です。 💡 小話・豆知識・逸話 1) SSL は“古い名前”、いまは TLS が正式 「SSL」という言葉は昔の規格の名前ですが、世の中には今も「SSL 証明書」という言葉が残っています。 実は、技術的には「TLS」が現在の正式名称です。 でも「SSL のほうが聞き覚えがある」ため、いまだに広く使われています。 2) 暗号化は「鍵付きの手紙」 手紙を例えると… ...

🚀 はじめに この記事でわかること DNS（Domain Name System）がどんな役割を持つのか ドメイン名 → IPアドレスの変換がどう行われているか DNS がないとインターネットはどう不便になるのか DNS を理解すると Webがどう見えやすくなるか ✅ 概要解説 DNSとは何か？ DNSは“インターネットの住所録（電話帳）”のような仕組みです。 Google → google.com YouTube → youtube.com 私たちは普段、こうした文字の名前（ドメイン名） を入力してサイトにアクセスしますよね。 しかし、コンピュータが通信できるのは 192.0.2.1 のような数字（IPアドレス） だけ。 そこで必要なのが… DNS：ドメイン名 ⇔ IPアドレス の変換係 あなたが文字で書いた住所（ドメイン）を、 実際の家の場所（IPアドレス）に案内する役目です。 何のためにあるのか？ DNSがあることで、次のメリットが生まれます： 覚えやすい文字の名前でアクセスできる → 「2404:6800:4004:81a::200e」を覚えずに済む Webサイトの引っ越しが簡単 → サーバーが変わっても“住所録”を書き換えるだけ 世界共通のルールで案内できる DNSがないとどうなるの？ DNSがなければ、インターネットはとても不便になります。 毎回 数字のIPアドレスを丸暗記しないとアクセスできない サイトが移転するたびに 新しい数字を覚え直す必要がある そもそも URLを共有するのが難しい よく考えると、DNSがあるからこそ 「google.com を開いて」と言えるわけです。 どんな場面で使われているのか？ DNSは見えないところで、実はほぼ毎日働いています。 Webブラウザでサイトを開くとき スマホアプリがサーバーと通信するとき メールを送受信するとき 家庭のWi-Fiルータが通信先を調べるとき つまり、 インターネットが動く＝ほぼ確実にDNSが働いている というくらい重要な存在です。 💡 小話・豆知識・逸話 ① DNSは「階層」でできている DNSの仕組みは“町 → 市 → 都道府県 → 国”のような階層構造。 トップには 「.com」「.jp」「.net」などのトップレベルドメイン（TLD） がいます。 ...

🚀 はじめに この記事でわかること Terraformの設計の全体像（フォルダの切り方・モジュールの作り方・環境（dev/stg/prod）の分け方・ステート管理） なぜ設計が大事か、そしてよくあるつまずきポイントを先回りで回避する考え方 すぐ試せる最小サンプルと、次に学ぶと良い道しるべ ✅ 概要解説 Terraformの“設計”とは何か ざっくり言うと、レゴの設計図のことです。 どんな箱（フォルダ） に、どの部品（モジュール） を入れて、街（環境） ごとにどう並べ替えるか。 さらに、完成写真（状態＝ステート） をどこに保管するかを決めるのが設計です。 フォルダ構成… 作る物（ネットワーク・DBなど）と、使う場所（dev/stg/prod）をどう分けるか モジュール設計… レゴの「何度も使える下ごしらえ」パーツ化 ステート管理… いまの完成形（状態）を安全に記録・共有する 運用フロー… 変更はどうレビューして、どう適用（apply）するか ポイント：設計がきれいだと、「増築」「引っ越し」「片付け」がラクになります。 何のためにあるのか（設計が大事な理由） 事故を防ぐ（削除ミス・上書きミス・人によるバラつき） 再利用が効く（同じ作りを別環境で素早く展開） レビューしやすい（どこが変わるか差分が読みやすい） チームで回せる（誰が触っても同じルールで動く） 設計がないとどうなるの？ ぐちゃぐちゃに成長して壊すのが怖い（どこに何があるか不明） 環境ごとの差が増え、“本番だけ違う”地雷が生まれる ステートが人のPCにだけある → 事故・紛失・衝突（同時更新） レビューが困難 → ミスが見抜けず「動いたらOK」文化に逆戻り どんな場面で役立つ？ 個人の学習〜小さなチーム：まずはフォルダとモジュールを整えるだけで運用が楽に 複数クラウド・複数環境：再利用とステートの分離で安全にスケール 長期運用：CI/CD、Lint、セキュリティチェックを足して “壊れにくい仕組み” に 🧱 設計の基本パターン（フォルダ構成） A. “live + modules” 方式（いちばん読みやすい定番） repo-root/ ├─ modules/ # 再利用する部品置き場（レゴのパーツ箱） │ ├─ storage-bucket/ # 例: S3バケットを作るモジュール │ │ ├─ main.tf │ │ ├─ variables.tf │ │ └─ outputs.tf │ └─ ... # 他にも vpc/, rds/, dns/ など増やす └─ live/ # 実際に使う“現場”の設計図（街ごと） ├─ dev/ │ └─ app/ # サブシステム単位で分けてもOK │ ├─ main.tf │ └─ terraform.tfvars ├─ stg/ │ └─ app/ └─ prod/ └─ app/ modules/：何度も使える部品（バケット、VPCなど） live/：実際の環境（dev / stg / prod）側の呼び出し メリット：見通しが良く、レビューしやすい。環境を複製するのも簡単。 ...

🚀 はじめに この記事でわかること Terraform と Ansible の役割の違い（何を自動化するツール？） ないと何が大変？あると何が楽？ の具体例 超シンプルな実践チュートリアル（ローカルで安全に“雰囲気”を体験） 次に学ぶと良い関連テーマ ✅ 概要解説 Terraform・Ansibleとは何か 一言でいうと： Terraform = 「家（インフラ）を建てるための設計図と職人の指示書」 Ansible = 「建った家の中（サーバーの中身）を整える家事代行・内装業者」 Terraform（テラフォーム） クラウド（AWS/Azure/GCPなど）にサーバー、ネットワーク、ストレージといった “土台”を作る ツール。 “コード（HCL） でインフラを宣言”すると、そのとおりに作る／壊す／差分更新してくれます。 ＝ IaC（Infrastructure as Code） の代表選手。 Ansible（アンシブル） できあがったサーバーにソフトを入れる・設定を変える・ファイルを置くなどの “中身の整備”を自動化。 “プレイブック（YAML）”に手順を書くと、複数台に一気に同じ状態をつくってくれます。 ＝ 構成管理ツール の代表選手。 何のためにあるのか 人手の作業ミスを減らし、同じ結果を何度でも作れるようにするため 構築・設定のスピードアップ（環境差やメモ忘れをなくす） 設計や履歴がコードとして残るので、引き継ぎや再現が簡単に ないとどうなるの？ 手作業のクリックやコマンドが増え、うっかり設定漏れが発生 何が違って不具合なのか、“差”が追えない（再現が難しい） 人依存になりやすく、忙しい時ほど時間が溶ける どんな場面で使えるの？ Terraform： AWSで「EC2（サーバー）1台＋セキュリティ設定」を毎回安全に作る Azure/GCPでネットワーク＋VM＋ストレージの組み合わせを使い回したい 検証環境を作って壊すを何度も繰り返す Ansible： サーバーにNginxやApacheをインストールして同じ設定にする ユーザー追加・ログ設定・アプリ配布などの日常運用を自動化 10台・100台のサーバーに一気に同じ変更を適用 まとめ：Terraformは“外観と土台”、Ansibleは“内装と日々の暮らし” を整える役割と考えるとスッキリします。 💡 小話・豆知識・逸話 “宣言的”と“手続き的” Terraformは宣言的：「最終的にこうなっていてほしい」を書きます。 Ansibleも基本は宣言的ですが、タスクを順番に並べる手続き的な側面もわかりやすいです。 ⇒ “最終形を宣言”して、必要な操作はツールが計算してくれるのが気持ちよさの源。 手で作る→壊せない問題 人がクリックで作ったリソースは、どこで作ったか忘れがち。 Terraformで作れば terraform destroy で綺麗にお片付けできます。 ...

🚀 はじめに この記事でわかること 共有責任モデル（Shared Responsibility Model）が何か クラウドで 「どこまでがクラウド事業者」「どこからが自分の責任」 なのか もし誤解するとどうなるか、そして実際に何を気をつければよいか ✅ 概要解説 共有責任モデル（Shared Responsibility Model）とは何か クラウドを「マンション暮らし」にたとえるとわかりやすいです。 管理会社（クラウド事業者）は、建物そのもの（土台・エレベーター・廊下・防犯カメラ）を安全に保つ責任があります。 住人（あなた／あなたの会社）は、自分の部屋の鍵・窓・貴重品管理・家のルールを守る責任があります。 クラウドも同じで、土台のハードや電源、建物の入り口の警備（＝クラウド基盤） は事業者が守ります。でも、部屋の鍵（パスワード）、窓締め（設定）、貴重品の置き方（データの扱い） はあなたの責任です。 この分担ルールを、業界では 「共有責任モデル」 と呼びます（AWS・Azure・Google Cloud など大手はすべて採用）。 何のためにあるのか 誤解を防ぐため： 「クラウドに置けば全部安全でしょ？」というよくある誤解をなくし、誰が何を守るのかを明確にするため。 責任の分担を決めるため： セキュリティ事故が起きたとき、どの範囲を誰が対処するかをはっきりさせて、再発防止まで辿りやすくするため。 共有責任モデルがないとどうなるの？ 「誰の仕事？」があいまいになり、パスワード管理やアクセス制御の穴が放置されやすい 設定ミス（例：ストレージの公開設定ミス） による情報漏えいが増える 事故後に 「想定外だった」「聞いてない」 で対立し、復旧や改善が遅れる 実際、クラウドの事件で多いのは “土台の故障”ではなく、利用者側の設定ミスや認証管理の不備です。 共有責任モデルは、こうした “もったいない事故” を減らします。 どんな場面で使えるのか（サービス別のイメージ） クラウドの種類が変わると、分担の境界も少しずつ変わります。 IaaS（仮想サーバー等 / 例：Amazon EC2、Azure VM） 事業者：物理設備・ネットワーク・ハイパーバイザーなどの土台 あなた：OS設定・パッチ・ミドルウェア・アプリ・データ・ユーザー管理 PaaS（アプリ基盤 / 例：Azure App Service、Cloud Run） 事業者：OS〜ランタイムまで面倒を見る あなた：アプリ設定・コード・データ・ID/権限 SaaS（完成アプリ / 例：Google Workspace、Microsoft 365） 事業者：アプリ本体・基盤 あなた：利用者アカウント・多要素認証・共有設定・データ分類 まとめ：基盤に近いほど（IaaS）あなたの守備範囲は広く、完成品に近いほど（SaaS）狭くなります。 💡 小話・豆知識・逸話 「クラウドは“安全”だが“無敵”ではない」 大手クラウドは世界有数のセキュリティ投資をしています。ただし、それは土台の品質が高いという話。 パスワードの使い回しや公開設定ミスは、借り手（利用者）側の問題で、ここが事故の主因になりがちです。 ...

🚀 はじめに この記事でわかること サーバーレスとFaaS（Function as a Service） の意味と違い AWS Lambda / Google Cloud Functions / Azure Functions などの役割と使いどころ コストの考え方（使った分だけ課金）、コールドスタート、トリガーなどの基本用語 まず触ってみるための超ミニ手順・サンプルと、次に学ぶテーマ ✅ 概要解説 サーバーレス / FaaSとは何か 例えると、「必要なときだけ呼べる出前のシェフ」。 キッチン（サーバー）を自分で準備・片付けせず、料理（処理）を注文した瞬間だけ来て、終わったら帰るイメージです。 サーバーレス（Serverless） サーバーが「ない」わけではなく、サーバーの面倒（用意・更新・故障対応・伸縮）をクラウド側が隠してくれる考え方。 Web/API、データベース、認証、ストレージなど “組み合わせて作る”設計を指すことが多い広い言葉。 FaaS（Function as a Service） サーバーレスの中でも 「関数（小さなプログラム）」単位で実行する仕組み。 代表例：AWS Lambda / Google Cloud Functions / Azure Functions。 イベントが起きた瞬間だけコードが起動し、使った分だけ課金されます。 かんたんな全体像 [イベント] ──▶ [関数(コード)] ──▶ [結果/保存/通知] │ │ ├ HTTP リクエスト(API Gateway等) ├ スケジュール(毎日9時 etc.) ├ ストレージの更新(画像アップ時) └ キュー/メッセージ(非同期処理) ・常時サーバー起動なし（クラウドが必要時に起動） ・終わったら停止（課金も止まる） 何のためにあるのか（うれしいポイント） 運用がラク：OS更新、サーバー台数の増減、セキュリティパッチなど面倒ごとを任せられる コスト最適：使った分だけ課金（リクエスト数・実行時間・メモリ量で計算） 自動スケール：アクセス急増時も自動で並列実行が増える 小さく始めやすい：1ファイルの関数からすぐ動く。PoCや試作に最適 サーバーレス / FaaSが「ない」とどうなる？ 24時間サーバーを自前で運転：電源・監視・更新・バックアップ・伸縮など全部自分事 コストが固定化しがち：使わなくてもサーバー費が発生 急なアクセスに弱い：スケール設計ミスで落ちやすい（手動で増強は間に合わない） どんな場面で使える？ 画像の自動処理：アップロードされた写真を自動でリサイズ/サムネ生成 通知・連携ボット：フォーム送信→Slack/Teams通知、カレンダー連携 スケジュール作業：毎朝9時にレポート集計、夜間のデータ整理 APIの裏側：問い合わせフォーム→メール送信＋DB保存 イベント駆動の業務フロー：受注→在庫引き当て→請求書発行→メール 💡 小話・豆知識・逸話 「サーバーがない」わけじゃない サーバーレスは “サーバーの存在を意識しないで良い” という意味。実際はクラウド側の大量のサーバーが裏で動いています。 ...

🚀 はじめに この記事でわかること IaaS / PaaS / SaaS の意味と違いが、専門用語なしでスッと理解できます それぞれをいつ使うと便利か、使わないと何が困るかがイメージできます 初めての人でも、自分の用途に合う選び方のヒントが得られます ✅ 概要解説 クラウドとは何か インターネット越しに「必要なときだけ、必要な分だけ」コンピュータの力（サーバー・ソフト）を場所を選ばず使える仕組みです。 自分でサーバーを買って部屋で動かすのではなく、世界のどこかにある大規模な設備をオンラインで“貸し借り” します。 使った分だけお金を払う電気・水道のような料金が基本。 すぐに増やしたり（スケール）減らしたりできる柔軟さが魅力です。 IaaS / PaaS / SaaS の違い（ひとことで） IaaS（あいあーす）：サーバーそのものを借りる（建物の“骨組み”） PaaS（ぱーす）：アプリが動く土台を借りる（“キッチン付き賃貸”） SaaS（さーす）：完成したアプリをそのまま使う（“レストランで食べる”） 生活のたとえ（持ち家・賃貸・ホテル） 持ち家（オンプレミス）：土地から全部自分で用意・管理 賃貸（IaaS）：建物は用意済み、内装や家具（OS・アプリ）は自分で用意 家具付き賃貸（PaaS）：料理できるキッチンや家電（ランタイム／DB）までセット ホテル（SaaS）：入ったらすぐ使える（アカウント作成だけ） 何のためにあるのか 速く始められる：物理機器の準備が不要。思い立ったら即スタート ムダが少ない：使った分だけ支払い。余りや不足を減らしやすい 運用がラク：ハード故障対応、停電対策、冗長化など重い作業はクラウド側が担当 世界展開しやすい：世界中の拠点から近い場所で提供できる クラウドがないとどうなる？ 初期費用が大きい：サーバー・ネットワーク機器を最初に一括で購入 使わない時も維持費がかかる：電気・スペース・保守契約など 急なアクセス増に弱い：必要になってから機器を増やすのは時間もコストも重い 障害対応が大変：停電・故障・災害対策を自前で担う必要 どんな場面で使える？ IaaS：OSやミドルウェアを自由にカスタマイズしたい、既存システムをなるべくそのまま移したい 例）Amazon EC2 / Azure Virtual Machines / Google Compute Engine PaaS：アプリ開発に集中したい、サーバー管理やパッチ適用を減らしたい 例）Azure App Service / Google App Engine / AWS Elastic Beanstalk / Heroku ...

🚀 はじめに この記事でわかること ポート番号が何のためにあるか（＝同じ住所の中の部屋番号のような役割） TCP と UDP の違い（配達の“受取サインあり/なし”の違い）と、それぞれが得意な場面 実生活のたとえ・図・簡単な表で、難しい数式なしに全体像をつかむ ✅ 概要解説 ポート番号とは何か 住所（IPアドレス）＋部屋番号（ポート）＋会話ルール（プロトコル） がそろって、はじめて正しいアプリへ届きます。 IPアドレス＝建物の住所 ポート番号＝建物の中の部屋番号（0〜65535の番号） プロトコル＝会話ルール（TCPかUDPが代表） 同じパソコン（同じ住所）でも、Webは「部屋 80/443」、メールは「部屋 25/587/993」など、アプリごとに部屋が違うから、迷子にならずに届きます。 TCP と UDP は何が違う？ 配達のイメージでいうと TCP＝“受取サイン付きの宅配便”（確実・順番通り・再送あり） UDP＝“ポスト投函のはがき”（速い・軽い・ただし届いた保証はない） 項目 TCP UDP 目的 確実に届ける・順番を保つ 速く軽く届ける（保証なし） 使いどころ Web（HTTP/HTTPS）、メール、ファイル転送 など 音声/動画通話、オンラインゲーム、DNS など 仕組み 通信前に握手（3ウェイハンドシェイク）して、欠けたら再送 握手しない。欠けても再送しないのが基本 体感 信頼性重視、多少遅くても正確 即応性重視、途切れに強い ポート番号は何のためにあるのか 同じPC（住所）で複数のサービス（部屋）を同時に動かすため ファイアウォールやNAT（ルーター） で、どの部屋に通すかを管理するため 世界共通の “よく使う部屋番号（ウェルノウンポート）” が決まっているため 例：80/tcp（HTTP）, 443/tcp（HTTPS）, 53/udp（DNS）, 25/tcp（SMTP） など もしポートとプロトコルがなかったら？ 配達先が曖昧：住所まで来てもどの部屋か分からず、正しいアプリに届かない 会話が通じない：違う言語（プロトコル）で話してしまい、理解不能 安全に振り分けられない：ファイアウォールも通す/止めるが判断できず、セキュリティが崩れる どんな場面で役立つ？ インターネットの不調の原因探し：「このアプリ、どのポートを使うんだっけ？」が分かる 自宅ルーターの“ポート開放”：オンラインゲームや自宅サーバー公開の基本のキ 会社のセキュリティ運用：特定ポートだけを許可して安全に業務アプリを通す 💡 小話・豆知識・逸話 どうして 0〜65535？ ポート番号は16ビット（2^16＝65536通り）。0〜1023は“ウェルノウンポート”と呼ばれ、代表的なサービスに割り当てられています。 代表的な“部屋番号”の一覧（よく出る） ...

🚀 はじめに この記事でわかること DHCPとは何か（何の略？何をしている？） 使うと何が良いのか（設定不要・トラブル減・管理が楽） もしDHCPがなかったらどうなるか（手動設定の大変さ／事故の原因） 家・学校・職場での具体的な使われ方と、次に学ぶとよい関連テーマ こんな人向け 中学生〜大人まで、IT知識がほとんどない人 「IPアドレス？難しそう…」と思っている人 Wi‑Fiがつながる仕組みを、やさしく全体像で知りたい人 初心者でも安心な理由 難しい専門用語は身近なたとえとイラストのイメージで説明 このページだけで完結（最後に信頼できる参考リンクもまとめ） まずはIPv4の基本→必要に応じてIPv6も軽く触れます ✅ 概要解説 DHCPとは何か Dynamic Host Configuration Protocol の略。 直訳すると「機器の設定（IPなど）を自動で配る約束ごと」。 たとえるなら、新学期の“座席表配布係”。 教室（ネットワーク）に新しい生徒（スマホやPC）が入ってきたら、 席番号（IPアドレス） 連絡先（DNSサーバー） 教室の出口（デフォルトゲートウェイ） などを、自動で割り当ててくれる係です。 IPv4の基本の流れ（DORA） Discover（さがす）：端末「誰か席を決めて〜！」（放送） Offer（提案）：サーバー「この席どう？」（提案） Request（希望）：端末「その席でお願いします！」（希望） Ack（確定）：サーバー「じゃあ、その席に決定！」（確定） 補足：IPv6 では似た流れ（Solicit / Advertise / Request / Reply）や、SLAAC（ルーターがアドレス作成のヒントを配る方式）もあります。 何のためにあるのか ラク：スマホやPCをWi‑Fiにつなぐだけで、IPアドレスなどを自動設定 安全：手入力ミスやIPアドレスの重複（ぶつかり事故） を防ぎやすい 管理が簡単：学校・会社では誰がどの席（IP） を使っているか、貸出期限（リース） も含めて把握・制御しやすい リース（lease）：席を 「○時間だけ」 貸すイメージ。期限が来たら更新（延長）します。 DHCPがないとどうなるの？ 端末ごとにIPアドレス、サブネット、ゲートウェイ、DNSを手で入力 うっかり同じアドレスを重複設定→通信が不安定になることも 人数（台数）が増えると管理が破綻しやすい 臨時イベントや教室の入れ替えなど、出入りが激しい場面で特に大変 どんな場面で使えるの？ 家庭のWi‑Fi：ほとんどの家庭用ルーターがDHCPサーバーになります 学校・オフィス：Windows Server / Linux（ISC Kea など） がDHCPサーバー役 大きな建物：フロアごとにネットワークが分かれていても、DHCPリレー（中継） で配布可能 IoT/プリンター：台数が多い機器の初期設定も差し込むだけでOK 用語ちょい足し ...