覚えたことを、
つなげてみよう。

ブラウザ

ブラウザはWebページを利用するクライアント側のソフトウェアです。サーバーに要求し、受け取った内容を画面に表示します。

• DNS：DNSは名前の情報を調べるしくみで、ページを表示するソフトではありません。
• Webサーバー：Webサーバーは要求に応答する側です。利用者の画面を表示するブラウザと区別しましょう。
• ルーター：ルーターはネットワーク間でデータを中継する機器です。

レスポンス

要求がリクエスト、応答がレスポンスです。方向を矢印で考えると区別できます。

• リクエスト：リクエストはブラウザからサーバーへの要求です。方向が逆です。
• パスワード：パスワードは認証に使う情報で、応答全体の名前ではありません。
• 検索語：検索語は利用者が検索サービスへ入力する内容です。

HTMLとは別に画像を要求する場合がある

ブラウザは文書を読み、必要に応じて画像などを追加取得します。検索はサービス、ブラウザはそれを利用するソフトウェアです。

• どのページも必ず1回の通信だけで表示される：画像やCSSなどを追加取得する場合があるため、回数は一定ではありません。
• ブラウザと検索エンジンは同じもの：検索エンジンは探すサービス、ブラウザは表示する道具です。
• Webサーバーが利用者の画面を直接描画する：通常、受け取ったデータを画面に組み立てるのは利用者側のブラウザです。

写真の取得に問題がある可能性を調べる

一部のデータだけ取得できないことがあります。観察できた事実から、本文と写真の取得を分けて考えます。

• インターネット全体が停止している：本文が表示されている事実だけでは、インターネット全体の停止とは言えません。
• 表示済みの本文も届いていない：本文は表示できています。確認できた事実を否定しないようにしましょう。
• ブラウザを使っていない証拠である：ブラウザでも画像だけ取得できない状態は起こります。

DNS

DNSは名前に対応する情報を調べるしくみです。Webページの構造を表すHTMLや、見た目を整えるCSSとは役割が異なります。

• HTML：HTMLは文書の構造を表します。名前の情報を調べる仕組みではありません。
• CSS：CSSは表示の見た目を指定します。
• 多要素認証：多要素認証は本人確認を強める方法です。

サイト内の対象を示すパス

「/menu」はパスです。ホストを示す「shop.example」や方式を示す「https」と区別します。

• 通信先のIPアドレス：IPアドレスではありません。URLのホスト名より後にある部分です。
• DNSサーバーの名前：DNSへの問い合わせ先を表す部分ではありません。
• 暗号化のためのパスワード：URLのパスとパスワードは別のものです。

名前に対応する情報を返す

DNSは名前の情報を扱います。本文の取得、認証、通信の保護をDNSだけで行うわけではありません。

• Webページの本文を常に返す：本文を返すのはWebサーバー側の役割です。
• 利用者の本人確認を必ず行う：名前解決は利用者の本人確認ではありません。
• すべての通信を暗号化する：DNSを使うだけで全通信が暗号化されるわけではありません。

キャッシュされた結果を利用する場合がある

保存済みの結果を一定期間利用することがあります。DNSの成功と、その後の接続・ページ取得の成功は別です。

• 名前とIPアドレスは必ず永久に一対一である：複数アドレスが対応することも、対応が更新されることもあります。
• URL全体とドメイン名は常に同じである：URLには方式やパスなども含まれます。
• 名前解決に成功すればページの取得も必ず成功する：名前解決後に接続やサーバー側の応答で問題が起こる場合があります。

HTTP通信をTLSで保護する

HTTPSは通信経路の保護に役立ちます。記事の真偽、端末の感染、認証情報の使い回しは別の問題です。

• 掲載情報が必ず正しいことを保証する：掲載情報の正しさはHTTPSだけでは保証されません。
• すべてのウイルスを削除する：HTTPSはウイルス対策ソフトではありません。
• パスワードの使い回しを安全にする：同じパスワードの漏えいによる被害はHTTPSだけでは防げません。

