ホームマップ土地利用規則の改正について

　ホームマップ土地利用規則は2013年の制定以来7年以上にわたって有効に機能しています。それだけの年月に耐えうる規則を制定されたことには敬意を表します。

　一方その7年の間に、解釈の関する議論も時々生じたこと、制定以降のMinecraftや技術のアップデートに対応しきれていない点などについて、改定の必要性を漠然と感じていました。また改定するにしても、重複した定義や同一事象を示す複数の単語の混在など、規則自体の読みにくさ（それ自体も改善の対象になるかと思います）により気力がそがれたこともあります（私事ですが）。

　今回、新たな議論が起こったことを契機として、全文を再検討し、改正すべきではないかというポイントを4点にまとめました。つきましては各位のご意見を賜りますよう、お願いいたします。

　現在の改正案の全文はver.02w08です。なお「以前のリビジョン」により、初版との相違点を確認することができます。

　なおあらかじめ断っておきますが、今回の改正提案は、すべてを遡及適用させるものではありません。正確に言うとまるで正反対のようですが、「すべて遡及適用させるが、その結果違反となる事項については罰則も設けずサーバールール違反ともせず、極めて緩やかに解消に努めてもらう」。これは、遡及適用した場合改正規則への違反状態が生じるような改正と、現状と規則の乖離を追認し現行規則への違反状態を解消することとなる改正が混在しているためです。

　この「大路」の概念について、規則上は、「大路はゲートから延びる道」「大路をふさぐな」「大路は決められた範囲or海岸線まで」の三点しか示されておりません。その結果その解釈の余地をめぐって議論がしばしば起こりますが、その割には、明確なコンセンサスは出ていないように思います。

また最近の議論において、「ゲートが海上に設置されることを想定していなかった」「大路が河川に優先されて設置されることは特に考えていなかった」等の発言がサーバー管理者からもありました。 以上を踏まえて現行の条文を見直した結果、第６条を全面改訂すべきではないかとの思いに至りましたので、以下に各条文とその作成理由を示します。

　第1項において遠方ゲート等を定義していることもあり、文意も通じるので章題を修正します。

1. 原点（x及びz座標がいずれも0の地点をいう。以下同じ。）及び遠方ゲート（以下「遠方ゲート等」という。）は、ユーザーが容易にアクセスできるように、その周辺（遠方ゲート等を中心に少なくとも9ブロックの円形の範囲内）を保全しなければならない。なお、原点についてはサーバー管理者が、遠方ゲートについてはユーザーが、その保全に努めなければならない。

　大路の前に、まずゲート周辺の保全を定めます。これは3つの理由によります。
　1つ目は、ゲート周辺のスペースが極端に狭くなることを防ぐためであり、
それにより大路の幅を広く確保しやすくするためです。
　2つ目は、Home02において海上にゲートが設置された際に、海面高さより上に
ゲートが設置された結果、いったんゲートを出てしまい水中に入るとゲートに
戻れない、戻るためにはブロックを設置しなければならない、という状況があった
ことなどを踏まえ、ゲートへのアクセスを確実に確保することを求めるためです。
　なお海上ゲートのアクセスはすべてボートによる、というユニークな発想も
考えられますので、ゲート周辺に地上を確保することを必須とはしません。
　3つ目は、この規定が陸上海上のみならず、将来的に第二ホームネザーや
第二ホームエンドへの適用も視野に入れるべきであると考えるためです。
　これは「ゲートを出たら溶岩の海」といったトラップ状態を避けるため、と
いう点で、2つ目の理由を補強するものと考えます。

2. 記号付きリスト遠方ゲート等を収容するような建造物を建設する場合は、可能な限り遠方ゲート等への視線を妨げないようにしなければならない。

　「遠方」ゲートという書き方から、規則制定時には遠方ゲートとそれ以外とに
線引きをする意識が背景にあったことは明らかですが、仮に今新規ユーザーが
来た場合、果たして遠方ゲートを中心として発展した町と、発展した町に
設置されたゲートと、両者を見分け区別することができるかというと、
はなはだ疑問です。
　Home01の大根やディルフウォンズといったゲートは建物内に設置されており、
遠方ゲートを建物で囲うという発想は当然あり得ますし、実際にHome02でも
いくつかのゲートが建物内にあります。アクセス等が適切にデザインされた
建物であれば、ゲート周辺の市街の魅力を増すものになるのではないかと
思いますので、建物で囲うこと自体は禁止すべきではないと思います。
　ただ、初めて訪れたユーザーが、町を探索した後、少しでも容易にゲートに
戻ることができるようにすべきではないか、というのがこの条文の趣旨であり、
これは後述する大路の「ふさぐ」ことを禁止する規定とも根底の趣旨を一に
するものと考えます。

