【システム構成】起きてしまった衝撃から命とデータを守る！「パッシブセーフ」｜情報処理問題1000本ノック

安全設計の双璧をなす思想。どれだけ予防しても「事故や障害は100%発生する」という前提に立ち、発生した瞬間の被害を最小限に抑える設計を攻略しましょう。

1. 【 問題 】：システムの安全性と被害軽減思想

【 問題 】 システム構成や製品の安全設計（セーフティ設計）において、事故、衝突、機器の破壊といった危険な事象が「発生したとき」に、人体（乗員やオペレーターなど）への被害や致命的な損害を最小限に抑えることを目的とした、受動的な安全の考え方はどれでしょうか？

① アクティブセーフ（能動的安全）
② パッシブセーフ（受動的安全）
③ フェールセーフ（安全側への制御）
④ フォールトトレラント（耐障害性）

2. 正解：

正解： ② パッシブセーフ（受動的安全 / 衝突安全）

3. 解説：「もしも」の瞬間に働く最後の防護壁

安全設計の思想において、最も重要な対比が「事故を未然に防ぐアクティブセーフ」と、今回の正解である「起きた後の被害を最小にするパッシブセーフ」です。

【システム構成におけるパッシブセーフの具体例】

パッシブセーフは、主に「物理的な破壊や衝撃」が人や設備に及ぶのを防ぐために導入されます。

・製品・ハードウェアの例：自動車のエアバッグ、シートベルト、衝撃吸収ボディ、あるいは工場内でロボットの暴走時に作業員を守る物理的な防護フェンス（安全柵）など。 ← ココが問題の正解！
・ITインフラの例：落雷の超過電圧から内部基盤を身代わりとなって守る避雷器（サージプロテクタ）、データセンターが火災になった際に、ガスを噴射して機材へのダメージを最小限に抑えつつ消火する設備など。

[ 選択肢のひっかけポイント（混同しやすい安全思想） ]
★ ① アクティブセーフ：危険自体を「未然に防ぐ」能動的な設計（自動ブレーキやAIの障害予測など）です。
★ ③ フェールセーフ：装置が故障したときに、システム全体を「常に安全な状態（停止など）」に移行させる設計です。
★ ④ フォールトトレラント：部品が壊れても、予備の部品が即座にバックアップすることで、システム全体を一切止めずに動かし続ける設計です。

1. 理解のコツ: 「自転車のヘルメット」をイメージしてください。ヘルメットを被っていても、転倒（事故）そのものを防ぐことはできません。しかし、運悪く転んで頭を地面にぶつけてしまったその瞬間に、衝撃を吸収して**体（頭部）への被害を最小に抑えてくれます**。この「受動的（パッシブ）に衝撃を受け止めて守る」仕組みがパッシブセーフです。
2. 試験対策 the 視点: 「事故などの発生時」「体（人命）への被害を最小に抑える」というフレーズがあればパッシブセーフが正解です。情報処理技術者試験では、ITシステムそのものの可用性（フェールセーフやフォールトトレラント）だけでなく、工場を制御するシステム（OT分野）やIoT機器の安全性を問う問題として、このパッシブ/アクティブの概念がよく狙われます。

---

4. まとめ

「事故の発生を前提とし、激突や破壊が起きた瞬間に人体やコア設備への深刻なダメージを最小限に食い止める防衛システム」。これがパッシブセーフです。アクティブセーフ（予防）とパッシブセーフ（事後緩和）の両輪が揃うことで、初めて人間の命や社会インフラを預かる頑強なシステムが完成します。

【システム構成】サーバーも「コード」で書く時代！「IaC」｜情報処理問題1000本ノック

マウスでポチポチ設定するのではなく、テキストファイルに設計図を書いてコマンド一つでインフラを立ち上げる。効率化の極致「IaC」を攻略しましょう。

1. 【 問題 】：インフラ構成の自動化

【 問題 】 サーバーの構築やネットワーク設定などのインフラ構成を、手作業ではなく設定ファイル（コード）を用いて定義し、実行ツールによって自動的に構築・管理する手法を何と呼ぶでしょうか？

① SaaS (Software as a Service)
② IaC (Infrastructure as Code)
③ PaaS (Platform as a Service)
④ IaaS (Infrastructure as a Service)

2. 正解：

正解： ② IaC（Infrastructure as Code）

3. 解説：インフラを「ソフト」のように扱う

IaCは、その名の通り「インフラをコードとして管理する」ことです。これにより、プログラム開発と同じような恩恵をサーバー管理にも持ち込めます。