要求した対象が見つからないことを示す

404は対象が見つからないことを示すHTTPの状態コードです。サーバーから応答を受けたことと、望む内容が見つかったことは別です。

• インターネット全体が停止した：応答を受けているので、それだけで回線全体の停止とは言えません。
• 本人確認に必ず成功した：404は本人確認の成功を示す番号ではありません。
• DNSの問い合わせが必ず失敗した：名前解決の失敗とHTTPの404応答は別です。

これらはHTTPSだけでは判断できない

通信の保護と内容・運営者の信頼性を切り分けましょう。攻撃者のサイトでもHTTPSを利用できる場合があります。

• 掲載記事の正確さ：暗号化は内容の事実確認をしません。
• 運営者の誠実さ：ドメインへの接続の確認と、運営者の誠実さは別です。
• 販売される商品の品質：HTTPSは商品の審査をする仕組みではありません。

普段使う公式アプリ等から状況を確認する

正規の経路から確認することで、メールが用意した誘導先を避けられます。認証コードも本人確認に使われる大切な情報です。

• HTTPSなので即座に入力する：HTTPSだけで要求の正当性はわかりません。
• メールに認証コードを返信する：認証コードを求める相手に渡すと、悪用されるおそれがあります。
• 同じパスワードを別サイトでも試す：別サイトで試しても、そのメールの正当性は確認できません。

認証

本人かを確認するのが認証、何を許すかを判断するのが認可です。

• 認可：認可は閲覧や編集など、許される操作を決めることです。
• 圧縮：圧縮はデータの表現を小さくする処理です。
• 名前解決：名前解決はドメイン名等に対応する情報を調べる処理です。

パスワードと本人の指紋

パスワードは知識要素、指紋は生体要素です。他の選択肢はいずれも知識要素だけの組合せです。

• パスワードと別の暗証番号：どちらも知識要素です。入力が2つでも種類は増えません。
• 同じパスワードを2回入力：同じ情報を2回入れても新しい要素は加わりません。
• 秘密の質問の答えを2つ入力：秘密の質問も知識要素に分類されます。

認可

ログイン後に許す操作の範囲を決めるため、認可の設定です。認証に成功していても権限は限定できます。

• DNS：名前の情報を調べる話ではありません。
• 画像圧縮：表示する画像の容量の話ではありません。
• 暗号化方式：通信の暗号方式を決める話ではありません。

一つの漏えいによる他サービスへの被害を抑えるため

同じ情報を複数サービスで使うと、一つのサービスからの漏えいが他のサービスへの不正ログインにつながるおそれがあります。

• DNSの処理が速くなるから：パスワードの使い分けでDNSが速くなるわけではありません。
• 画面の表示色が変わるから：画面の色と認証情報の使い回しは関係ありません。
• 必ず記憶しやすくなるから：目的は覚えやすさではなく被害の連鎖を抑えることです。

機密性

許されていない人が情報を知ることになったため、機密性が損なわれています。停止や変更は問題文にはありません。

• 可用性：可用性は必要なときに使えることです。この例は漏えいが中心です。
• 表示速度：処理速度ではなく、誰に情報が渡ったかを考えます。
• 画面解像度：画面の細かさと漏えいは別の話です。

完全性

情報の正確な状態が不正な変更で損なわれたため、完全性の問題です。

• 可用性：この例で示されているのは利用停止ではなく内容の変更です。
• 名前解決：ドメイン名の情報を調べる処理ではありません。
• 通信速度：データを送る速さではなく、内容の正しさの問題です。

可用性

必要なときにサービスを利用できないため、可用性が損なわれています。書かれた条件に沿って分類しましょう。

• 機密性：問題文では漏えいは起きていません。
• 完全性：問題文ではデータの変更は起きていません。
• パスワードの長さ：パスワードの長さについての条件は書かれていません。