3. 遠方ゲート等から直線状に延びる道（以下「大路」という。）及びその延長線をふさぐ建物を建築することは、これを禁止する。

　現行第1項の改定版です。
　大路の形状について「直線状」と明確に定義しました。
これは、曲がりくねった大路の存在を考えたときに、建物を建てるユーザーに
とって、どのような形が「ふさぐ」、特に「延長線をふさぐ」に当たるのかを
直感的に判断することができないためです。規則のコンセプトにある
「単純明快な土地利用」を進めるためには、必要ではないかと考えました。
　また、大路の定義から延長線を外しました。これはすでに建設されたものと
予定のものを分ける意味合いです。
　なお大事な点として、遠方ゲート等から、曲がりくねった道を伸ばすことを
禁止する規定とはしていません。大路としてのメリットは得られませんが、
例えばHome01の円規花のような町割りを作れる余地は残したいと考えます。

4. 大路及びその延長線上に、その形状が川や海と認められる水源があるときは、水面上をボートが自由通行できるよう、形状を保持しなければならない。

　大路とボートの航路のバッティングに対しては特に明確な規則がないことは
指摘されてきたところであるので、これを明確化しました。
　なお、どういう形かはともかく、代わりの通過水路を設置することは問題
ないと解釈しています。明文化の必要があれば、書き足せばよいかと思います。

5.前2項の規定は、サーバー管理者又は遠方ゲート等をその域内に持つ町が定めた範囲内においてのみ、適用される。ただし、範囲が定められていないときは、遠方ゲート等から12チャンク（遠方ゲート等の所在するチャンクを除く）をその範囲とする。

　現行第2項の改定版です。ふさぐ建物だけでなく、ボート航路についても
範囲を設定する必要があることから、ここに設置します。
　原点については通常サーバー管理者が中央特区の範囲を定めるであろうことから
いいとして、現行条文にある町の管理者を加えるかどうかは議論の余地があるところだと
思います（遠方ゲートと町ゲートを峻別する立場、あるいは区別しているこの条文の
前提からはなおさらです）。
　ここでは、無機物である「町が定めた」としています。これは、町が定める
ためには、そこに一定のコンセンサスが必要になってくると考えられるためです。
　なお12チャンクは、Minecraft 1.15.2でのデフォルトの描画距離を根拠としています。

6. 大路の延長を持ち、原点もしくは遠方ゲートの座標を中心とした幅9ブロックの柱状の領域は、公共交通路予定帯と見なす。

　Home02の話になりますが、大路と公共交通路予定帯の関係性で気になるのが、
遠方ゲートは下2桁00の位置に立っているのに公共交通路予定帯は00-09の幅と
されていることです。
　一般に大路はゲート位置を中心に左右対称の幅の道で作られることが多いので、
その場合大路の半分は予定帯を外れることになり、大路の上下に鉄道を引こうと
すると、気軽に使えるのは大路の道幅の半分ということになります。もちろん
残りの半分もしっかり占有表示すればいいだけではありますが。
　ただ、大路の道路としての機能及び実装はほぼ地表面のみに限られる一方、
ゲートに直結する地下・空中空間が容易に確保されることから、利便性、公共性、
占有との競合といった点からも、大路の地下及び上空は公共交通路を引くのに
絶好の場所であり、両者の親和性の高さも有効活用すべきであろうと考えます。
さらに、交通路が一か所に収まりことにより、ゲート周辺で利用可能な土地が
増えるという、公共交通路予定帯の概念が持つメリットも活かせます。
　そこで、大路が引かれたならば、幅を区切ってこれを予定帯と見なすことと
します。あくまで引かれた大路を対象とし、延長線は含めません。これにより
公共交通路の建設が容易となります。
　なお9ブロックの根拠は、地下鉄を基準に、側壁１ブロック＋ホーム２ブロック
＋線路１ブロックの４ブロック幅を、線路を隔てる１ブロックを挟んで両側に
設置した場合（壁ホホ線隔線ホホ壁）、というものです。

