第6章 Webとインターネット
この章のねらい 私たちが毎日使っている「ホームページを見る」「クラウドにデータを預ける」といった仕組みが、 裏側でどう動いているのかを学ぶ章です。経営情報システムの中でも、この分野は毎年3〜5問と 出題数がとても多く(対応過去問は47問)、しかも用語の意味さえ正確に覚えれば得点できる問題が中心です。 難しい計算はほとんどありません。得点源にすべき最重要分野です。
過去問での出方:大きく4つのかたまりで出ます。①Webの基礎の仕組み(HTTP・HTML・CSS・URL・Cookie)、 ②クラウドコンピューティング(IaaS/PaaS/SaaS・パブリック/プライベート・責任共有モデル)、 ③電子商取引とWebサービス(API・REST・CMS・レスポンシブ・Webマーケ指標)、 ④IoT・モバイル・新技術。特にクラウド関連は近年ほぼ毎年出ており、最優先で固めましょう。 ※ IT技術は移り変わりが速いため、古い問題の表現には「※現在は」と注記を入れています。
6-0 この章の地図
この章は、「Webページが表示される仕組み」という土台から始めて、 「それをサービスとして借りる(クラウド)」「商売に使う(EC・Webサービス)」 「モノやスマホにつなげる(IoT・モバイル)」へと、外側に広がっていきます。
6-1 Webの仕組み … HTTP/HTTPS・HTML/CSS・ブラウザ・URL・Cookie
│ (★最頻出。ここが土台)
│
6-2 クラウドコンピューティング … IaaS/PaaS/SaaS・パブリック/プライベート
│ (★近年ほぼ毎年。責任共有モデルに注意)
│
6-3 電子商取引とWebサービス … EC・API/REST・CMS・レスポンシブ・効果測定指標
│
6-4 IoT・モバイル・新技術動向 … IoT・エッジ・LPWA・MDM・AR/VR
まずは6-1で「クライアントとサーバがやり取りしている」という基本の絵を頭に入れると、 以降がすべてその応用として理解できます。
6-1 Webの仕組み
まず全体像:クライアントとサーバの「お願い」と「返事」
Web(World Wide Web)は、インターネット上で文書や画像をやり取りする仕組みです。 登場人物は2人だけと考えてください。
- クライアント:見る側。あなたのPCやスマホのブラウザ(Chrome・Safari・Edgeなど)。
- サーバ(Webサーバ):見せる側。ページのデータを保管し、求めに応じて送り出すコンピュータ。
この2人が、次のように「お願い(リクエスト)」と「返事(レスポンス)」を交わします。
【クライアント】 【Webサーバ】
ブラウザ (例: Apache)
│ │
│ ①「このページください」(リクエスト) │
│ ─────────────────────────→ │
│ │
│ ②「はいどうぞ」HTML・画像など(レスポンス) │
│ ←───────────────────────── │
│ │
③ 受け取ったHTMLをブラウザが解釈して画面に表示
この「お願い」と「返事」のルール(約束事)が、次に見るHTTPです。
📝 過去問はこう出る(R07 第4問) クライアントとサーバのデータ交換の用語を正誤判定する問題。正しいのは 「HTTPは、リクエストを送るクライアントとレスポンスを返すサーバが、HTML文書などをやり取りするために用いるプロトコル」と 「JSONはWebアプリのデータ交換で使われるデータ形式の1つ」。この2つを"正"と見抜ければ解けます。 → R07 第4問
HTTPとHTTPS ― Webの「通信ルール」
プロトコルとは「通信のときのお約束・手順」のことです。Webでは次を使います。
| 名称 | 読み | 中身 |
|---|---|---|
| HTTP | エイチティーティーピー | HyperText Transfer Protocol。Web文書(HTMLなど)をやり取りする基本ルール。暗号化されていない |
| HTTPS | エイチティーティーピーエス | HTTP over SSL/TLS。通信を暗号化したHTTP。盗み見・改ざんを防ぐ |
- 「https://」で始まるサイトは、通信内容が暗号化されています(SSL/TLSという技術を使用)。 クレジットカード番号やパスワードを送るページでは必須です。
- 「http://」(sが無い)は暗号化されていないので、重要情報のやり取りには不向きです。
💡 覚え方:HTTPS の S は Secure(安全)の S。「sが付いていれば鍵がかかっている」。
HTML ― ページの「骨組み」を作る言語
HTML(HyperText Markup Language)は、Webページの構造(骨組み)を記述する言語です。 「マークアップ」とは、タグという目印で文書に意味づけをすること。
<h1>見出しです</h1> ← 見出し
<p>これは段落です。</p> ← 段落
<a href="...">リンク</a> ← 別ページへのリンク(アンカー)
<img src="cat.jpg"> ← 画像(終了タグが不要な「空要素」)
<table>...</table> ← 表
HTMLの重要な特徴を、過去問で問われたポイントで押さえます。
- ① リンク(ハイパーリンク)機能:
<a>タグ(アンカー)で示した文字や画像をクリックすると、 別のページへ飛べる。これがHTMLの本質的な特徴です。 - ② タグは"開始と終了"の対が基本、ただし例外あり:多くのタグは
<p>…</p>のように対で書きますが、<br>(改行)・<img>(画像)・<hr>(区切り線)のように終了タグを持たない空要素もあります。 → 「必ず開始と終了を記述する」と一律に言うのは誤り(引っかけ)。 - ③ 色は約1,677万色:色はRGB各8ビット計24ビットで指定でき、約1,677万色を表現できます(「256種類」は誤り)。
- ④ 表はHTMLで作れる:
<table>タグで表を表示できます(「表の表示機能がない」は誤り)。 ※ ただしグラフ描画の機能は標準HTMLにはなく、スクリプトや画像で対応します。
📝 過去問はこう出る(H21 第4問) HTMLの特徴を問う問題。正解は「HTMLにはリンク機能があり、アンカーで示した文字や画像をクリックして 異なるページを表示できる」。「タグは必ず開始と終了が必要」「色は256種類」「表の表示機能がない」は すべてHTMLの事実に反する誤りです。 → H21 第4問
CSS・JavaScript ― 「見た目」と「動き」を足す
HTMLだけでは、文字と画像が素朴に並ぶだけです。そこに次の2つを組み合わせます。
| 言語 | 役割 | ひとことで |
|---|---|---|
| HTML | 構造(骨組み) | 何を書くか(見出し・段落・表) |
| CSS | 見た目(装飾) | どう見せるか(色・大きさ・配置・レイアウト) |
| JavaScript | 動き(動作) | クリックで反応する・入力チェックなど、ブラウザ側で動く処理 |
- CSS(Cascading Style Sheets):デザイン(色・フォント・レイアウト)を指定する言語。 HTMLから見た目の指定を切り離すことで、修正がラクになります。
- JavaScript:ブラウザ(クライアント側)で動くスクリプト言語。ページに動きや対話性を与えます。 ※ 名前が似ていますが、サーバ側で動く「Java」とは別物です(混同注意)。
これらを組み合わせて動きのあるページを作る手法は、古くはDHTML(Dynamic HTML)と呼ばれました。 また、Ajax(Asynchronous JavaScript + XML)は、サーバと非同期通信を行い、 画面全体を書き換えずに一部だけ動的に更新する手法です(地図をスクロールしても全体が再読込されない、あの仕組み)。
📝 過去問はこう出る(H23 第7問) 用語と説明の対応を問う問題。「HTML+JavaScript+CSSで動きと対話性のあるページを作る」=DHTML、 「見出し・更新時刻などのメタデータをXML準拠で構造化して更新を伝える」=RSS、 「サーバと非同期通信し画面の全書き換えなしに更新」=Ajax。正解はこの3つが揃った組み合わせ。 なお Web2.0 は個別技術名ではなく"利用者参加型Web"という思想・概念の名前で、ここに混ぜると誤りになります。 → H23 第7問
URL ― Webページの「住所」
URL(Uniform Resource Locator)は、Web上の資源(ページ・画像など)の場所を示す住所です。 分解して読めるようになると、URLに関する問題は一気に解けます。
https :// news.example.co.jp / products / index.html
───── ──────────────── ─────────────────
スキーム ホスト名(ドメイン名) パス
(通信方式) (どのサーバか) (サーバ内のどこか)
- スキーム:先頭の
httpsやhttp。通信方式を表します。httpsなら暗号化されていることが分かります。 - ホスト名(ドメイン名):
news.example.co.jpのようにどのサーバかを示す名前。 - パス:
/products/index.htmlのように、そのサーバ内のどのファイルかを示します。
URLを読むときの注意点(過去問の急所):
- ドメイン名は大文字・小文字を区別しない:
News.Fishing.jpとnews.fishing.jpは同じサイトです。 「大文字小文字を入れ替えた偽サイト」とは判断できません。 - トップレベルドメイン(.jp など)は登録者の属性を示すが、サーバの物理的な設置場所を保証しない: 「.jp だからサーバが日本国内にある」とは断定できません。
📝 過去問はこう出る(R01 第8問) あやしいメールのURL
https://News.Fishing.jp/testから確実に読み取れることを選ぶ問題。 正解は「httpsなので通信が暗号化されていることが確認できる」。 「大文字小文字を入れ替えた偽サイト」(=ドメインは大小区別しないので誤り)、 「サーバが日本国内にある」(=.jpは設置場所を保証しない)、「wwwが省略されている」は いずれもURLだけからは断定できないため誤りです。 → R01 第8問
DNS・DHCP・NAT ― 住所を裏で支える3つの仕組み
URLの「住所」を実際に使える形にするために、裏側で働く仕組みが3つあります。頻出の3点セットです。
| 仕組み | 読み | 何をするか |
|---|---|---|
| DNS | ディーエヌエス | ドメイン名(住所の名前)とIPアドレス(数字の住所)を対応づける(名前解決) |
| DHCP | ディーエイチシーピー | LANにつないだPCへ、使うIPアドレスを自動で割り当てる |
| NAT | ナット | グローバルIP(外向け)とプライベートIP(社内向け)を変換する |
- DNSは「
example.jpという名前を、93.184.…という数字(IPアドレス)に翻訳する電話帳」とイメージすると分かりやすいです。 - DHCPがないと、PCをつなぐたびに手作業でアドレスを設定する必要があります。
- NATは、社内の多数のPCが少数のグローバルIPを共用してインターネットに出るための変換役です。
📝 過去問はこう出る(H23 第12問) 「名前とIPを対応づける」=DNS、「PCにIPを割り当てる」=DHCP、「グローバルIPとプライベートIPを変換」=NAT、 の対応を選ぶ問題。3つの役割を取り違えないことがポイントです。 → H23 第12問
Cookie(クッキー)とセッション ― 「同じ人だと覚える」仕組み
HTTPには、実は「前のやり取りを覚えていない」という性質があります(これをステートレスといいます)。 毎回が"初対面"だと、ログイン状態や買い物カゴを保てません。そこで使うのが次の2つです。
- Cookie(クッキー):Webサーバがブラウザに小さなデータを預けて保存させる仕組み。 次にアクセスしたときブラウザがそれを送り返すので、サーバは「あ、さっきの人だ」と分かります。 ログイン状態の保持、買い物カゴ、閲覧履歴に基づく広告などに使われます。
- セッション:一連の"つながった訪問"のまとまり。セッションIDという合言葉をCookieなどで受け渡し、 「同じ利用者の連続した操作」として扱います。
⚠️ 混同注意:Cookieは"預けるデータ"、セッションは"つながりのまとまり" Cookieは主にブラウザ側に保存される小さなデータ。セッションはそれを使って 「同じ利用者の一続きの利用」を管理する考え方です。Cookieはセッションを成り立たせる道具、と押さえましょう。
つまずきポイント:似た言葉の整理
- HTML=構造 / CSS=見た目 / JavaScript=動き。この3役割の取り違えが定番の引っかけです。
- Java(サーバ寄りの本格的言語)と JavaScript(ブラウザで動くスクリプト)は別物。名前だけ似ています。
- HTTP(暗号化なし)と HTTPS(暗号化あり)。sの有無で意味が変わります。
6-2 クラウドコンピューティング
クラウドとは ― 「自前で持たず、借りて使う」
クラウドコンピューティングとは、 インターネットを通じて、コンピュータの機能(サーバ・ソフト・保存領域など)をサービスとして借りて使う利用形態です。 自社でサーバを買って設置・運用する(オンプレミス)代わりに、必要な分だけ使って使った分だけ払う、という考え方です。
- メリット:初期投資が少ない/使った分だけ払う/機器の管理を任せられる/必要に応じて増減できる(拡張性)。
- 中小企業にとっては、少ない資金で高度なIT環境を使える点が大きな魅力です。
サービスの3階層 ― IaaS・PaaS・SaaS(★最頻出)
クラウドは「どこまでを事業者が用意してくれるか」で3つに分かれます。 下の図の「サービスとして提供される範囲」が、下から上へ広がっていくイメージです。
提供される範囲 ← 上にいくほど事業者が多く用意
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ アプリケーション │ │ アプリケーション │ │ アプリケーション │←SaaSはここまで全部
├─────────────┤ ├─────────────┤ │ (全部込み) │
│ ミドルウェア │ │ ミドルウェア │ │ │
│ OS │ │ OS ← PaaSは │ │ │
├─────────────┤ │ ここまで │ │ │
│ ハード/インフラ │←IaaSは │ │ │ │ │
│ (サーバ等) │ │ ここまで │ │ │ │ │
└─────────────┘ └─────────────┘ └─────────────┘
IaaS PaaS SaaS
(インフラ) (土台・実行基盤) (完成したソフト)
| 略称 | 正式名 | 提供される範囲 | たとえると | 利用者が用意するもの |
|---|---|---|---|---|
| IaaS | Infrastructure as a Service | サーバ・ストレージ・ネットワークなどインフラ(ハードウェア) | 更地+建物の骨組み | OS・ミドルウェア・アプリ |
| PaaS | Platform as a Service | インフラ+OS・ミドルウェアまで(アプリの実行基盤) | 設備の整ったキッチン | アプリケーション |
| SaaS | Software as a Service | アプリまで全部(完成したソフトをそのまま利用) | 出来上がった料理 | (基本、使うだけ) |
- IaaS:土台だけ借りて、OSもアプリも自分で載せる。自由度が高い。
- PaaS:OSや開発環境まで用意されていて、アプリ開発に集中できる。
- SaaS:メールソフトや会計ソフトなど、完成したソフトをそのまま使う。多くの顧客が同じソフトを共用します。
💡 覚え方:Infra(設備)→ Platform(土台)→ Software(完成品) の順で、事業者が用意してくれる範囲が広がる。 頭文字 I → P → S の順に「借りる範囲が増える」と覚えましょう。
📝 過去問はこう出る(R01 第23問) 「アプリケーション・ミドルウェア・OS・ハードウェアの全機能を提供し、複数顧客が利用するサービス」を選ぶ問題。 正解は SaaS(全部込みで使うだけ)。IaaSはインフラのみ、PaaSは実行基盤まで、が区別のポイント。 なお選択肢の MaaS(Mobility as a Service)は"移動サービスの統合"のことで、クラウドの階層とは別概念です(引っかけ)。 → R01 第23問
責任共有モデル ― 「どこまでが事業者、どこからが利用者の責任か」
クラウドを使うとき、セキュリティやデータ管理の責任を事業者と利用者で分担する考え方を 責任共有モデルといいます。近年の頻出テーマです。基本ルールは次のとおり。
- 下位(IaaS)→上位(SaaS)になるほど、事業者の管理範囲が広く、利用者の責任範囲は狭くなる。
- ただし、利用者が入力・生成したデータの管理責任は、SaaSであっても常に利用者側に残る。 ←ここが最重要。
事業者の責任 ←───────────→ 利用者の責任
IaaS : ハード・仮想化基盤 │ OS・ミドルウェア・アプリ・データ(広い)
PaaS : ハード〜OS・基盤 │ アプリ・データ
SaaS : ハード〜アプリまで │ データ(狭い。でもデータ責任は残る)
📝 過去問はこう出る(R06 第11問) 責任共有モデルの責任分界を問う問題。正解は「SaaSを利用する場合でも、利用者が入力・生成したデータの 管理責任は利用者が負う」。「IaaSでOS管理は事業者」(→実際は利用者)、「PaaSでハード管理は利用者」(→実際は事業者)、 「外部委託すれば最終責任は委託先が負う」(→最終責任は委託元=利用者に残る)はすべて誤りです。 → R06 第11問
実装(配置)形態 ― パブリック・プライベート・その他
「誰のために提供されるか」で、クラウドは次のように分類されます(NISTの定義がベース)。
| 形態 | だれのためのものか |
|---|---|
| パブリッククラウド | 不特定多数の一般利用者に開放されるクラウド |
| プライベートクラウド | 単一の組織の専用使用のためのクラウド |
| コミュニティクラウド | 共通の懸念事項(規制・セキュリティ等)を持つ複数組織の共同体の専用使用 |
| ハイブリッドクラウド | パブリックとプライベートなど、異なる形態を組み合わせたもの |
- 「単一組織の専用使用」=プライベート(パブリックではない)。ここが取り違えの定番。
- ハイブリッドは"異なる種類の組み合わせ"。複数のパブリッククラウドを組み合わせるのはマルチクラウドと呼び、別概念です。
📝 過去問はこう出る(R06 第6問) クラウドの実装形態を問う問題。正解は「コミュニティクラウドは、共通の懸念事項を持つ異なる組織の 成員から成る共同体の専用使用のために提供される」。「パブリック=単一組織専用」(→プライベートの説明)、 「ハイブリッド=複数パブリックの組み合わせ」(→マルチクラウドの説明)などは誤りです。 → R06 第6問
⚠️ 混同注意:3つの分類軸を混ぜない クラウドには3つの見方があります。①サービス階層(IaaS/PaaS/SaaS)、②実装形態(パブリック/プライベート等)、 ③責任共有モデル(事業者と利用者の責任分担)。問題文がどの軸を聞いているかを最初に見極めましょう。
6-3 電子商取引とWebサービス
電子商取引(EC)の基本分類
電子商取引(EC:Electronic Commerce)は、インターネットを通じた商取引です。 「誰と誰の取引か」で分類する用語がよく問われます。
| 略称 | 意味 | 例 |
|---|---|---|
| BtoB | 企業間取引(Business to Business) | 部品メーカーと組立メーカーの取引 |
| BtoC | 企業と消費者(Business to Consumer) | ネット通販サイトでの買い物 |
| CtoC | 消費者間(Consumer to Consumer) | フリマアプリ・ネットオークション |
- eマーケットプレイス:多数の売り手・買い手が集まる電子的な取引の"市場"。
- ロングテール:ネット販売では、あまり売れない多品種の商品の売上合計が、 一部のヒット商品に匹敵するほど大きくなる現象(実店舗では棚に置けない商品も扱えるため)。
API・Webサービス・REST ― システム同士をつなぐ「窓口」
API(Application Programming Interface)とは、 あるソフトの機能やデータを、外部の別のソフトから呼び出して使うための"窓口(取り決め)"です。 これをWeb経由で提供するものをWeb APIと呼びます。
- 例:地図サービスのAPIを使えば、自社サイトに地図を埋め込める。決済サービスのAPIで支払い機能を組み込める。
- Web APIは「機能やデータを外部から呼び出すインタフェース」であって、 「HTMLとCSSでブラウザ上に動的表示する仕組み」ではありません(それはJavaScript等の役割)。ここが引っかけ。
REST(レスト)は、Web APIの代表的な設計様式(作り方の流儀)です。
- RESTは、HTTPメソッド(GET=取得/POST=登録/PUT=更新/DELETE=削除)を使って、 Web上の資源(リソース)を操作します。
- 「HTTPメソッドを用いずにサーバOSの機能を利用する」というのはREST の説明として誤りです。
JSON(ジェイソン:JavaScript Object Notation)は、 システム同士のデータのやり取りで広く使われる軽量なデータ記述形式です。人間にも読みやすく、APIの返答によく使われます。
📝 過去問はこう出る(R07 第4問・再掲) a:RESTは「HTTPメソッドを用いることなく…」→誤り(RESTはHTTPメソッドを使う)。 b:Web APIは「HTMLとCSSで動的表示する仕組み」→誤り(それはJavaScriptの役割)。 c:JSONはデータ交換形式→正。d:HTTPはHTML等をやり取りするプロトコル→正。 よって a誤・b誤・c正・d正 の組み合わせが正解です。 → R07 第4問
CMS ― 専門知識なしでサイトを更新する仕組み
CMS(Content Management System:コンテンツ管理システム)とは、 HTMLの専門知識がなくても、Webサイトの文章や画像を作成・更新・管理できる仕組みです。 代表例はWordPressなど。中小企業が自社サイトやブログを手軽に運用するのに役立ちます。
レスポンシブWebデザイン ― PCでもスマホでも見やすく
レスポンシブWebデザインとは、 閲覧する画面の大きさ(PC・タブレット・スマホ)に応じて、レイアウトを自動で調整する作り方です。 1つのHTMLとCSSで、どの端末でも見やすく表示できるため、スマホ利用が主流の今、標準的な手法になっています。
Webマーケティングの効果測定指標
ネット広告・サイト運営では、効果を数値で測れるのが強みです。指標の名前と定義の対応が問われます。
| 指標 | 読み | 意味 |
|---|---|---|
| コンバージョン率(CVR) | コンバージョン | 訪問者のうち、購入・会員登録などの成果に至った割合 |
| 直帰率(バウンス率) | ちょっき | 最初の1ページだけ見て、他ページへ移らず離脱した割合 |
| 離脱率 | りだつ | 各ページから離れていった割合(直帰率とは別) |
| チャーン率(解約率) | チャーン | 一定期間に解約・退会した利用者の割合 |
| エンゲージメント率 | エンゲージメント | いいね・コメントなど反応(関与)の割合 |
📝 過去問はこう出る(R02 第14問) 効果測定指標と定義の対応を問う問題。正解は「広告配信停止や解約をしたユーザの割合=チャーン率」。 「成果の割合=エンゲージメント率」(→正しくはコンバージョン率)、「最初の1ページだけで離脱=離脱率」 (→正しくは直帰率)など、定義のすり替えが誤りの選択肢です。似た指標の"境目"を押さえましょう。 → R02 第14問
6-4 IoT・モバイル・新技術動向
IoT ― モノがインターネットにつながる
IoT(Internet of Things:モノのインターネット)とは、 家電・センサー・機械などの"モノ"がインターネットにつながり、データを収集・活用する仕組みです。 例:工場の設備の稼働状況を集めて故障を予測する、家電を外出先から操作する、など。
IoTでよく問われる関連用語を押さえます。
- センサー:状態を測る部品。例としてサーミスタは温度センサー(温度で抵抗値が変わる部品)。 ※「サーミスタ=方位センサー」は誤り、という形で問われます。
- ワンボードマイコン:1枚の基板に載った小型コンピュータ。IoT機器の頭脳に使われます。 OSを持たないもの(ベアメタル)やRTOS搭載のものもあり、「すべてにLinuxが入っている」は誤り。
- LPWA(Low Power Wide Area):低消費電力で広い範囲をカバーできる無線通信技術。 電池で長期間動くIoT機器の通信に向いています。
エッジコンピューティング ― 「現場の近くで処理する」
エッジコンピューティングとは、 データをクラウド(遠くの中央)に集約せず、IoT機器やその近くのコンピュータで処理する技術です。
- メリット:処理を手元で行うので応答が速い(遅延が小さい)、通信量を減らせる。
- クラウド(中央集約)と対比して覚えます。「クラウド=中央でまとめて処理/エッジ=現場の近くで処理」。
📝 過去問はこう出る(R07 第8問) IoTの正誤判定。正しいのは「エッジコンピューティングはIoT機器やその近くのコンピュータでデータを処理する技術」と 「LPWAは広範囲をカバーし低消費電力で運用できる通信技術」。 「すべてのワンボードマイコンにLinux」(→誤り)、「サーミスタは方位センサー」(→温度センサーなので誤り)が引っかけです。 → R07 第8問
モバイル端末の管理(MDM)とテレワーク関連用語
スマホ・タブレットを業務で使う場面が増え、安全な端末管理が問われます。用語の定義がそのまま出題されます。
| 用語 | 読み・正式名 | 意味 |
|---|---|---|
| MDM | Mobile Device Management | モバイル端末そのものを一元管理(設定配布・遠隔ロック・紛失時のデータ消去など) |
| MCM | Mobile Content Management | 端末内の業務データ(コンテンツ)を管理する技術 |
| BYOD | Bring Your Own Device | 社員の私物端末を業務で利用すること |
| COPE | Corporate Owned, Personally Enabled | 企業が支給した端末を、私的利用も許可する方式 |
| MFA | Multi-Factor Authentication | 知識・所持・生体など異なる要素を組み合わせる多要素認証 |
| SSO | Single Sign-On | 一度の認証で複数のサービスを利用できる仕組み |
- BYOD(私物を業務利用)とCOPE(会社支給を私的利用も許可)は向きが逆なので取り違え注意。
- MFAは「複数の"端末"で認証」ではなく「複数の"要素"で認証」。
- SSOは「端末を最低限にしてサーバで資源管理」(=これはシンクライアントの説明)ではありません。
📝 過去問はこう出る(R05 第21問) モバイル端末管理の用語の定義を問う問題。正解は「MCMは端末内の業務データを管理する技術」。 「BYOD=組織所有端末を許可なく私的利用」(→私物を業務利用が正)、「COPE=私物を業務利用」(→会社支給が正)、 「MFA=複数端末で認証」(→複数"要素"が正)、「SSO=端末最低限でサーバ管理」(→シンクライアントの説明)は すべて定義のすり替えで誤りです。 → R05 第21問
AR・VR・ウェアラブル ― 新しいIT用語の正確な定義
新技術は「言葉の意味を正確に言えるか」がそのまま問われます。
- AR(Augmented Reality:拡張現実):現実の風景にデジタル情報を重ねて表示する技術(スマホをかざすと情報が浮かぶ、など)。 ※「AR=人工知能技術」は誤り。
- VR(Virtual Reality:仮想現実):コンピュータが作った仮想空間に入り込む技術。
- ウェアラブルデバイス:身につけられる機器(スマートウォッチなど)。生活・健康・運動のデータを収集し、 行動分析に活用できます。
- MCN(マルチチャンネルネットワーク):複数の動画チャンネルを束ねて支援する事業者・仕組み。 ※「自社サイトをゲートウェイにする仕組み」ではありません。
📝 過去問はこう出る(H29 第8問) 新しいIT用語(AR・IoT・MCN・ウェアラブル)の定義を問う問題。正解は 「ウェアラブルデバイスは身につけられる機器で、生活・健康・スポーツのデータを蓄積し行動分析を緻密かつリアルタイムにできる」。 「AR=人工知能」「IoTでインターネットが全て置き換わる」「MCN=自社サイトのゲートウェイ化」はいずれも定義の誤りです。 → H29 第8問
この章のまとめ(試験直前チェック)
- ☐ Webはクライアント(ブラウザ)とサーバがリクエスト/レスポンスをやり取りする仕組み
- ☐ HTTP=Web文書のやり取りルール/HTTPS=それを暗号化(SSL/TLS)したもの。sの有無で意味が変わる
- ☐ HTML=構造/CSS=見た目/JavaScript=動き(役割の取り違えに注意。Java と JavaScript は別物)
- ☐ HTMLの本質はリンク(アンカー)機能。タグは対が基本だが
<br>等の空要素もある/色は約1,677万色 - ☐ DHTML(動きのあるページ)・Ajax(非同期通信で部分更新)・RSS(更新通知)/Web2.0は"思想・概念"
- ☐ URL=スキーム+ホスト名(ドメイン)+パス。ドメインは大小文字を区別しない/.jpは設置場所を保証しない
- ☐ DNS(名前↔IP)・DHCP(IP自動割当)・NAT(グローバル↔プライベート変換)の3点セット
- ☐ Cookie=ブラウザに預ける小さなデータ/セッション=一続きの利用のまとまり(HTTPはステートレス)
- ☐ クラウド3階層:IaaS(インフラ)<PaaS(実行基盤)<SaaS(完成ソフト)、事業者が用意する範囲が広がる
- ☐ 責任共有モデル:下位ほど事業者責任が広い。ただしデータの管理責任は常に利用者に残る
- ☐ 実装形態:パブリック(一般開放)/プライベート(単一組織専用)/コミュニティ/ハイブリッド
- ☐ API=機能を外部から呼び出す窓口、REST=HTTPメソッド(GET/POST/PUT/DELETE)で操作、JSON=データ形式
- ☐ CMS(知識なしでサイト更新)・レスポンシブ(画面幅に応じて自動調整)
- ☐ Web指標:コンバージョン率=成果割合/直帰率=1ページで離脱/チャーン率=解約率(定義のすり替えに注意)
- ☐ IoT:エッジ=現場の近くで処理、LPWA=低消費電力・広範囲、サーミスタ=温度センサー
- ☐ モバイル管理:MDM(端末)/MCM(データ)/BYOD(私物を業務)/COPE(会社支給を私用も)(BYODとCOPEは逆)
- ☐ AR=現実に情報を重ねる(≠AI)、ウェアラブル=身につける機器
この章に対応する主な過去問
| 年度・問 | 論点 | リンク |
|---|---|---|
| H21 第4問 | HTMLの特徴(リンク・タグ・色) | 問題 |
| H23 第7問 | DHTML・RSS・Ajax の対応 | 問題 |
| H23 第12問 | DNS・DHCP・NAT の役割 | 問題 |
| R01 第8問 | URLから読み取れる情報 | 問題 |
| R07 第4問 | REST・Web API・JSON・HTTP | 問題 |
| R01 第23問 | クラウド提供形態(SaaS等) | 問題 |
| R06 第6問 | クラウドの実装(配置)形態 | 問題 |
| R06 第11問 | クラウドの責任共有モデル | 問題 |
| R02 第14問 | Webマーケティングの効果測定指標 | 問題 |
| R07 第8問 | IoT・エッジ・LPWA | 問題 |
| R05 第21問 | モバイル端末管理(MDM・MCM・BYOD) | 問題 |
| H29 第8問 | 新技術用語(AR・IoT・ウェアラブル) | 問題 |
次章予告 ▶ 第7章「情報セキュリティ」 本章のWeb・クラウド・モバイルは、いずれも「どう安全に使うか」という課題と裏表です。 第7章では、暗号化(共通鍵・公開鍵)、認証、電子署名、マルウェア対策、そして本章でも触れた SSL/TLS や多要素認証(MFA)を、セキュリティの視点から体系的に整理します。