データを戻すための備えであり、保存先の保護や復元確認も必要

バックアップは失ったデータを戻すための対策です。それだけで全ての被害を防げるわけではなく、復元できる状態で保管する必要があります。

• 取得すれば情報漏えいが必ず防げる：複製を取ることと、不正な閲覧を防ぐことは別の対策です。
• 取得後は復元の確認が不要になる：必要なときに戻せなければ目的を果たせないため、復元確認も大切です。
• 暗号化と同じ役割しか持たない：暗号化は内容を保護する技術、バックアップは復元への備えです。

Plan

目標・手順・評価方法を用意するのはPlanです。

• Do：Doは計画した方法の実行です。
• Check：Checkは実行後の結果の確認・比較です。
• Act：Actは評価を踏まえた改善・標準化です。

Check

結果を目標と比較して評価するのでCheckです。

• Plan：目標を最初に決める段階ではありません。
• Act：改善方法を決める前の評価です。
• Do：手順を試す部分がDoで、その後の比較はCheckです。

Act

結果を踏まえた改善や標準化を行うのがActです。

• Do：計画を試す段階と、その評価を踏まえた改善を分けます。
• Plan：この設問では実行・評価後の改善判断が中心です。
• Check：測定・比較を行った後の判断です。

客数や曜日などの比較条件も確認する

条件の違いが結果へ影響している可能性があります。比較と解釈を分けて考えます。

• 施策の効果だと必ず断定できる：来客数など別の要因も考えられます。
• 記録があれば次の改善は不要：記録を次の改善へ使うことが大切です。
• 客数の違いは無視してよい：客数が違えば待ち時間も変わり得ます。

強み

自店の内部にある有利な能力なので強みです。

• 機会：機会は外部環境の有利な要因です。
• 弱み：不利な内部要因ではありません。
• 脅威：不利な外部要因ではありません。

機会

周辺需要という外部環境の有利な変化なので機会です。

• 強み：自店の能力や資源ではなく周囲の環境です。
• 弱み：内部の不利な点ではありません。
• 脅威：この設問では有利な変化とされています。

弱み

自店の内部にある、目標に対して不利な要因なので弱みです。

• 強み：狙う注文への対応では不利とされています。
• 機会：外部の有利な環境変化ではありません。
• 脅威：自店の設備は内部要因です。

脅威

市場価格という外部の、不利な要因なので脅威です。

• 強み：内部の有利な能力ではありません。
• 弱み：市場価格の変化は自店の外部要因です。
• 機会：この条件では不利な変化です。

Product

商品自体の内容を設計しているのでProductです。

• Price：価格の設定が主題ではありません。
• Place：流通経路の変更ではありません。
• Promotion：告知方法ではなく商品の中身です。

Price

価格の設定はPriceです。

• Product：この条件では商品内容は同じです。
• Promotion：広告や告知の変更ではありません。
• Place：販売経路の変更ではありません。

Place

注文から受取までの販売経路を整えるため、主にPlaceです。

• Promotion：ネットを使っていても、告知ではなく販売経路の整備です。
• Price：価格変更は書かれていません。
• Product：商品の中身を変更する設問ではありません。

Promotion

認知を広げる広告・販売促進はPromotionです。

• Place：注文や配送の経路を整える施策ではありません。
• Price：価格設定の話ではありません。
• Product：商品開発ではなく伝え方の話です。

月間の予約売上

この例では売上が最終成果の指標です。関係の薄い作業量だけで達成とは判定しません。

• 会議の開催回数：会議回数だけでは売上達成を測れません。
• 広告原稿の文字数：文字数は売上という最終成果ではありません。
• 集計表の枚数：表の枚数は目標達成を示しません。

200件

120,000÷600＝200件です。目標売上を一件あたりの額で割ります。

