スコープノート
この記事の二乗則の結果は、共有された可変作業の下での潜在的なペアの相互作用に関するものです。これは、上位レベルの計画に関する強力なシグナルであり、すべての展開について約束するものではありません。実際の競合は、ワークロードの局所性、ロック規律、データまたは権限の境界によってすでに分割されている作業の量によって異なります。
1. 組み合わせのコア
If n agents can interfere with one another in the same workspace, the number of unordered pairs is n(n-1)/2. That alone is enough to explain why conflict pressure rises much faster than team size in unpartitioned parallel systems.
If each pair has conflict probability p, a useful expectation is E[conflicts] = n(n-1)/2 * p. This is the right first-order reason to stop assuming that doubling agents doubles useful throughput.
2. Why the old partition formula was wrong
この記事の以前のバージョンでは、ゾーンの数に対する普遍的な最適値 Z* = sqrt(n / p) が主張されていました。その結果は精査に耐えられませんでした。これには、互換性のない目的と、共通のパラメーター設定で実質的にゾーンごとに 1 つのエージェントである暗黙の操作点が混在していました。
The right lesson from the square law is simpler: if you hold zone size fixed while the total fleet grows, total collisions grow roughly linearly. If you hold zone count fixed while the fleet grows, collisions remain superlinear because each zone becomes crowded.
3. ゾーン数だけでなくゾーンサイズに基づいてモデル化する
Let each zone hold k agents on average, so Z = n / k zones. If conflicts are mostly within-zone, expected collision burden is approximately C(k) approx Z * k(k-1)/2 * p = n(k-1)p / 2.
This makes the key design point obvious. For fixed k, conflict grows like O(n). Near-linear behavior comes from bounded zone size, not from a special formula in Z alone.
4. Smaller zones are not free
If smaller zones always won, we would use one agent per zone. But splitting work creates cross-zone merge, synchronization, and review overhead. A simple planning proxy is M(k) = b * n / k, where b captures the average merge cost per zone boundary.
The total coordination burden can then be approximated as B(k) = a * n * (k - 1) * p / 2 + b * n / k, where a prices the cost of one within-zone collision and b prices the cost of one zone boundary.
5. より良い最適化
B(k) を最小化すると、k* およそ sqrt(2b / (a * p)) が得られます。これは、衝突確率が上昇した場合にはゾーン サイズを縮小し、クロスゾーン マージ コストが高くなった場合には拡大する必要があるという直観的なことを述べているため、より防御可能な設計ルールです。
暗黙のゾーン数は「Z = n / k」となり、フリートの合計サイズにほぼ直線的に比例します。これはまさに、組織が成長するにつれてローカルの競合を制御したい場合に期待されることです。
6. パラメータの推定方法
直感ではなく、実際の衝突または上書きログから「p」を推定します。 1 つの競合イベントのコスト (作業の損失、再試行の遅延、レビューの負担、またはロールバックの労力) から「a」を推定します。追加のゾーン境界を維持するためのコスト (マージ作業、調整遅延、およびゾーン間の承認) から「b」を推定します。
パーティショニングが無料であるかのようにチームに 2 つの実際のコストを比較させるため、大まかな見積もりであっても役立ちます。
7. MARIA OS ゾーンの運用ガイダンス
In MARIA OS terms, a zone should be large enough that local coordination is worthwhile and small enough that conflicts stay local and understandable. Split a zone when collision rate per decision climbs, when merge work inside the zone starts to dominate execution time, or when reviewers can no longer explain ownership boundaries clearly.
ゾーン間のハンドオフが優勢で、ローカル衝突圧力がすでに低い場合にのみ、ゾーンをマージします。オペレーターは、すべてのユニバースに共通する 1 つの公式という観点ではなく、ターゲット ゾーンのサイズと測定された競合という観点から考える必要があります。
8. 内部リプレイの要点
内部実行リプレイにより、理論の堅牢な部分が確認されました。分割されていない共有作業では、フリートが成長するにつれて紛争圧力が急速に上昇することが示されましたが、境界ゾーンのサイズにより、紛争の成長は直線にかなり近づきました。正確な節約量は、ゾーン間のマージ規則に大きく依存します。
それが実際的なポイントです。組織が境界で何が起こっているかにも注意を払っている場合にのみ、パーティショニングは役に立ちます。
結論
The square law of potential collisions is real and important, but it is only the starting point. The design problem is not to memorize a flashy sqrt(n / p) rule. It is to balance within-zone collision cost against cross-zone merge cost and to keep zone size bounded as the fleet grows. That is what turns quadratic conflict pressure into something an operating system can actually manage.