【IaCによって得られる4つのメリット】

■ 再現性
・同じコードを実行すれば、誰でも、何度でも、全く同じ環境が作れます。

■ 自動化・高速化
・100台のサーバーもコマンド一つで数分のうちに立ち上がります。

■ 履歴管理（バージョン管理）
・Gitなどのツールを使い、「いつ、誰が、どこを変えたか」の履歴がすべて残ります。

■ イミュータブル・アーキテクチャの実現
・「直すより作り直す」が簡単にできるのは、コードですぐに新品が作れるからです。

[ 代表的なツール例 ]
★ Terraform：クラウド全体の構成を定義する。
★ Ansible：OSの中身（ソフトのインストール等）を設定する。
★ CloudFormation：AWS専用のIaCサービス。

1. 理解のコツ: 料理で例えると、「自分の勘で味付け（手動設定）」するのではなく、「完璧なレシピ（コード）」を作っておくようなものです。レシピがあれば、誰が作っても、何度作っても、分店（別環境）を出しても同じ味を再現できます。
2. 試験対策の視点: 「設定ファイルで定義」「自動構築」「バージョン管理が可能」といった言葉が出たらIaCです。IaaS（サービスとしてのインフラ）という言葉と似ていますが、IaCは「やり方（手法）」、IaaSは「提供されるモノ」と区別しましょう。

---

4. まとめ

「インフラの構成をコード化し、自動で構築・管理する」。これがIaCです。開発と運用の壁をなくす「DevOps」を支える、現代ITインフラの土台となる考え方です。

【システム構成】使い捨てが生む安定性！「イミュータブル・アーキテクチャ」｜情報処理問題1000本ノック

「壊れたら直す」のではなく「新しいものに置き換える」。インフラ運用の常識を覆した、モダンな設計思想を攻略しましょう。

1. 【 問題 】：インフラ設計の新常識

【 問題 】 サーバーなどのインフラ構成を変更する際、稼働中のOSやソフトウェアを修正（更新）するのではなく、常に新しい環境を構築して丸ごと入れ替えるという設計手法を何と呼ぶでしょうか？

① モノリシック・アーキテクチャ
② サーバーレス・アーキテクチャ
③ イミュータブル・アーキテクチャ
④ マイクロサービス・アーキテクチャ

2. 正解：

正解： ③ イミュータブル・アーキテクチャ（Immutable Architecture）

3. 解説：「不変（Immutable）」という最強の防御

「イミュータブル」とは「不変（変わらない）」という意味です。一度動かしたサーバーには二度と手を加えない（変更しない）のがこの手法の核です。

【対比：これまでの運用 vs イミュータブル】

■ 従来の運用（ミュータブル / 可変）
・稼働中のサーバーにログインして設定変更やパッチ適用を行う。
・弱点：長年運用すると、設定が複雑に入り組み「秘伝のタレ」化して再現不能になる。

■ イミュータブル・アーキテクチャ（不変）
・変更が必要なら、新しい設定のサーバーを別に作り、古いものと交換して捨てる。
・利点：常に「新品」の状態で動くため、環境の不整合が起きず、復旧や複製が容易。

[ 関連キーワード ]
★ Blue-Green Deployment：新旧の環境を並行して作り、ロードバランサーで一気に切り替える手法。イミュータブルな運用の代表例。
★ IaC (Infrastructure as Code)：コードから同じ環境を何度でも作れる技術が、このアーキテクチャを支えています。

1. 理解のコツ: 昔のテレビ（ブラウン管）が壊れたら近所の電気屋さんが裏蓋を開けて修理していましたが、今のスマホは壊れたら「本体交換」で対応することが多いですよね。あの「直さず新品に替える」という発想がイミュータブル・アーキテクチャです。
2. 試験対策の視点: 「変更（更新）せずに作り直す」「不変」「構築済みのサーバーを破棄」という表現が出てきたらこの用語を選びましょう。Dockerなどのコンテナ技術の説明とセットで出ることが多いです。

---

4. まとめ

「一度作った環境には手を加えず、変更のたびに作り直す」。これがイミュータブル・アーキテクチャです。クラウド時代のインフラ運用において、再現性と信頼性を高めるための必須知識と言えます。

【システム構成】再開までのタイムリミット！「RTO」｜情報処理問題1000本ノック

システムが止まったとき、ビジネスを止めてもいい「制限時間」を定義する重要指標を攻略しましょう。