• 20件：金額の単位と桁を確認しましょう。
• 720件：売上と単価を掛ける計算ではありません。
• 2,000件：一桁多い値です。

売上実績は10万円で未達

200×500＝100,000円です。件数だけが計画どおりでも売上の達成を保証しません。

• 件数が200件なら必ず売上達成：平均単価も影響します。
• 売上実績は12万円：200×500は100,000円です。
• 平均単価は成果に影響しない：売上は件数だけでは決まりません。

目標との関係や期間・対象をそろえて確認する

指標の意味は目標や集計範囲との関係で決まります。数字の定義を確認しましょう。

• 売上はどんな目標でも必ずKGI：目標の階層によって位置づけは変わります。
• KPIが一つ良ければ他の条件は無視する：一つの数字が改善しても成果を保証しません。
• 期間が違う数字でも無条件に掛ける：同じ期間・対象でないと式の意味が崩れます。

300円

800−500＝300円です。この額から固定費を回収します。

• 800円：変動費が引かれていません。
• 500円：これは変動費そのものです。
• 1,300円：価格と費用を足すのではなく差を求めます。

200個

60,000÷（800−500）＝200個です。価格ではなく1個あたり限界利益で割ります。

• 75個：価格だけで割ると変動費を無視します。
• 120個：変動費で割る計算ではありません。
• 300個：300は1個あたり限界利益の金額です。

15,000円

（800−500）×250−60,000＝15,000円です。

• 75,000円：固定費60,000円を引く前の限界利益合計です。
• 200,000円：これは売上高です。費用を引きます。
• −15,000円：計算結果はプラス15,000円です。

201個

損益分岐点の200個では利益ゼロなので、黒字には201個が必要です。

• 199個：損益分岐点より少ないため赤字です。
• 200個：利益ゼロと黒字を区別しましょう。
• 0個：固定費があるため販売ゼロなら赤字です。

DBMS

DBMSがデータベースを管理するソフトウェアです。保存されたデータ自体とは区別します。

• DNS：DNSはドメイン名の名前解決などを担います。
• ブラウザ：ブラウザはWebページを利用するソフトです。
• 主キー：主キーは表の行を識別する項目です。

レコード

一件の注文を表す行がレコードです。

• フィールド：フィールドは注文IDや数量などの列です。
• DBMS：DBMSは管理用ソフトです。
• データ型：データ型は文字列や整数などの値の種類です。

3

データの行数を数えるので3レコードです。見出しは含めません。

• 1：表全体で一件ではありません。
• 4：見出しをレコードに数えません。
• 9：セルの数ではなく行数を数えます。

0や小数など、この数量欄で許さない値を防ぐ

許容する値を定める制約です。入力が現実と一致するかは別に確認が必要です。

• すべての注文の事実確認を不要にする：型や範囲が正しくても注文内容の誤りはあり得ます。
• 顧客を一意に識別する：数量は顧客の識別子ではありません。
• 表を必ず高速化する：速度改善を必ず保証するものではありません。

注文ID

注文IDは注文ごとに異なり、一行を一意に識別します。

• 顧客名：同姓同名や同じ人の再注文を区別できません。
• 数量：同じ数量の注文は複数あります。
• 顧客ID：一人の顧客が複数回注文するため重複します。

よい。この例では外部キーの重複を許す

一対多の関係なので、注文表の外部キーC01は複数行に現れます。

• 主キーなので不可：注文表の主キーは注文IDです。
• 注文IDも同じならよい：注文IDは各注文を識別するため重複できません。
• 顧客表にもC01を2行作る必要がある：顧客表の主キーC01は一行のままです。

行を一意に識別し、NULLを許さない

主キーは重複せず、NULLを許しません。複数列の組合せの場合もあります。

• NULLを必ず一行に許す：主キーにNULLは許しません。
• 同じ値を何行でも許す：重複すると行が一意に決まりません。
• 必ず氏名にする：氏名は同姓同名などがあり、この例の主キーにはしません。

