情報処理試験を勉強していると、「ロックって何のためにかけるの？共有ロックと専有ロックは何が違うの？」と混乱しがちです。
この記事では、ロック（排他制御）の仕組みを日常の例え話と図解で整理し、試験で得点できる状態まで一気に引き上げます。
対象試験と出題頻度
ロック（排他制御）は、基本情報技術者・応用情報技術者で出題されるテーマです。
データベースの同時実行制御に関する問題として定番化しており、共有ロックと専有ロック（占有ロック）の組み合わせによるロック獲得の可否を正確に判断できるかが問われます。
詳細をクリックして確認
基本情報技術者
応用情報技術者
★★★☆☆
ランクB（標準）覚えておくと有利
用語の定義
ロック（排他制御）とは、一言で言うと
「複数のトランザクションが同じデータに同時アクセスしたとき、データの矛盾を防ぐためにアクセスを制限する仕組み」
のことです。
イメージとしては、「トイレの個室ロック」です。
誰かが個室に入って鍵をかけたら、外の人はその個室を使えません。
鍵が開くまで待つしかない。データベースのロックもまったく同じで、あるトランザクションがデータを「使用中」にしている間、他のトランザクションはそのデータへの操作を待たされます。
ロック（排他制御）の基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Lock / Exclusive Control |
| 目的 | 複数トランザクションの同時実行によるデータ不整合の防止 |
| ロックの種類 | 共有ロック（Shared Lock）、専有ロック（Exclusive Lock） |
| 関連リスク | デッドロック（互いにロック解除を待ち続けて処理が止まる状態） |
解説
データベースでは、複数の利用者が同じテーブルの同じ行を同時に読み書きする場面が日常的に発生します。
もしロックの仕組みがなかったら、ある人が在庫数を「10→5」に書き換えている最中に別の人が古い値「10」を読み取り、二重出荷が起きる。こうしたデータの不整合が頻発します。
この問題を解決するために、「今このデータを使っている」ことを宣言するロック機構が導入されました。
共有ロックと専有ロックの違い
ロックには2種類あります。資格試験でこのまま出ます。
| 種類 | 別名 | 用途 | 他からの読込み | 他からの書込み |
|---|---|---|---|---|
| 共有ロック（S） | Shared Lock | データの読込み時に獲得 | 許可 | 拒否 |
| 専有ロック（X） | Exclusive Lock （占有ロック） |
データの更新時に獲得 | 拒否 | 拒否 |
要するに、共有ロックは「読むだけだから他の人も読んでOK。
ただし書き換えはダメ」、専有ロックは「書き換え中だから読みも書きも全部ダメ」という挙動です。
図解：ロック獲得の可否マトリクス
すでにロックがかかっている資源に対して、別のトランザクションが新たなロックを獲得できるかどうかを一覧にすると、以下の通りです。
ロック獲得の可否マトリクス
| 新たに共有ロック（S） | 新たに専有ロック（X） | |
|---|---|---|
| 既に共有ロック（S） | ○ | × |
| 既に専有ロック（X） | × | × |
▲ ○＝獲得可能、×＝獲得不可（ロック解除待ち）。唯一「S + S」だけが同時に成立する
この表は丸暗記する必要はありません。「読み同士は干渉しないから共存OK」「書き換えが絡むと全部NG」という原則さえ理解していれば、その場で導き出せます。
図解：ロックによる同時実行制御の流れ
具体的にトランザクションAとBが同じデータにアクセスする場面を時系列で追います。
トランザクションA（更新）とB（読込み）の衝突シナリオ
トランザクションA
トランザクションB
▲ 専有ロック中は他のトランザクションの読込み・更新の両方がブロックされる
デッドロックとの関係
ロックには副作用があります。
トランザクションAが資源1をロックした状態で資源2を要求し、同時にトランザクションBが資源2をロックした状態で資源1を要求すると、互いに相手のロック解放を待ち続けて永久に処理が進まなくなります。これがデッドロックです。
デッドロック発生の構図
トランザクションA
資源1をロック済み
トランザクションB
資源2をロック済み
互いに相手の解放を待つ → 永久に処理が進まない
▲ 防止策：資源のロック順序をシステム全体で統一する
デッドロックの防止策としては、「資源のロック順序を全トランザクションで統一する」方法が代表的です。先ほどの例なら、AもBも「資源1→資源2」の順にロックするルールにすれば、循環的な待ちは発生しません。
もう少し詳しく知りたい方向け：ロック粒度とセマフォ
ロック粒度（ロックの範囲）とは、ロックをかける単位のことです。テーブル全体にかけるテーブルロック、行単位にかける行ロックなどがあります。粒度が大きい（テーブル単位）ほどロック管理のオーバーヘッドは小さくなりますが、同時処理性能は落ちます。逆に粒度が小さい（行単位）ほど並行処理しやすくなりますが、管理コストは増えます。
セマフォは、データベースのロックとは異なりOS（リアルタイムOS含む）レベルでのタスク間の資源アクセス制御に使われる仕組みです。AP R4春 午前問17やAP R7秋 午前問16では、タスクの排他的制御に利用するOSの機能としてセマフォが正解になっています。データベースのロックとOS上のセマフォは「排他制御」という目的こそ同じですが、適用レイヤーが異なる点に注意してください。
では、この用語が試験でどのように出題されるか見ていきましょう。
ロック（排他制御）の核心を3行で
・共有ロック（S）＝読込み用。他からの読込みは許可、書込みは拒否
・専有ロック（X）＝更新用。他からの読込みも書込みもすべて拒否
・唯一「共有 + 共有」だけが同時に成立する。それ以外の組み合わせはすべて待ち
試験ではこう出る！
ロック（排他制御）は、FE・APの午前問題でデータベースの同時実行制御として繰り返し出題されています。
出題パターンは大きく2つに分かれます。
過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE H25春 午前 問30 |
排他制御のロック獲得の可否を選ぶ問題 | ・「共有ロック中に別の共有ロック獲得は可能」が正解 ・専有ロック中の共有/専有ロック獲得がひっかけ |
| FE H26秋 午前 問30 |
ロックの動作に関する記述を選ぶ問題（H25春と同一構成の流用） | ・選択肢の文言もほぼ同一 ・FEでは繰り返し同じ形式で出題される典型例 |
| FE H20春 午前 問59 |
ジョブのロック種別の表からロック競合の有無を判断する問題 | ・共有/専有の可否マトリクスを使って各ジョブ組み合わせの待ち状態を判定する |
| AP R4秋 午前 問16 |
二つのタスクが共用資源を排他的に使用するとき、デッドロック発生を防ぐ方法を選ぶ問題 | ・「資源の獲得順序を統一する」が正解 ・AP R7秋 午前問18でも同一テーマが再出題 |
IPA試験での出題パターン
パターン1：「ロック獲得の可否を選べ」
共有ロック・専有ロックの4通りの組み合わせが選択肢に並び、正しい記述を選ぶ形式。正解は毎回「共有ロック中の資源に別の共有ロックは獲得可能」の選択肢です。ひっかけとして「専有ロック中に共有ロックが可能」や「共有ロック中に専有ロックが可能」が紛れ込みます。
パターン2：「デッドロックの防止策を選べ」
複数タスクが資源を排他利用する場面設定で、デッドロックを防ぐ手段を問う形式。「資源のロック順序を一方向に統一する」が定番の正解です。
試験ではここまででOKです。ロック粒度やセマフォのP/V操作の詳細まで問われることは稀なので、深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. データベースの排他制御におけるロック獲得の可否について、適切なものはどれでしょうか？
- A. あるトランザクションが共有ロックを獲得している資源に対して、別のトランザクションが共有ロックを獲得することは可能である。
- B. あるトランザクションが専有ロックを獲得している資源に対して、別のトランザクションが共有ロックを獲得することは可能である。
- C. あるトランザクションが共有ロックを獲得している資源に対して、別のトランザクションが専有ロックを獲得することは可能である。
正解と解説を見る
正解：A
解説：
共有ロックは読込み用のロックであり、他のトランザクションからの読込み（共有ロックの追加獲得）は許可されます。唯一「共有ロック同士」の組み合わせだけが同時成立する点がポイントです。
選択肢Bは不正解です。専有ロックは更新用のロックであり、獲得中は他のトランザクションからの読込み・更新のいずれも拒否されます。選択肢Cも不正解です。共有ロック中の資源に対して専有ロック（書き換え）を許可すると、読込み中のデータが途中で変更されてしまうため、整合性を保てません。
よくある質問（FAQ）
Q. ロック（排他制御）は実務でどのように使われていますか？
実務では、ECサイトの在庫管理や銀行の口座残高更新など「同時書き換えが致命的な結果を招くデータ」に対して使われます。例えばMySQLやPostgreSQLでは、SELECT … FOR UPDATEという構文で対象行に専有ロックをかけ、他のトランザクションからの更新を防ぎます。フレームワークのORM（ActiveRecordやSQLAlchemyなど）にもロック機能が組み込まれており、アプリケーションコードから簡単に利用できます。
Q. 楽観的ロックと悲観的ロックの違いは何ですか？
本記事で解説した共有ロック・専有ロックは「悲観的ロック（Pessimistic Lock）」に分類されます。データアクセス前にロックを獲得して競合を物理的に防ぐ方式です。一方、「楽観的ロック（Optimistic Lock）」はロックをかけずに処理を進め、更新時にバージョン番号やタイムスタンプを比較し、他のトランザクションが先に更新していた場合のみエラーにする方式です。競合が少ない場面では楽観的ロックの方がスループットが高くなります。IPA試験の範囲では悲観的ロックの理解が中心ですが、用語として両方知っておくと安心です。
Q. 「専有ロック」と「占有ロック」は同じ意味ですか？
同じ意味です。IPAの過去問では「専有ロック」と表記される場合と「占有ロック」と表記される場合の両方があります。英語ではいずれもExclusive Lockです。問題文でどちらの用語が使われていても、「更新時にかけるロックで、他のトランザクションからの読込み・更新を一切許可しないもの」として判断すれば正答できます。
Q. デッドロックが起きたらDBMSはどう対処しますか？
多くのDBMSにはデッドロック検知機能が組み込まれています。一定時間ごとに「待ちグラフ（Wait-for Graph）」を監視し、循環待ちを検出したら、コストの低い方のトランザクションを強制的にロールバック（取り消し）して循環を解消します。ロールバックされた側のトランザクションはアプリケーション側でリトライする必要があります。