1. 【 問題 】：目標復旧時間（RTO）

【 問題 】 システム障害が発生した際、業務を再開するまでに要する時間の目標値を何と呼ぶでしょうか？

① RPO (Recovery Point Objective)
② RTO (Recovery Time Objective)
③ MTBF (Mean Time Between Failures)
④ SLA (Service Level Agreement)

2. 正解：

正解： ② RTO（Recovery Time Objective）

3. 解説：キーワードは「いつまでに直すか」

RTOは、障害発生から「業務再開」までの経過時間に関する目標です。この値が短いほど、高度な復旧体制が必要になります。

【図解：RTOの考え方】

■ RTO (Recovery Time Objective)
・焦点：サービス停止の「期間」。
・決まり方：予備機の準備状況や復旧手順の習熟度で決まる。

■ 混同しやすい RPO との違い
・RPO (目標復旧時点)：「いつのデータ」まで戻せるか。（過去への遡り）
・RTO (目標復旧時間)：「いつまでに」直せるか。（未来への所要時間）

[ 現場での考え方 ]
★ 「RTOを10分にする」：自動切り替えなどの高価な仕組み（ホットスタンバイ）が必要。
★ 「RTOを3日にする」：サーバーを新しく買ってきてセットアップする時間がある。

1. 理解のコツ: 料理で例えると、冷蔵庫が壊れてから「何時間以内に修理を終えて、再び冷やし始めるか」がRTOです。その間、中身の食材（ビジネス）が傷まないうちに再開しなければなりません。
2. 試験対策の視点: 「業務再開までの時間」「サービス停止の許容期間」という表現があればRTOが正解です。RPO（Point＝時点）とRTO（Time＝時間）の頭文字を絶対に入れ替えないよう注意しましょう。

---

4. まとめ

「障害発生からサービスを復旧させるまでの目標時間」。これがRTOです。RPOとともに、システムの冗長性（バックアップサイトをどこまで作り込むかなど）を決定する際の最も重要な基準となります。

【ネットワーク】システムの生存確認！「ハートビート」｜情報処理問題1000本ノック

心臓の鼓動（Heartbeat）のように、一定の間隔で信号を送ることで、相手が正常に動いているかを遠隔で監視する仕組みを攻略しましょう。

1. 問題：稼働状況の確認手法

【 問題 】 ネットワークに接続されたコンピュータやソフトウェアが、外部に対して「自分は正常に稼働している」ことを知らせるために、一定の間隔で送信する信号のことを何と呼ぶでしょうか？

ア、ハンドシェイク   イ、ハートビート   ウ、キープアライブ   エ、ポーリング

2. 正解：可用性管理に関する正解

正解： イ、ハートビート（Heartbeat）

3. 解説：沈黙は「異常」のサイン

ハートビートは、特に冗長化（二重化）されたシステムにおいて、相方の故障を検知するために非常に重要です。

【図解：ハートビートの役割と仕組み】

■ 生存確認の流れ
・稼働中のサーバーが、監視役の装置へ定期的に「トントン（生きてるよ）」と短いパケットを送ります。
・信号が途切れた（一定時間届かない）場合、監視役は「あいつは死んだ（故障した）」と判断します。

■ 活用例：フェイルオーバー
・メイン機からのハートビートが途絶えた瞬間、待機していたサブ機が「自分の出番だ！」と判断して処理を引き継ぎます。

[ 紛らわしい用語との違い ]
★ キープアライブ：通信セッションを維持するために送る信号。ほぼ同じ意味で使われることもありますが、ハートビートはより「システムの死活監視（OSやアプリが生きてるか）」の文脈で使われます。
★ ポーリング：監視側が「生きてる？」と毎回聞きに行くこと。ハートビートは基本、自分から「生きてるよ！」と発信するスタイルです。

1. 理解のコツ: 登山のパーティで、先頭の人が後ろの人に向かって「おーい！」と声を出し続けるようなものです。声（信号）が聞こえなくなったら、何かトラブルがあったとすぐにわかります。
2. 試験対策の視点: 「一定間隔で送信」「正常稼働の通知」「死活監視」という言葉がキーワードです。高可用性（HA）クラスター構成の話題とセットで登場することが多い用語です。

---

4. まとめ

「ネットワーク上で稼働状況を知らせるために送る信号」。これがハートビートです。システムが沈黙した瞬間に異常を検知し、素早く切り替える。そんな「止まらないシステム」を支える心臓の鼓動です。