以上が、第６条を全6項に改正する提案です。

　例えば、地下の公共交通路の占有表示は、公共交通路予定帯では表示の省略が可能（2-5-VI-cと3-5）だが地上を占有される可能性あり（2-5-VI-c）、公共交通路予定帯以外では簡素な方法（2-5-VI-a）で表示が必要（3-5）、という規定である、と整理されます。

　しかし、見てのとおり同一の規定が重複しており、また関連する項目が複数の条項にわたっています。さらに2-5-VIでは「予定帯以外の」地下について簡素な方法を使用可能、としているにもかかわらず、その下位の2-5-VI-cでは「公共交通路予定帯上においては」と予定帯について書かれているなど、非常に複雑かつ直感的ではない構成となっています。

　これらを整理してできるだけ直感的な条文構成にするため、第２条と第３条を大幅に組み替えた上で、所要の改正を行うことを提案します。なお以下では公共交通路予定帯内を「帯内」、公共交通路予定帯以外を「帯外」と表記します。

• 2-5-VI 帯外での簡素な占有表示の認定　→　修正の上、移動(3-11)
• 2-5-VI-a 帯外での簡素な占有表示の方法　→　文言調整の上、移動(3-11-I)
• 2-5-VI-b 帯外での簡素な占有表示の効力　→　文言調整の上、2-5-VI-aと併合(3-11-I)
• 2-5-VI-c 帯内での簡素な占有表示の公共交通路予定帯内の省略と地上の占有　→　文言調整の上、移動(3-13)
• 2-5-VI-d 簡素な占有表示の期間　→　文言調整の上、移動(3-12)
• 3-1 公共交通路の定義、追記マップ供用開始前の土地の確保　→　本文は文言調整の上、継続(3-1)／追記は独立(3-14)
• 3-2 歩道と公共交通路の関係　→　修正の上、継続(3-2)
• 3-3 公共交通路予定帯の定義　→　文言調整の上、継続(3-3)
• 3-4 帯内の公共交通路は近隣許可不要、ただし占有済の地上を除く　→　本文は文言調整の上、継続(3-6)／ただし書は次条に独立(3-7)
• 3-5 帯内の地下の公共交通路の占有表示の省略、ただし帯外は省略不可　→　本文は2-5-VI-cと重複のため削除／ただし書は一般の占有ルールと同内容のため削除
• 3-6 帯内の他の公共交通路との調整　→　修正の上、移動(3-4)
• 3-7 帯内の歩道との調整不要、ただし破壊等を禁止、改修に鯖管理者許可要　→　文言調整の上、移動(3-5)
• 3-8 帯外の他者占有地との隣接時は近隣許可必要　→　文言調整の上、継続(3-8)
• 3-9 近隣許可に伴う不在時の措置　→　修正の上、継続(3-9)
• 3-10 近隣許可に伴う不在者との対話　→　修正の上、継続(3-10)

• 2-5-VI （削除）
• 3-1 公共交通路の定義、追記マップ供用開始前の土地の確保(現3-1)
• 3-2 歩道と公共交通路の関係(現3-2)
• 3-3 公共交通路予定帯の定義(現3-3)
• 3-4 帯内の他の公共交通路との調整(現3-6)
• 3-5 帯内の歩道との調整不要、ただし破壊等を禁止、改修に鯖管理者許可要(現3-7)
• 3-6 帯内の公共交通路は近隣許可不要(現3-4本文)
• 3-7 帯内の地下敷設時は占有済の地上の許可要(現3-4ただし書)
• 3-8 帯外の他者占有地との隣接時は近隣許可要(現3-8)
• 3-9 近隣許可に伴う不在時の措置(現3-9)
• 3-10 近隣許可に伴う不在者との対話(現3-10)
• 3-11 地下敷設時の簡素な表示方法の認定(現2-5-VI)
• 3-11-I 地下敷設時の簡素な占有表示の方法と効力(現2-5-VI-aとb)
• 3-12 地下敷設時の簡素な占有表示の期間(現2-5-VI-d)
• 3-13 帯内の地下敷設時の簡素な占有表示の省略と地上の占有(現2-5-VI-cと現3-5本文)
• 3-14 供用開始前の土地の確保(現3-1追記)

