1 ロック粒度の概念
1.1 定義と位置づけ
ロック粒度とは、共有資源（データ項目、記憶領域、論理オブジェクトなど）に対して、排他制御を行うときにロックを取得する単位の細かさ、またはその範囲の大きさを指す。粒度が細かいほど同時に進められる処理の組み合わせが増えやすく、粒度が粗いほど管理は単純になりやすい。
この概念は、並行実行の正しさ（競合の抑止、整合性の維持）と性能（待ち時間、スループット）を同時に左右する設計の中核として位置づけられる。実装の都合だけでなく、データ構造、アクセスパターン、分散配置、障害時のふるまいまで影響が及ぶため、システム全体の性能工学と密接に関連する。
1.2 粒度の大小が与える影響
1.2.1 並列性への影響
粒度を細かくすると、異なる対象へアクセスする処理は別々のロックで分離されやすい。その結果、同時実行が成立する範囲が広がり、待ち行列が短くなる傾向がある。一方で、細かな対象ごとにロックを管理しなければならないため、ロックの作成・保持・解放・競合判定が増える場合がある。
粒度を粗くすると、同一ロックがより多くの対象をカバーするため、競合の起きる組み合わせが増える。すると同時実行の余地は縮小し、ワークロードが多様な更新を含む場合に特に待ちが顕在化しやすい。
1.2.2 オーバーヘッド（管理コスト）への影響
ロック粒度が細かい場合、ロック管理のためのメタデータ量や、ロック取得の経路（探索、参照、整形）が増えやすい。さらに、ロック保持時間が短いとしても、取得回数が膨らむことで合計の調整コストが上積みされることがある。
粒度が粗い場合は取得回数が減るため、ロック操作そのものの回数は相対的に抑えられやすい。しかし一度ロック競合が発生すると、より広い範囲の処理がまとめて待たされるため、結果的に全体の効率が下がる可能性がある。したがって、コストは「回数」と「待ちの増幅」の両面で評価する必要がある。
1.3 関連用語との違い
1.3.1 ロック種類との関係
ロック粒度は「どれだけの範囲をロックするか」という軸であるのに対し、ロック種類は「その範囲に対してどのモードで排他するか（共有／排他など）」という軸に対応する。粒度を細かくしても、強い排他モードを選べば競合は起きるため、性能や待ちの性質は粒度と種類が相互に作用して決まる。
実務では、粒度と種類がセットで設計されることが多い。例えば、行単位に共有アクセスを許しつつ更新は排他にする、といった組み合わせが検討される。
1.3.2 トランザクションと整合性の関係
トランザクションは、複数操作をひとまとまりの変更として扱う単位であり、整合性（状態が矛盾しないこと）を保つための枠組みである。ロック粒度はトランザクション内部で、どのデータ範囲を保護するかに直結する。整合性の確保は、粒度そのものだけでなく、トランザクションがどのタイミングでロックを取得し、どの程度保持するかにも依存する。
また、整合性を満たすための条件（例えば直列化可能性や隔離の要件）は、粒度とロック管理戦略を通じて実現されることが多い。その意味で、ロック粒度は「整合性を実装するための手段」の一部として位置づけられる。
2 粒度の代表的な種類
2.1 データベースにおける粒度
2.1.1 テーブルレベル
テーブルレベルの粒度では、表全体を単一のロック単位として扱う。更新が広範に及ぶ場合には管理が容易だが、参照や更新が局所的でも全体が連動して待ちやすい。多人数環境で更新が集中すると、並列実行の効果が縮みやすい。
2.1.2 ページ／ブロックレベル
ページまたはブロックといった単位でロックする方式では、テーブルより細かい範囲分割によって競合を減らせる。典型的には、物理的な配置単位に近い単位であるため、データの偏りがあると一部のページにアクセスが集中し、局所的な競合が起こる。
2.1.3 行（レコード）レベル
行単位の粒度は、更新対象が比較的独立している場合に高い並列性を提供しやすい。複数行への変更でも、必要な行にだけロックを取得する設計にできるため、不要な待ちを抑えやすい。ただし、行数に比例してロック管理の負担が増え得るため、更新件数が多い場合は別の最適化が必要になることがある。
2.1.4 キー（インデックス）レベル
インデックスのキーごとにロックする発想では、検索や条件絞り込みに密接した単位で競合を分離できる場合がある。特に、更新が索引に沿って発生するワークロードでは有利になりやすい。
一方で、範囲検索や複合条件が多い場合には、多数のキーや周辺範囲を巻き込む可能性がある。その結果、細かい粒度を選んだのに実質的には粗い範囲を扱う状態になり得る。
2.1.5 パーティション／シャードレベル
パーティションやシャードに基づく粒度では、データを分割した単位ごとにロックを管理する。分割がアクセスの偏りと整合している場合、競合は分散され、並列性が伸びやすい。反対に、特定パーティションへアクセスが集中すると、粒度を粗くした場合と同様の待ち増大が起こることがある。
2.2 分散システムにおける粒度
2.2.1 ノード（ホスト）単位
分散配置された計算資源に対して、ノード単位でロックを扱う構成がある。実装は比較的単純になりやすいが、単一ノード内の複数オブジェクトがロックによって同じ影響を受けるため、並列性は局所的に制約されやすい。
2.2.2 セグメント（範囲）単位
キー空間やオブジェクト識別子の範囲をセグメントとして分割し、その範囲単位でロックする方式がある。範囲が均等に分布していれば競合は薄まり、偏っていればホットスポットが顕在化する。設計上は、分割境界の選び方が性能に強く影響する。
2.2.3 オブジェクト（識別子）単位
オブジェクトごとに識別子ベースでロックを管理する粒度は、独立性が高いワークロードに適合しやすい。特定のデータ項目だけを更新する場合に待ちを抑えやすい反面、ロック管理の情報量が増え、メモリやメッセージ処理量に影響が出ることがある。
2.3 ファイルシステム・ストレージにおける粒度
2.3.1 ファイル単位
ファイル単位のロックは、アプリケーションがファイルを単位としてアクセスする場合に分かりやすい。複数スレッドが同一ファイルの異なる領域を扱うと、実際には競合していないにもかかわらず待ちが発生し得るため、アクセスパターンに依存する。
2.3.2 領域（セクション）単位
領域単位の粒度では、ファイル内のセクションやオフセット範囲に沿ってロックを設定できる。部分更新が多い場合には有効で、不要なブロックを避けやすい。ただし、どの範囲をロックするかの算出が複雑になり、境界の取り扱い（重なり判定など）が実装負担になることがある。
2.3.3 メタデータ単位
メタデータ（属性、ディレクトリエントリ、割り当て情報など）に対して粒度を設ける考え方がある。たとえばファイル本文とメタデータが異なる操作で変化するなら、粒度分離によって競合を抑制できる可能性がある。もっとも、メタデータ更新は整合性の要件が厳しくなりやすく、ロック範囲や順序の設計が重要になる。
3 選定基準と設計判断
3.1 ワークロード特性からの判断
3.1.1 更新頻度と競合率
更新が頻繁で、かつ同じ対象に集中するなら競合が増えるため、粒度を細かくする価値が高まりやすい。逆に更新が少なく、衝突がほとんど起きないなら、細分化による管理負担が相対的に目立ちやすい。
競合率は平均だけでなく分布にも依存する。平均が低くても、短時間のスパイクで局所競合が発生する場合があるため、測定は時間軸を含めて行うのが望ましい。
3.1.2 参照中心か更新中心か
参照主体の環境では、同時実行の多くが読み取りとなるため、ロックの方式（共有／排他）や読み取り時の扱いが効く。粒度を過度に細かくしても効果が薄いことがあり、ロック操作の増加が純増コストになる場合がある。
更新中心では排他が支配的になりやすいため、粒度による待ちの差が顕在化する。更新対象の独立性がどれくらいあるかを基準に判断することが多い。
3.1.3 アクセスの偏り（ホットスポット）
ホットスポットが存在する場合、細粒度にしても同一対象へ多数が集中すれば競合は消えない。むしろロック単位が細かいほど、同じホット対象の周辺で密な待ちが発生し、スケールの伸びが鈍化することがある。
偏りへの対処としては、分割戦略（パーティションのキー設計やシャーディング）やキャッシュの併用、あるいは更新のバッチ化など、粒度以外の手段と合わせて考える必要がある。
3.2 性能指標との対応
3.2.1 スループット
スループットは同時処理量に左右されるため、粒度が適切なら待ちが減って処理が前進しやすくなる。ただしロック取得や管理の手数が増えすぎると、待ちが減っても総処理が伸びない。したがって粒度は、待ち時間の短縮と管理コストの増加のバランス点を探す対象となる。
2.2.2 レイテンシ
レイテンシは特に「渋滞」の影響を受けやすい。粒度を粗くすると、競合が起きた瞬間に待ちの長さが増えやすい。一方で、細かくするとロック操作の回数が増えて処理経路が重くなり、競合が少ないケースでも一定の遅延を生むことがある。平均値だけでなく分位点（たとえば尾側）を観測することで判断精度が上がる。
3.2.3 スケーラビリティ
スケーラビリティは、スレッド数やノード数を増やしたときの伸び方で評価される。粒度が合わないと、競合や待ちが支配的になり、追加の実行単位が活かされない。逆に粒度が適切であれば、独立性の高い処理が並び、計算資源の増加が実効につながりやすい。
3.3 実装・運用の観点
3.3.1 ロック管理の複雑さ
粒度が細かくなるほど、ロック対象の列挙、範囲衝突の判定、保持中の状態管理が複雑になりがちである。加えて、ロックの取得順序や解放タイミングの設計にも注意が必要になる。実装が複雑になることでバグの発生確率も上がるため、検討にはコスト見積もりが不可欠である。
3.3.2 デバッグ容易性
粗い粒度は、ロック競合の原因となる範囲が見通しやすく、トレース上で現象を把握しやすいことがある。細かい粒度は、競合が特定の要素に偏るため、再現性の確保やログの粒度設計が難しくなり得る。デバッグ戦略（計測点の設計、観測指標、再現手順）が粒度の選択と一体で考えられるべきである。
3.3.3 運用時のチューニング性
運用では、負荷変動、データ成長、クエリ形状の変化などにより最適点が動く。粒度を調整できる余地がある場合、段階的にチューニングして最適化しやすい。逆に粒度が固定に近い設計では、データ分割やクエリの設計修正でしか対処できず、時間と費用が増えやすい。
4 論点：競合と安全性
4.1 デッドロック
4.1.1 発生メカニズム（粒度との関係）
デッドロックは、複数の処理が互いに必要なロックを解放するのを待ち続け、前進不能になる状態である。粒度が細かいほど、同一トランザクション（または処理）内で保持するロックが増えやすく、取得順序の多様性も増える。その結果、循環待ちの形が作られやすくなる場合がある。
粒度が粗い場合でもデッドロックは起こり得るが、ロック数や取得経路が単純になりやすいため、発生パターンが限定されることがある。とはいえ、複数の粗ロックをまたぐ設計では循環が成立し得るため、「粗いなら安全」とは言えない。
4.1.2 回避・検出の考え方
回避の代表的手段としては、ロック取得順序を全経路で統一する方法がある。細粒度では取得対象が増えるため、順序統一の徹底がより重要になる。また、保持期間を短くし、不要なロックを早期に解放する設計も有効である。
検出については、待ちグラフの循環を検出する仕組みや、タイムアウトに基づく巻き戻し・再試行が用いられる。運用上は、検出コストと誤検知の扱い、再試行時の副作用（負荷増など）を事前に評価する必要がある。
4.2 スターべーション（飢餓）
4.2.1 優先度設計と待ちの偏り
スターべーションは、ある処理が継続的にロックを取得できずに進めない状態である。粒度が細かいと、競合対象が分散して見えても、優先度や到達順の設計次第で特定の系統が常に割り込まれ、待ちが解消されないことがある。
優先度付きキューイングや公平性の方針（先着順、ラウンドロビンなど）を明確にしないと、平均的な性能は高くても、遅延の大きい処理が長く放置されることがある。
4.2.2 再試行戦略の影響
再試行は衝突時の一般的な対処であるが、粒度が細かく衝突が多い場合、再試行による再競合が連鎖して全体の負荷が上がることがある。特に同期的に再試行が起きると、リトライの波が同時に発生し、状況が改善しない。
ランダム化した待機や指数バックオフ、あるいは競合回避のための手順（別順でのロック取得、部分更新への切替）を組み合わせると、飢餓の確率を下げられることがある。
4.3 一貫性（整合性）とロックの整合
4.3.1 直列化可能性との関係（概念整理）
直列化可能性は、並行処理の結果が、ある順序で実行された場合と同じ効果を持つことを求める概念である。ロックは、競合する操作が矛盾した順序で見えないように制御することで、一貫性の保証に寄与する。
ただし、粒度がどれほど細かくても、ロック取得の設計や隔離条件が要件を満たさなければ直列化可能性が成立しないことがある。逆に、粒度が粗くても、適切なルールでロックを確保すれば要件を満たし得る。したがって粒度は手段であり、整合性の条件そのものはロック戦略全体で評価される。
4.3.2 隔離レベルとの関係（概要）
隔離レベルは、複数トランザクションが同時に走るときに、互いの変更がいつ、どの程度見えるかの許容範囲を定める。ロック粒度は隔離の実装に影響し、細かい粒度はより局所的な整合性制約を与えやすい。一方で、隔離要件が強い場合は、必要な範囲が実質的に拡大し、細粒度の利点が薄れることがある。
実務では、隔離レベルの要件に対して、粒度とロック種類、さらにロック保持の範囲を組み合わせて整合性を満たす設計へ落とし込む。
5 チューニングとベストプラクティス
5.1 粒度の動的調整（可能な場合）
システムによっては、負荷状況や競合観測に応じて粒度を切り替える仕組みがある。例えば、競合が低いときは細かい対象で管理し、競合が高いときはより広い単位にまとめることで、管理コストと待ちのトレードオフを最適化する。
ただし動的調整は、切替時の整合性維持や移行コストが問題になり得るため、単純なルールでは不十分な場合がある。段階的な適用、観測指標の選定、切替の安全性検証が前提となる。
5.2 ロックコストを下げる工夫
5.2.1 ロック取得範囲の最小化
必要な範囲だけをロックすることは基本原則である。例えば、更新対象が条件で絞られるのに、計画が不十分で広い範囲までロックしてしまうと、競合が増えやすい。範囲の推定精度やアクセス経路の設計によって、粒度の実効範囲を狭められる余地がある。
5.2.2 クリティカルセクション短縮
ロック保持中に行う処理を減らすと、待ちの発生点が前倒しされにくくなる。計算量の多い処理や外部I/Oは可能な限りロック外へ移し、必要データの取得と更新だけを保護範囲に含めるのが一般的な考え方である。
また、更新前後の整合性検証をどこで行うかも影響する。検証をロック外へ移すことで矛盾検知のタイミングが変わる可能性があるため、正しさを確保できる範囲で整理する。
5.3 ホットスポット対策
5.3.1 シャーディング・分割
ホットスポットが特定キーに偏る場合、キー設計や分割ルールの見直しが有効である。均等な分布を目指すだけでなく、アクセス頻度の高いパターンに対して分割が競合を分離できるかを確認する。
既存データの再配置はコストを伴うため、移行計画や段階的導入（部分シャードから開始など）を立てるのが現実的である。
5.3.2 キャッシュと整合性の扱い
キャッシュは読み取り競合を減らすことで、ロック要求の回数を間接的に削減できる。更新系が競合する場合でも、読み取り優勢のワークロードでは効果が出やすい。
整合性は、キャッシュの無効化、更新伝播、読み取り時の整合性要件の整理が鍵になる。ロックで直接守る範囲を減らすのか、キャッシュ更新時に追加の同期を行うのか、といった設計方針を一貫させる必要がある。
6 具体例とケーススタディ
6.1 少数競合で行う行ロックの例
アプリケーションが顧客ごとのレコードを独立に更新し、同一顧客への同時更新が稀な場合、行単位のロックは有効になりやすい。複数スレッドは異なる顧客の行に対して並列実行でき、待ち時間は競合の発生確率に従って限定される。
ただし、バッチ処理で大量の顧客行をまとめて更新する局面では、取得するロック数が急増し、管理コストやデッドロックリスクが増える。そこでロック順序の統一や、更新の分割（チャンク化）が併用されることがある。
6.2 多数競合でテーブルロックが有効な例
全ての処理が同一の集計表を更新し、更新が短時間に集中するようなケースでは、粒度を細かくしても競合対象がほぼ一致する。その場合、行やキーに分けても待ちの解消は限定的で、むしろロック管理が増えて無駄になることがある。
テーブルレベルで排他を取り、一連の更新をまとまって実行することで、競合の調停コストを減らし、全体の安定性を高める選択が合理的になる場合がある。
6.3 インデックス中心のアクセスにおけるキー粒度の例
検索条件が常に特定のキーに一致し、そのキーに対応する行だけを更新するようなワークロードでは、キー粒度のロックが適合しやすい。参照や更新が同一キーに衝突したときだけ競合し、それ以外のキーは独立して進められる。
ただし、範囲条件や複合キーの組み合わせが混在すると、対象範囲の見積もりが難しくなる。結果として想定以上に多くのキーにロックが及び、期待した並列性が得られないことがあるため、クエリ形状の棚卸しが重要になる。
6.4 分散環境での注意点
分散環境では、ロック取得や解放のたびにネットワーク往復が発生し得るため、粒度の影響は局所的な待ちだけでなく通信回数にも波及する。細粒度にするとロック操作が増え、通信のオーバーヘッドが増えることがある。
さらに、部分障害や遅延が起きるとロックの保持時間やタイムアウトに影響が出る。再試行の設計や、冪等性の確保（同じ操作を繰り返しても安全であること）、フェイルオーバー時の状態復元など、粒度以外の設計要素との整合が必要になる。
7 よくある誤解とQ&A
7.1 「粒度が小さいほど常に速い」は本当か
常に速くなるわけではない。細かいほど競合が減りやすいのは事実だが、ロック操作や管理の回数が増えることで、競合が少ない領域ではかえって遅くなることがある。結果は、競合率、ロック保持時間、管理コスト、処理経路の複雑さにより決まる。
したがって判断には、想定負荷の下での測定と、分位点を含む評価が必要である。机上の一般論だけで粒度を極端に細めることは避けるのが無難である。
7.2 ロック粒度とトランザクション寿命の混同
ロック粒度は保護対象の範囲であり、トランザクション寿命はロックが保持される期間に関する概念である。粒度を細かくしても、処理が長引けば待ちや競合の影響は大きくなり得る。逆に、寿命を短くしても粒度が粗すぎれば競合は増えやすい。
両者は別の軸なので、同時に評価する必要がある。実装では、粒度変更とあわせて、処理の分解、ロック外への計算移動、更新のチャンク化なども検討対象になる。
7.3 設計レビューで確認すべき観点
7.3.1 ロック取得順序
デッドロックを避けるには、複数ロックを取得する経路の順序を統一することが重要である。特に粒度が細かいと取得数が増え、順序の組み合わせが爆発しやすい。レビューでは、例外経路や成功・失敗パスも含めて順序が守られているかを確認する。
また、順序の定義をコード上で明示し、将来の変更でも破られにくい形にしておくことが実務上の効果につながる。
7.3.2 想定最大競合と性能見積もり
平均負荷だけで設計すると、ピーク時に待ちが支配的になり性能目標を外すことがある。レビューでは、想定最大競合（同時にロック要求が集中する条件）を見積もり、そのときの待ち時間と管理コストを概算する。
併せて、データ成長やクエリ頻度の変化によりホットスポットが移動する可能性も考慮する。性能は固定ではなく変動するため、見積もりには前提条件と観測計画を含めるのが望ましい。