【システム構成】サービスを止めずに進化させる！「ローリングアップデート」｜情報処理問題1000本ノック

システム全体を一時停止させる「計画停止」は、現代の24時間365日稼働するサービスでは許容されないことが増えています。無停止で新バージョンへ切り替える手法を攻略しましょう。

1. 問題：稼働継続とアップデートの両立

【 問題 】 複数のサーバーやノードで構成されるシステムにおいて、稼働中のノードを一つ、あるいは数個ずつ順番に新しいバージョンへと入れ替えていく手法を何と呼ぶでしょうか？

ア、一斉アップデート   イ、ブルーグリーンデプロイメント   ウ、ローリングアップデート   エ、カナリアリリース

2. 正解：リリース管理に関する正解

正解： ウ、ローリングアップデート（Rolling Update）

3. 解説：サービスを維持しながら「波」のように更新する

「Rolling」という名の通り、車輪が転がるように次々と対象をスライドさせて更新していきます。

【図解：ローリングアップデートの手順】

■ 手順
1. 全4台のうち、まず1台を切り離してアップデートし、復帰させる。
2. 残りの旧バージョンが動いている間に、次の1台をアップデートする。
3. これを繰り返し、最終的にすべてのノードを新バージョンに置き換える。

■ メリット
・システム停止が不要：常に一部のノードが稼働しているため、ユーザーはサービスを使い続けられます。
・リソース効率が良い：予備のサーバー群を丸ごと用意する必要がなく、既存のリソース内で完結できます。

[ 比較して覚えたい：ブルーグリーンデプロイメント ]
★ ブルーグリーン：現行環境（Blue）と同じ規模の新しい環境（Green）を丸ごと用意し、ロードバランサーの向きを一気に切り替える手法。瞬時に切り替わりますが、2倍のリソースが必要になります。

1. 理解のコツ: 4人組のアイドルグループが、一人ずつ順番に舞台裏で着替えてステージに戻るようなイメージです。常に誰かが歌っている（サービスが動いている）ため、ライブ（システム）を止める必要がありません。
2. 試験対策の視点: 「順番に」「一部ずつ」「システム停止を避ける」というフレーズが特徴です。クラウドやマイクロサービスの運用において、最も一般的なデプロイ方法の一つとして頻出します。

---

4. まとめ

「複数のノードを順番に更新し、サービスを維持する」。これがローリングアップデートです。ユーザーに不便を強いることなく、常に最新の機能やセキュリティパッチを適用し続けるための、止まらないシステム運営の基本技術です。

【システム構成】二度届いても動じない！「冪等性（べきとうせい）の担保」｜情報処理問題1000本ノック

ネットワークの不安定な環境では、同じリクエストが重複して届くことは珍しくありません。そんな時、システムが二重処理を防ぎ、常に正しい結果を保つための必須概念を攻略しましょう。

1. 問題：重複リクエストへの耐性

【 問題 】 ある操作を1回行っても、失敗したと思って複数回繰り返して行っても、結果が常に同じ（副作用が1回分しか発生しない）ようになる性質を何と呼ぶでしょうか？

ア、一貫性（Consistency）   イ、可用性（Availability）   ウ、冪等性（Idempotency）   エ、原子性（Atomicity）

2. 正解：システム設計・APIに関する正解

正解： ウ、冪等性（べきとうせい）

3. 解説：「何度やっても結果が同じ」という安心感

特に決済システムやメッセージキューを利用した分散システムにおいて、冪等性の担保は設計上の最優先事項の一つです。

【図解：冪等性がある場合とない場合】

■ 冪等性がない例（銀行振込）
・「1万円送金する」という命令を2回送ると、2万円引き落とされる。
・通信エラーで結果が分からない時に再送するのが怖くなる。

■ 冪等性を担保した例
・命令に「リクエストID：A100」を付与する。
・サーバー側で「A100は処理済み」と記録しておけば、2回目が届いても「既に完了しています」と安全に回答できる。

[ HTTPメソッドと冪等性 ]
★ GET, PUT, DELETE：原則として冪等であるべきとされています（何度消しても、無い状態は変わらない）。
★ POST：原則として冪等ではありません（送るたびに新しいデータが作られる可能性がある）。

1. 理解のコツ: エレベーターの「行先階ボタン」をイメージしてください。1回押しても、連打しても、結局その階に止まるという「結果」は変わりません。これが冪等性です。
2. 試験対策の視点: 「同じデータが複数回届いても正常に処理できる」「ある操作を何度繰り返しても結果が同一」という表現があれば冪等性です。分散システムにおける「リトライ処理」とセットで出題されることが多いです。