　結果として、ユーザーが一般的な占有ルールを把握するためには第2条だけを見ればよくなり、公共交通路の敷設者だけが、加えて第3条を見ることになる、また第3条は定義→関係者調整→占有表示→その他という敷設の順番に沿った内容となります。

　なお、条文整理のため、論理展開を行い、以下のような調整を行います。

　現行の「公共交通路に該当しない歩道」という表現では、公共交通路に該当する歩道があるように解釈できます。仮にこれが高速歩道のことであれば、既に高速歩道という名前で分離できているため、ここでの表現は単に歩道と言い換えることができます。

　その際、歩道を「公共交通路の構造（有用なものに限る。）を有しない道」と定義します。これにより、道の一部分にレールが敷かれているような道は、レール部分だけでなくその全体を公共交通路と見なせるようになり、ルールが明確になります。ただしデザイン的にレールをちりばめたような道が公共交通路と見なされるのを防ぐため、有用な構造に限ります。

　現行では「近隣の建造物の所有者の許可」となっていますが、建築予定で先に土地を確保しているようなユーザーに対しても配慮する必要があると考え、「占有者」とします。

　現行では「占有者及び近隣住人の許可」とありますが、占有なくして居住することは通常考えられない（借家は所有者が占有者に当たり、通常その許可を得れば借家の住人の許可を必要としないと考えられる）ことから、近隣住人を削除します。

　現行では3-10においてサーバー内において積極的に対話を行わない場合のBANの可能性を示唆していますが、BANの要件を個別の規則で定義することは疑問があると考えます。3-9において連絡を取ることに努める旨を規定することで、規則違反によるBANの可能性を提示することで代替させます。

　また3-10ではログイン時間が一致しない場合、「さらに一週間の猶予」をもって着工できると規定していますが、この一週間の起点が相手のログイン時間なのか相手のログインを確認した時間なのかあいまいであるため、不在者の最終ログイン日と定義します。

　現行では帯外での敷設時に限定されています。3-13で帯内での省略が認められているためだと思いますが、省略を認めるということは省略しなくてもよいということであるため、ここで帯外に限定する理由がなくなることから、広く地下への敷設時一般に対象を拡大します。

以上が、第２条の一部及び第３条を改正する提案です。

　上記各項目の他、規則を読みやすくするために、その趣旨を変えない範囲において改正を提案します。

　漢字表記とかな標記の混在や同一事象を示す複数の単語の混在について、理解を容易にするために、以下のとおり解消することを提案します。

• 「管理者」「サーバー管理者」　→　「サーバー管理者」に統一します。
• 「ユーザー」「サーバー利用者」「利用者」　→　「ユーザー」に統一します。
• 「建設」「建築」「建造」　→　「建築」「建築権」および「建造物」に統一します。
• 「設置」「敷設」「敷く」「通す」　→　交通に関しては「敷設（する）」に、それ以外は「設置（する）」に統一します。
• 「許可or許諾」「Minecraft orマイクラ」「ブロックor m（メートル）」「1ヶ月or1か月」「及びorおよび」「ときor時」「ことor事」　→　前者に統一します。
• 「／」　→　文脈に従い「及び」「あるいは」「または」に変換します。
• 「場合には」「場合には、」「場合は」「場合は、」　→　「場合は、」に統一します。ただし後ろが「この限りではない。」と短い場合は読点を省略します。

　一般的な法令の表現に見られないような叙述の仕方をしている点について、以下のとおり整理することを提案します。

• 「(2013/9/20追記)」といった表記　→　初版制定より前の日付であることから、２版制定に際してこれらを整理し、本文をなじませます。
• 「こと。」「禁止。」といった体言止め　→　条及び項においては、体言止めを用言で終わる形に書き換えます。
• 「公示され」「実施される」　→　特にサーバー管理者の行動について、ユーザー側から見た行動という視点が条文に反映されていますが、これを第三者視点に改めます。
• 「（以下○○と称する）」　→　「（以下「○○」という）」に改めます。
• 「～とは、～を指す。」　→　「～とは、～をいう。」に改めます。

　例えば、規則を先頭から読み進めたとき、2-1でいきなり「公共交通路」という日常生活であまり使用しない単語が現れ、その定義は3-1まで待たなければならない、といった点は、規則の読解時に混乱を招き、とっつきにくくさせる要因であると感じます。