顧客IDの外部キー制約

顧客表への外部キー制約が参照先の存在を確認します。

• 数量の整数型だけ：数量の型では顧客の存在を確認できません。
• 表の表示順：表示順は参照整合性を保証しません。
• 顧客名の文字色：見た目の設定はデータの制約ではありません。

更新の不整合

同じ現在の事実が二通りになり、整合しなくなっています。

• 暗号化：データを暗号で保護する話ではありません。
• 名前解決：ドメイン名の解決ではありません。
• 認証の成功：本人確認の成否とは別です。

顧客表を独立させる

顧客の存在と注文の発生を別の表で表すと、注文なしでも顧客を登録できます。

• 架空の注文を必ず作る：存在しない注文を作るとデータの意味が壊れます。
• 顧客名を数量欄に入れる：数量欄の意味と型に合いません。
• 全顧客を同じIDにする：顧客を区別できなくなります。

依存関係を考えて重複による不整合などを防ぎやすくする

データの意味と依存関係に沿って表を整理します。単純な見た目の分割ではありません。

• 表を必ず一つにまとめる：一つにまとめることが目的ではありません。
• すべての検索を必ず高速化する：速度は処理内容や索引などにも依存します。
• 列を同じ数に分ける：列数をそろえても依存関係が整理されるとは限りません。

過去と現在の事実を区別して扱う

時点の異なる事実は区別します。履歴の値を現在値に揃えると、当時の情報を失います。

• 過去の配送先も必ず上書きする：履歴を残す目的に反します。
• すべての注文を消す：連絡先変更は注文消去の理由ではありません。
• 主キーを削除する：主キーを失うと注文の識別に支障が出ます。

選択

条件に合う行を取り出すので選択です。元データの削除ではありません。

• 射影：射影は列を取り出します。
• 結合：この操作では別の表をつないでいません。
• 削除：結果を取り出しているだけです。

射影

必要な列に着目した操作が射影です。

• 結合：複数の表を関連づける操作ではありません。
• 選択：条件で行を絞る話ではありません。
• 更新：値を書き換えていません。

顧客IDの一致

顧客IDという対応する値で表をつなぎます。表示順には依存しません。

• 上から同じ位置の行：並べ替えだけで対応が変わってしまいます。
• 文字色：見た目は表の関係を保証しません。
• 数量の大きい順：数量の順序は顧客との対応を示しません。

C01とC02の2種類

関係代数の射影では同じ行を重複させないので、C01とC02の2種類です。

• C01だけ：C02も元の表にあります。
• O101、O102、O103：注文IDではなく顧客IDを取り出します。
• C01が2行、C02が1行：この設問は関係代数の射影で、重複するC01をまとめます。

コミット

コミットでトランザクションを確定します。

• ロールバック：未確定の変更を取り消す操作です。
• 射影：必要な列を取り出す操作です。
• 名前解決：DNSなどで行う処理です。

ロールバック

未確定の一連の変更をロールバックし、途中の更新だけを残さないようにします。

• コミット：成功として確定する操作なので目的と逆です。
• 結合：表の対応をつなぐ操作ではありません。
• 顧客表の全削除：無関係な顧客情報を削除する必要はありません。

原子性

一連の処理を全部反映するか、反映しないかとして扱うのが原子性です。

• 耐久性：耐久性は確定した結果を保持する性質です。
• 射影：列を取り出す操作です。
• 正規化：表の依存関係を整理する設計の考え方です。

排他制御や条件付き更新などで同時実行を調整する

適切な同時実行制御と更新結果の確認が必要です。処理をまとめるだけでは不十分な場合があります。

• 画面の文字色だけ変える：表示だけではDB更新の競合を防げません。
• 顧客IDを全員同じにする：顧客を識別できなくなり、競合も解決しません。
• トランザクションと書けば実装に関係なく解決する：分離レベルや更新方法などの設計が必要です。