---

4. まとめ

「同じデータが複数回届いても、正常に処理できることを担保する」。これが冪等性（べきとうせい）です。ネットワークの「もしも」を想定し、二重実行によるデータの不整合を防ぐ、堅牢なシステム設計の要（かなめ）です。

【システム構成】止まらない仕組みの二大巨頭！「冗長化の構成方式」｜情報処理問題1000本ノック

システムを多重化する際、予備の機材をどう待機させておくかによって、コストや性能、切り替え時間が大きく変わります。現場でも頻出の2つの構成をマスターしましょう。

1. 問題：冗長化構成の分類

【 問題 】 クラスター構成において、複数のコンポーネントがすべて同時に稼働し、通常時から負荷を分散して処理を行う方式を［   A   ］、稼働系（Active）のみが処理を行い、待機系（Standby）は故障時に備えて待機する方式を［   B   ］と呼びます。空欄に入る適切な組み合わせはどれでしょうか？

ア、A：アクティブ・スタンバイ　B：アクティブ・アクティブ
イ、A：アクティブ・アクティブ　B：アクティブ・スタンバイ
ウ、A：ホットスタンバイ　　　　B：コールドスタンバイ
エ、A：デュプレックスシステム　B：デュアルシステム

2. 正解：高可用性設計に関する正解

正解： イ、A：アクティブ・アクティブ　B：アクティブ・スタンバイ

3. 解説：効率重視か、確実性重視か

それぞれの方式には、リソースの活用効率や障害発生時の挙動に明確な違いがあります。

【図解：2つの冗長化方式】

■ Active-Active（アクティブ・アクティブ） ★A
・状態：すべての機器が同時に稼働。
・メリット：複数台で処理を分担（負荷分散）するため、システム全体の性能が高まる。無駄なリソースがない。
・注意点：1台故障すると、残った方の負荷が急増し、性能が低下する可能性がある。

■ Active-Standby（アクティブ・スタンバイ） ★B
・状態：1台が本番用として働き、他方は予備として待機。
・メリット：構成がシンプルで、切り替え後の性能変化が予測しやすい。
・注意点：通常時は予備機が何も処理しないため、リソースのコストパフォーマンスは低い。

[ スタンバイ側の「温まり具合」による分類 ]
アクティブ・スタンバイは、待機状態によってさらに細分化されます。
★ ホットスタンバイ：予備機もOSを起動し、即座に切り替え可能。
★ ウォームスタンバイ：OSは起動しているが、アプリケーションは準備中。
★ コールドスタンバイ：予備機は電源オフ（または別の用途で使用）。

1. 理解のコツ: アクティブ・アクティブは「2人で協力して荷物を運ぶ」イメージ、アクティブ・スタンバイは「1人が運び、もう1人は後ろからついてくる（交代要員）」イメージです。
2. 試験対策の視点: 「負荷分散（ロードバランシング）」というキーワードがあればアクティブ・アクティブ、「切り替え（フェイルオーバー）」という言葉が強調されていればアクティブ・スタンバイを意識しましょう。また、デュアルシステム（同じ処理を2系統で行い結果を照合）との違いもよく問われます。

---

4. まとめ

「全員で働くか、予備を置いておくか」。これがActive-ActiveとActive-Standbyの違いです。システムの要求性能やコスト、許容されるダウンタイムに応じて、最適な構成を選択することが設計の鍵となります。

【システム構成】たった一つの故障が命取り！「単一障害点（SPOF）」｜情報処理問題1000本ノック

どれだけ高価なサーバーを並べても、たった一つの部品や回線が共有されているだけで、システム全体が止まってしまうリスクがあります。その「急所」を見つけ出し、対策する考え方を攻略しましょう。

1. 問題：システムの脆弱性と信頼性

【 問題 】 システム構成において、その箇所が故障するとシステム全体が停止してしまうような、冗長化（多重化）されていない単一の箇所を何と呼ぶでしょうか？

ア、ボトルネック   イ、デッドロック   ウ、SPOF（Single Point of Failure）   エ、フェイルセーフ

2. 正解：信頼性設計に関する正解

正解： ウ、SPOF（Single Point of Failure）

※日本語では「単一障害点（たんいつしょうがいてん）」と呼びます。

3. 解説：「鎖の強さは、最も弱い環で決まる」