　こういった事例について、単語の初出時に定義を行うこととします。ただし、条文構成を大きく変える必要が生じる場合については、単語の初出時に定義されている条文を明記するにとどめます。

　例えば、「大路」という言葉は6-1で定義されていますが、その後「大路」という単語は一度も使われていません。一方で、「MinecraftIDが記載された看板」という少し長めの単語は4回出現します。これに「ID看板」などの適切な略語を充てることで、文章の見通しが良くなります。 　そこで、複数回出現する長めの単語や複雑に修飾された単語について、適切な略語もしくは用語を充てます。

　改正による影響がない、または微小なもので、主なものをここに掲げます。ただし改正後の数値の設定等については、議論の余地があるものと承知しています。

→　禁止事項だけを定めているわけではないため、「建築に関しサーバー参加者（以下「ユーザー」という。）が順守すべき事項」に改めます。

→　明らかにいちゃもん対策ですが、表面は土とは限らないので「表層」に改めます。

→　占有地における水源についての条文ですが、占有地内で行き止まりとなる川などにまで制限を課す必要はないことを、「ただし、それらの水源が占有地を通過していない場合または隣接する水源により自由通行できる形状が確保される場合はこの限りではない。」と設定します。

→　ログで先占有者が判断できた場合の取り決めが、自明のこととして省略されているのだと思いますが、あいまいであるため、原則を当事者間の話し合いとし、話し合いの材料としてログの提示を求めることを認める（にとどめる）文章に改めます。

→　Farの設定自体1.8あたりで既に変更されているため、1.15.2のデフォルト値を採用して領域のサイズ自体を「最大で幅12チャンク長さ12チャンクの範囲内に収めなければならない。」に改めます。

→　条文の構成を考え、復元申し立てで1項、サーバー管理者は完全に復元させる義務を負わない旨(4-5の内容も含む)で1項に整理し、順序を調整します。

→　仕様を述べる部分と権限に関する部分を切り分け、権限については別項に整理します。

　以上の提案の他、さまざまな趣旨に基づくいくつかの改正の提案を行いたいと思います。

　これらの提案は、議論の余地が大きいと思われることから、より慎重に提案したいという意味合いを持つものです。

→　ケースによる後付け改定の場合の猶予を定めたものと認識していますが、改定内容が（きっかけとなったケース以外の）第三者にもあてはまる可能性を考慮し、「（サーバー管理者）の見解により本規則の改定が必要となる場合は、サーバー管理者は、ただちにその旨をユーザーに開示するものとする。」として情報の共有を求めます。

→　町の管理者という概念をどう定義するかは土地利用規則としては守備範囲外ではないかと思いますので、この文以降は削除が妥当かと思います。

→　解決策については、前項以上に範囲外だと思います。一方、他の条文でも「ユーザー間の話し合い」や「サーバー管理者の調停」を定めた個所があります。
　まずは話し合い、その後調停というのは土地利用に限らずごく一般的なルール（とマニュアルの中間）だと思われますので、それらについても、削除しても差し支えないか、あるいはここで原則を統一して明文化するのも一手段であると考えます。

→　町の管理者については2-5-Vの考え方のとおりですが、本項に限って言えば、マインハッタンを想定すれば理解でき、許容範囲とも考えられます。
　ユーザーが開拓した町というものについては、「（占有地の）再占有」というキーワードで概念化できるのではないかとも思いますが、規模が大きすぎるので今回の提案では断念します。

→　地上の構造物の列挙ですが、バージョンアップへの対応が必要なこと、また難破船や海底遺跡や（メサの）廃坑など地上にも地下（水中）にも出現するものの扱いが極めて微妙なものになることから、単に「村その他の構造物」と改めます。
　ただし、モンスターハウスなどのチェストの中身に対する考え方次第では、書き方を調整する必要があるところです。

→　構造物の利用は「第一到達者」の自由に委ねられていますが、スルーすることも自由であります。その場合、第二到達者が、自分が第一であると考える状況は十分想定されます。
　「第一到達者」を強調することが、ややこしさを生む一因となると考え、「第2条に定める方法により占有されている場合を除き、ユーザーが自由に利用してよいものとする。」というシンプルな形に改めます。これでも十分「第一到達者の自由」は守られるでしょう。

→現状に即して、廃止を提案します。

以上4段にわたって、理由を付して改正の発議を行いたいと思います。よろしくお願いいたします。