SPOFをなくすことは、高可用性（ハイアベイラビリティ）を実現するための第一歩です。

【図解：SPOFの具体例と対策】

■ よくあるSPOFの例
・ネットワーク：2台のサーバーを繋いでいるが、大元のルーターが1台しかない。
・電源：サーバーは二重化したが、電源タップが1つでそこから全ての電力を取っている。
・ストレージ：計算機はたくさんあるが、データ保存先が1台のNASに集中している。

■ 対策：冗長化（Redundancy）
・同じ機能を持つ機器を2つ以上用意（多重化）し、一方が故障しても他方が処理を引き継げるように設計します。

[ 関連用語：ボトルネックとの違い ]
★ SPOF：壊れると「停止」するもの（有無の問題）。
★ ボトルネック：そこが詰まると「低速」になるもの（性能の問題）。

1. 理解のコツ: どんなに頑丈な吊り橋でも、メインのワイヤーが1本しかなければ、それが切れた瞬間に終わりです。その「1本しかないワイヤー」がSPOFです。ITシステムでは、サーバー、スイッチ、ディスク、さらには電源や回線、時には「特定の作業ができる唯一の担当者」さえもSPOFになり得ます。
2. 実務・試験の視点: システムの稼働率（可用性）を計算する際、SPOFがある構成では、その箇所の稼働率がシステム全体の最大稼働率を制限してしまいます。設計図（構成図）を見て「ここが死んだら全部止まるな」という場所を探す訓練が重要です。

---

4. まとめ

「多重化されておらず、故障がシステム全体の停止に直結する箇所」。これがSPOF（単一障害点）です。これを見つけ出し、一つずつ消していく作業こそが、止まらないシステムを作るための基本となります。

【コンピュータシステム】外からの合図に即座に対応！「外部割込み」｜情報処理問題1000本ノック

CPUがプログラムを実行中に、外部の機器や内部のタイマーから緊急の知らせが入ることがあります。これらを整理して正しく分類できるようにしましょう。

1. 問題：外部割込みの要因

【 問題 】 コンピュータの割込み処理のうち、CPUの外部にある装置やタイマーなど、プログラムの実行状態とは直接関係なく発生する「外部割込み」に該当するものはどれでしょうか？

1. ゼロによる除算（ゼロ除算）
2. 存在しない命令コード（不正命令）の実行
3. タイマーによる設定時間の通知
4. ページフォールト（主記憶にないページへのアクセス）の発生

2. 正解：割込み処理に関する正解

正解： 3. タイマーによる通知

3. 解説：「内部」か「外部」かの境界線

割込みは、その原因が「CPU内部のプログラム実行によるもの」か「CPU外部の要因によるもの」かで大きく2つに分けられます。

【図解：割込みの種類と具体例】

■ 外部割込み ★今回の正解
・要因：CPUの外側から発生するイベント。
・具体例：
　- タイマー割込み：設定した時間が経過した。
　- 入出力割込み：キーボード入力やディスクの読み書き完了。
　- コンソール割込み：オペレーターによる操作。
　- 機械チェック割込み：電源異常やメモリのパリティエラーなど。

■ 内部割込み（ソフトウエア割込み・例外）
・要因：プログラムの実行中に、その内容によって発生するもの。
・具体例：
　- プログラム割込み：ゼロ除算（選択肢1）、不正命令（選択肢2）、オーバーフロー。
　- SVC割込み：OSの機能（システムコール）を呼び出す時。
　- ページフォールト：仮想記憶の制御（選択肢4）。

[ 覚え方のポイント ]
★ 内部割込み：そのプログラムを実行したから「自業自得」で起きたもの（計算ミスやOSへの依頼）。
★ 外部割込み：プログラムの都合に関わらず「外から勝手に」やってくるもの。

1. 理解のコツ: 外部割込みは、いわば「外からの呼び鈴」です。作業の手を止めて玄関へ向かうように、CPUは現在の状態を一時保存して、割り込んできた緊急事態（入力対応や時間管理）を優先して処理します。
2. 試験対策の視点: 「ゼロ除算」と「タイマー」は、内部と外部を区別する問題で最もよく使われる典型的なキーワードです。この2つの違いを基準に覚えるのが効率的です。

---

4. まとめ

「プログラムの実行とは無関係に外から発生する」。これが外部割込みです。コンピュータが時間通りに動作したり、私たちの入力に即座に反応したりできるのは、この割込みの仕組みがあるおかげです。