コンテンツの骨格

概要

本ドキュメントは、1周回に何がどれだけ要るかの骨格を決めます。系統が何本か・各系統が何段か・終盤に 何が要るか・アーティファクトが何種類か、そして航海の決着（GameEndings.md 12節）で増えた海区と遠征先の小島で何が採れるかです。

個々のレシピは決めません。 工程の分割・所要時間・材料の個数は幅出しの仕事です。各系統の中身は既存の カタログ（SurvivalItems.md・Containers.md・ Dwellings.md・Bedding.md・Animals.md・ Voyage.md）が持ち、本書はそれらを「何本・何段」として数え直し、足りない箇所を指すだけ です。スキルの粒度は Skills.md、航海の遊び方は GameEndings.md 12節が持ちます。

新設した文法はゼロです。「系統」も「段」もエンジンには写しません。 型の側に段を表すプロパティは 持たせず、段はレシピの要求（スキルと材料の連言、Skills.md 3節）が結果として作ります。 本書が持つのは数え方だけで、その数え方は区間によって変わります（2節）。

在処は、数え直しの材料として使った stats/balance.yaml（npm run stats:balance の生成物）・stats/climate.yaml・ stats/terrain.yamlと、src/assets/world-codex/terrain_generation.yaml の island.site_count です。読み方は docs/diagnostics/ の各文書が持ちます。 本書の節のうち、定義へ写るものはほぼ写り終わっています——8.1.1.1節・8.1.2節・8.1.3節の明るさと 8.1.5節の風雨は core.yaml の hour・weather と locations.yaml の各土地へ写っており、写した側が この4節を出どころとして名乗ります。 5.1節の海図は山頂の explore が担っています。 まだ写っていないところがあります——6節は24種類のうち golden_chalice だけ（artifacts.yaml）です。 2.3.2節の歩数による開始地点の選抜は src/domain/generation/StartSiteSelection.ts が担っています。

生成物から書き写しているのは、その数を知らないと結論が読めない数値だけです （DocumentStyle.md 7節）。判断の根拠でしかない数値は書かず、stats/ のどの節か だけを指します。書き写した数値には出どころのキーを名乗る印（HTMLコメント）が付いていて、 tests/docs/docStatsCitations.test.ts が印の指す先と 突き合わせます。印が付くのは書き写した数値だけで、複数のセルから導いた数値は対象外です。

確定しているのは、見出しに 【確定】 が付いた節だけで、他の節は暫定です。 とりわけ8節の日数は、 仮置き（屋外の割合・土地の配分）に支配されているので、桁の話として読んでください。

1. 系統は「繰り返し払う支出」で割る

系統とは、プレイヤーが繰り返し払っている1つの支出と、それを安くしていく手段の連なりです。支出を 数えれば、系統が数えられます。

割り方の候補は次のとおりです。

• 材料の出どころで割る（石・木・繊維・獣・土・鉱）。採りません。プレイヤーが欲しいもの——住居・ 容器・船——はどれも材料をまたぐので、1本の系統が完結しません。幅出しを並列に流すときも、石の系統と 木の系統が同じ住居の定義を取り合います。
• 道具の用途で割る（切る・叩く・掘る・突く）。採りません。「切る道具」と「叩く道具」を分けても、 どちらも石を打ち欠く同じ労働なので、品数は増えても支出は減りません。用途は系統ではなく、1つの段の 中の幅です。
• 支出で割る。 採ります。埋めるものが違えば手段が転移しないので、系統どうしが干渉しません。

支出で割ると、系統の本数は「プレイヤーが何に繰り返し払っているか」の本数に一致し、こちらの都合で 増減できなくなります。これが本数を数える根拠になります。

2. 段の物差しは、区間で変わる

足止めしているものが区間で違うので、段の切り方も変えます。開始直後は不確実性が、それ以降は労働の量が 足止めします。

平均値の表は開始直後には当てはまりません。 stats/balance.yaml の chain_routes の分数は、どの経路も選べて pick の期待値どおりに引ける前提の数字です。開始直後のプレイヤーはどちらの 前提も満たしていないので、表の分数はその区間の重さを表しません （DesignPrinciples.md の 「何が足止めしているかは区間で変わるので、段の物差しも変える」節）。

1日未満で越えられる前提は、段ではなく幅です（同「段は、実際に足止めしたものだけを数える」節）。 単体で1段ぶんに届く型はごく限られます（2.4節）——stats/balance.yaml の object_costs で days が1以上になるものがそれで、山として数えたものの日数は4節の表が持ちます。

この物差しは道具が判定します。 npm run stats:balance の総コストがそのまま「段かどうか」を決めるので、 幅出しで物が増えたときに数え直しが要りません。

2.1 最初の段は、アクセスの確保と数日分の備え

開始直後の段が終わるのは、主要な資源へ手が届き、数日死なない量の水と食料を確保した時点です。

• アクセスの確保 — 石・繊維・木・水源・食料が採れる土地への道が見つかっていること。開始地点は砂浜、 砂浜の無い島では他の海岸です（選抜の候補。2.3節）。砂浜には石も小枝も枯れ草もありません。 最初の仕事は、隣に何があるかを知ることです。
• 数日分の備え — 最悪を想定しなくてよくなる量。

これらが揃った時点で、プレイヤーは初めて「明日どうするか」を選べます。それまでは選択肢が 「今日死なないこと」に固定されているので、労働の量で段を切っても何も表しません。

2.2 切るものと火は、目的にせず最初の段の中で配る

刃物と火は仕組みの上では本物の前提ですが、プレイヤーが追う目的としては置きません。

前提としては外せません——水の経路の大半は刃物を要求し（cutting_tool、あるいはその一部で柄に固定 されていない刃だけを指す handheld_blade。stats/balance.yaml の chain_routes の property: hydration。刃物を通らないのは、粘土と炉だけで甕を焼く道です）、タロイモもヤシガニも火が要ります（Animals.md 1節）。外すと組み立てが 崩れます。

目的にしない理由は、目的にした瞬間、まだ何も知らないプレイヤーへ「石を探せ」という指示を出すことに なるからです（DesignPrinciples.md の 「仕組みの前提を、プレイヤーの目的にしない」節）。目的は生きる手段の確保に置き、刃物と火はその途中で 自然に手に入る道具として配ります。

2.3 開始地点は、最初の段を越えやすい地点から選ぶ

生成された島を測って、漂着できる地点のうち最初の段を越えやすいものから始めます。しきい値で候補を 落とすことはしません（2.3.1節）。生存が成立することを、 生成の保証（guarantees）では作りません（DesignPrinciples.md の 「生成への保証は島の顔を作る道具で、生存を成立させる道具ではない」節）。

保証そのものは使えます——山がある島・湖がある島といったその島が何であるかを決めるのは保証の仕事 です。生存の側でだけ第一選択にしない、という切り分けです。

測るのは、開始地点から道をたどって、生きるのに要るものが何歩以内に揃うかです。今の分布は次のとおりで、 1つの土地で全部は揃いません。

砂浜から始めると、この表がそのまま最初の数日の道順になります。 砂浜で手が届くのは太い枝とヤシの実と ヤシガニで、ヤシの実は割るのに刃が要り、ヤシガニは焼かないと食べられません （Animals.md 1節）。打ち上げられた流木の幹も転がっていますが、丸太にするには斧が要ります。プレイヤーは「石と火が要る」ことを、指示ではなく手元の物から 知ります（2.2節）。そして砂浜は海岸帯なので岩礁海岸・断崖海岸と隣り合いやすく、そこに石と、 打ち上げられた海藻があります。海藻はそのまま食べられるので、火が点くまでの食い繋ぎになります。

開始地点が説明を兼ねます。 何を採ればよいかを教える文章は要らず、持っている物が次にすることを 決めます。

選抜は生成の後段が持ちます（src/domain/generation/StartSiteSelection.ts。実体化のときに IslandSpawner.placePlayer がそれを呼びます）。歩数は生成が出したパスネットワークからしか出ないので、 島が出来上がる前には測れません。候補は砂浜で、砂浜の無い島では外周リング（海岸）——主人公は海から 流れ着くので（GameConcept.md 概要）、内陸から始まることはありません。 その中を並び順ではなく歩数で並べ、届かない要るものが少ない順、次に全部が揃うまでの歩数、次に その移動時間で採ります。ここまで並べても同じなら、最後はサイトのindexで決めます——順序を決めきる ための鍵で、良し悪しの判定ではありません。

候補を海岸全体まで広げていません。 広げるとどの島もほぼ2歩以内に収まり、2.3.2節の段が1つに 潰れます。砂浜に留めれば、島の引きがそのまま難易度の散らばりになります。砂浜の無い島でだけ海岸へ 落ちます（そこから始まる島の割合は stats/startup_reach.yaml の island_start_site_locations）。落ちても段は潰れていません——分布は island_start_site_hops_histogram にあり、2.3.2節の線はどれも空になっていません。

2.3.1 引きの厳しい島でも、引き直さない

どの候補も2.3.2節の初心者の線に届かない島でも、その中で最も越えやすい地点から始めます。島は 引き直しません （DesignPrinciples.md の「引きが厳しい周回は、そのまま始めさせる」節）。

その周回は腕にかかわらず苦しく、死ぬこともあります。周回のロストは新しい島を始めることなので （GameEndings.md 8節）、外れの引きはそこで清算されます。

2.3.2 難易度は、揃うまでの歩数で作る【確定】

難易度は消費や獣の強さではなく、最初の段に要るもの（2.3節の表）が開始地点から何歩先にあるかで 切ります——2歩以内・3歩・4歩以上（DesignPrinciples.md の 「難易度は、数値ではなく配置の散らばりで作る」節）。

出どころ: #656（難易度の線）と、同（難易度の3段目を「熟練者」に改める）

2.3.3 運の幅は、生成の側で締める

引き直さないぶん、島ごとの立ち上がりやすさの散らばりは生成の側で抑えます。散らばりが大きすぎれば、 選抜をしても引きで決まるだけになります（DesignPrinciples.md の 「運の幅は、例外の救済ではなく分布への制約で抑える」節）。

制約の中身は実測を見てから決めます。 どの配り方が幅を広げているかは、多数の種で回した分布を 見ないと分かりません。今わかっている範囲での候補は次のとおりです。

• カバレッジを型ではなく「採れるもの」で置く。 今の guarantees は「標高が最大のサイトへ山頂を 置く」という形で型を名指ししています。生存のためのカバレッジは、代わりに上の表のそれぞれについて 「島のどこかで採れる」を条件にします。どの型がそれを担うかは島ごとに変わり——火口を草原が持つ島も、 荒野が持つ島もありえます——型を名指ししないぶん、島の個性は削れません。山を必ず1つ置く既存の保証は そのままです（あれは島の顔を決めるもので、2.3節の切り分けの向こう側にあります）。
• 開始地点になりうるサイトの行き止まりを減らす。 今の配り方（terrain_generation.yaml の extra_edge_detour_factor）では行き止まりの土地が残ります（次数の分布は stats/terrain.yaml の site_degree_histogram）。行き止まりの砂浜から 始まると、次の一手が1つしかありません。

どちらも「必ずこの型をここへ置く」ではなく、満たすべき性質を配り方の条件に足す形なので、 2.3節の選抜と同じ考え方に乗ります。

2.3.4 歩数の数え方と、今の島が落ちている段

2.3.2節から導いたもので、覆すのに人間の判断は要りません。

歩数は道の本数で、0歩はその土地自身で採れることです。最も遠い1つが決めます——ほかが 足元にあっても、残る1つが3歩なら3歩です（StartupReachStats.md 計測方法節）。

選抜（2.3節）を通した今の島は、大半が初心者で、次に多いのが経験者、熟練者はごくわずかです （stats/startup_reach.yaml の island_start_site_hops_histogram。2歩以内・3歩・4歩以上をそれぞれ足したもの）。選抜を通さずに 砂浜から始めた場合の平均歩数は同 site_all_needs_hops_by_start_location の砂浜の行にあり、選抜は そこから island_start_site のぶんだけ近づけています。

歩数は道具が測ります（npm run stats:startup。定義と生成された島だけから計算できます）。

2.4 それ以降の段は、物ではなく量で立つ

1つの物で1日を超えるものはほとんどありません。段になるのは「まとまった量」です。

石の斧も甕もロープも、1つでは1日に届きません（stats/balance.yaml の object_costs）。段として立つのは「家1軒ぶんの丸太20本」「水を貯める甕10個」のような量のほうです。 4節はこの単位で並べます。

行き先が絡む段は、そこにしかない材料と対で書きます （DesignPrinciples.md の「行き先は、行きたくなる理由と同時に作る」節）。

3. 繰り返し払う支出を系統に分ける

支出を数えると、次の系統になります。

家具・娯楽が系統なのは、里心が繰り返し払う支出だからです。 溜まるのは日数そのもので （Characters.md ホームシック節）、払いは毎日続き、設えを据えるほど安くなります ——1節の割り方にそのまま乗ります。埋める支出はほかのどれとも別物です——寒さと雨は熱が受け持って いるので、火を焚いても里心は1点も減りません。

手段の側は、ほかの系統とも重なります。 雨風のために建てた家は居心地を押し （Dwellings.md 2.1節）、家畜のための囲いは連れとして押します（系統2、 farming.yaml）。どちらも別の目的で作る物なので、単体で止められるのは60日目からの募りまでに 抑えてあります（同節）——その先は、2つを重ねるか、snug まで積むかです。

この系統の物は、据えること以外に何の役にも立ちません。 生きるのに要る物が居心地を兼ねると、 対策がどうせ作る物になって圧が素通りするためです（同節）——だから snug へ届くには、この系統の物を 積むことになります。

手当て（怪我・病気）は系統に数えていません。支出ではありますが、繰り返し払うのは失敗したときだけで、 安くしていく段の連なりを持ちません（InjurySystem.md の治療は、段ではなく 症状ごとの対処です）。移動の距離も同じ物差しで落ちます（3.1節）。

移動の重さそのものは下げません。 今の島は端から端まで日帰りで届き、往復は屋外の枠を使い切って いません（8.3.1節）。畳む手段を持たない支出はただの待ち時間になりますが （DesignPrinciples.md の「コストは、それを軽くする道具の値打ちその もの」節）、枠が余っているうちは待たされていません。縮尺（terrain_generation.yaml の diameter_meters）を下げても浮くものがないので、今のままにします。

さらに系統が増えるとすれば、浅い洞窟の奥です。 潜るには昼でも光源が要るので （IlluminationSystem.md 7節）、明かりと燃料を安くしていく段が 連なります。奥そのものがまだ無いので、上の表には入れていません（【いつか: 洞窟内部】、 Someday.md）。

3.1 移動の距離は系統に数えない【確定】

移動の距離は繰り返し払う支出ですが、系統には数えません。 安くしていく段が、泊まりの行程も遠い 場所へ置く前線も入れないと決めた時点で無くなったためです（8.3.1節）。

出どころ: #1161（遠出は系統から落とす）

3.2 落としたあとに移動へ残るもの

3.1節から導いたもので、覆すのに人間の判断は要りません。

残るのはそりと、拠点をどこに置くかの判断で、どちらも移動の中の段ではありません——そりは運ぶ 入れ物の段であり、拠点の位置は段ではなく1度きりの選択です。

4. 各系統の段

最初の段（2.1節）に入るものと、そのあとに来る「1日以上の山」を分けて並べます。山は合計28個、 日数にして71.27日ぶんです。

この表の一覧そのものが、1周回の日数の出どころです。 山を何と数えるかは src/analysis/dailyPhases.ts の WORK_PILES が宣言し、そこから下の数は全部 stats/terrain.yaml が出します （読み方は TerrainStats.md）。日数は自由時間 （1日891分）に対する概算で、実測と書いたものは量を その型の値段そのもので採っています。

この71.27日は、明るさと移動時間を無視した下限です——どちらも入れると同じ山が 101.4日ぶんに広がり、島を開く16.0日を足すと 1周回は約117日になります（8節）。

山が「量」で立っていることに注意してください（2.4節）。石の斧も甕も1つでは段になりません ——段になるのは家1軒ぶんの丸太であり、貯水に足りる数の甕です。畑も塩田も1枚では1日に届きません （stats/balance.yaml の object_costs）——段になるのは拓いた枚数・据えた 枚数と、撒いて収穫しに戻る往復・海水を汲みに戻る往復の回数のほうです。囲いは1つで段に届きます ——丸太と縄が要るためです。干し場も1基で段に届きます——縄が1本要るためで、開けるのは 腐敗の最も速い段の食べ物（生肉・獣の死体・ヤシガニ・海藻）を干物にできることです （SurvivalItems.md 10節）。薪棚も1基で届きます——こちらも縄が1本要るためです。

12の量は、里心が止まる snug へ届かせる、いちばん安い積み方で測っています。 何をいくつ並べるかは 自由で、要るのは合計の手間のほうなので（Characters.md ホームシック節）、足止め しているのはその線までの手間です（2節）。ひと通りそろえる量で測ると、設えの型が1つ増えるたびに 1周回の日数が伸びます——プレイヤーが払う手間は線までで変わらないのに。積み方は stats/terrain.yaml の work_piles に出ます。

表の中身は、ほとんどが既存のカタログのままです。 9は Bedding.md 2節、10は Dwellings.md 3節、7は Containers.md 2節、4・5・6は SurvivalItems.md 1〜3節、11は Voyage.md 1〜3節に既にあります。 新しく足したのは1・2・3と、5の山で、このうち2の飼育は Animals.md 3.1節、3の製塩と 塩蔵は SurvivalItems.md 9節、3の干し場は同10節、3の燻し小屋は同11節、5の薪棚は FireSystem.md 2.5節が持ちます。残りはまだどの文書も担当していません。12のカタログは文書を持たず、src/assets/world-codex/furnishings.yaml が中身 そのものです——設えは点数と手間の対応が全部で、文書へ書き写すと定義と二重に持つことになります。

新しく足した系統の多くは、仕掛けて待つ形です。 水を溜める・畑と家畜・保存の設備（干す・燻す・天日で 塩を採る）はいずれも、留守の間に設備が働きます。罠が既にこの形なので （TrapSystem.md）、新しい仕組みは要りません。畑と家畜、塩田、干し場、 燻し小屋、そして薪棚がこの形で入っています——farming.yaml の field・pen、salt.yaml の salt_pan、 drying.yaml の drying_rack、smoking.yaml の smokehouse、firewood.yaml の firewood_rack は罠と 同じ宣言だけで書けていて、新しい文法は1つも足していません（飼育の中身は Animals.md 3.1節、 製塩と塩蔵は SurvivalItems.md 9節、干し場は同10節、燻し小屋は同11節、薪棚は FireSystem.md 2.5節）。まだ宣言が無いのは、水を溜める設備です。

仕掛ける手を持たないものも、同じ形に乗ります。 ベリーの茂み（locations.yaml の berry_bush）は 拓く手間も仕掛ける代償も持たず、周期タイマーだけを罠と同じ宣言で持ちます——払うのは通う手間と、 実りの周期そのものです。上の設備と並べていないのは、積む手間が1つも無いためです（1節）——据える ものではなく見つけるものなので、系統2の支出を安くする山が上の表に立ちません。株の数は探索で増えます が、それは島を開くぶんの手間（8.3節）で、食の調達へ払った手間ではありません。

磨いた石器（系統4）と恒久窯（系統5）は、山に数えません。 どちらも開けるものを持たないためです ——最初の段の石の斧で丸太も板も出ているので、磨いて初めてできることが1つも無く （SurvivalItems.md 1節）、素焼きに要る温度は使い捨ての覆い焼きで届きます （同4節）。山はその系統の支出を安くする手段です（1節）——安くするものが無ければ、労働の量が いくらあっても段にはなりません。

火（5番）の山は、薪棚です（4.1節・src/assets/world-codex/firewood.yaml）。炉の段 （FireSystem.md 6節）はいずれも石を数個積むだけで1日に届かないので、 段ではなく幅です（2節）——段として立つのは薪のほうで、開けるのは「伐った木から、取り出せる上限まで 熱を取れること」です。伐ったばかりの丸太は目方あたり太い枝の半分しか熱を出さず、1本の200は火を焚く 炉の薪の上限を超えるので、くべると入りきらない分が失われます。棚が買うのは、割っただけの薪の先——同じ手間のまま 燃料が20から30へ上がるぶんです——拾った枝より安くなる線は割った時点で跨いでいて、そこから先を落とすのが棚のほう （FireSystem.md 2.5節）。同じ形だった移動の距離は系統から落としましたが （3.1節）、火は落としませんでした（4.1節）。

【いつか: 泊まりがけ】 補給を持ち込んで泊まる行程は、島の広さが変わるまで入れません （Someday.md）。

【いつか: 穀物】 年単位で保つ食材は、今ある保存がどれも20日で頭打ちのまま回るので後から足します （Someday.md）。

4.1 火にも、1日以上の山を1つ置く【確定】

火の系統にも、1日以上かかる山を1つ作ります。 熱という支出を安くする段を1つ持たせて、他の系統と 同じ重さにします。その山は薪棚です——丸太を割って積み、乾かすと燃料1点あたりの手間が落ちます （4節・FireSystem.md 2.5節）。

火を系統から落とす道は採りません。移動の距離を落としたのと揃いはしますが（3.1節）、火は炉の段という 手段そのものを持っていて、1日に届かないだけだからです。

出どころ: #2055（火に1日以上の山を1つ作る。2026-09-12に回答）

5. 終盤に要るもの

出航までにプレイヤーが到達している必要があるのは、次のとおりです。

1. 積める船。 筏に帆と櫂が付いたもの（Voyage.md 2.1節）。丸太・ロープ・帆材が要り、 丸太は斧だけが作ります（同1節）。
2. 水を4〜6日ぶん運ぶ手段（遠回りと荒天を見込んで、余裕を取るなら10日ぶん）。1日は2.4L （飲用250mLがhydration 10 tick、1日の必要は96 tick）なので、10日で24Lです。海の上で水が増える道は 雨水しかありません（GameEndings.md 3.1節）。これは水の系統の段に 届いていなくても運べる量です——ヤシの実は1日5個の勘定で、10日ぶんを積んでも、積荷が横断を長くする 段にも筏の積荷枠のかさ（Voyage.md 3.2節）にも届きません （tests/world-codex/voyageYaml.test.ts が、実際に積んで横断時間を比べます）。甕（水の段3）なら24Lを31kgで運べます。どちらでも運べるようにします（5.3節）。
3. 航海ぶんの塩漬けと、突き銛の予備。 積むのは4〜6日ぶんで、伸びたぶんは海の上で釣って賄います （Voyage.md 3.9節）。生肉は2.5日で腐るので塩漬けは要り、腐らせない側は保存の段4 （製塩・塩蔵）に届いていれば足ります——塩蔵の20日が航海の日数を大きく上回るので、量は問われません。 積荷は体調も問います——塩漬けにしても生肉の運ぶ菌は消えないので、ビタミンを欠いたまま出ると 航海中に発熱の段へ乗ります（同3.9.3節）。銛は突いた魚に持って行かれるので、穂先になる尖った石と 紐も積みます（同3.9.4節）。
4. 浜まで運ぶ手段。 そり（運ぶ入れ物の段3）。備蓄は拠点にあり、出航地点は海岸なので、積み込みの前に 陸の運搬が要ります。積む量が4〜6日ぶんへ縮んでも要ります——甕で運ぶ水は下限でも3〜4つ＝16〜21kg （Voyage.md 3.9.6節。蓋をしなければ蒸発が、積む物を誤れば食べ方が押し上げます）で、 そこへ塩漬けの生肉12〜18個（Voyage.md 3.9.3節）と、脂を切らさないためのヤシの果肉2〜3個（同3.9.6節）が 乗るので、通れなくなる線（too_heavy。Characters.md 荷重の効き方節）に照らすと、 長い側では、水と食料だけで誰も通れません。 短い側は水と食料だけなら通れますが、 いちばん非力な者はアーティファクト1つで線を越えます。持ち帰る物が、そのまま 運べなくなる理由です。この数が数えているのは水と食料だけで、蓋も銛の予備も海図も乗っていません ——蓋をしなければ、甕の数のほうがここから増えます。
5. 残りの海区数が読める海図（GameEndings.md 12.6節）。山頂からの視認と 沿岸航海で作ります。

出航に適した季節の窓（同3.1節）が、これらに期限を与える——はずでしたが、今の重みでは期限として 働いていません（Voyage.md 3.1節）。横断時間も荒天の押し流しも数えたうえで、乾季と 雨季の差は待ち時間より桁違いに小さいままです。

出航に要る素材は、どれも入口を2つ以上持ちます（DesignPrinciples.md の「要るものは、名指しの鍵ではなく、部分的に代替できる資源で作る」節）。2つ目はどれも海岸に置いて あります——島がどの土地を取りこぼしても海岸だけは必ず在る（terrain_generation.yaml の hull_coast） ので、これで「その土地の有無がそのまま当落になる」入口が無くなります。

斧と刃物の段は飛びません——繊維はどちらの入口も刃物を通り（掻き取るのも実の皮を剥ぐのも handheld_blade。柄付きの斧では代われません）、流木の幹も斧を要求し（Voyage.md 1節）、 獣を仕留めるには武器が要ります。 増やしたのは入口であって、段ではありません。

5.1 望遠鏡は置かない【確定】

望遠鏡は骨格に入れません。海図の段階（GameEndings.md 9.1節）で 「方角と、幅のある海区数が海図に入る」役割は、山頂への到達が担います。

レンズには研磨したガラスが要り、青銅を上限とする技術水準（SurvivalItems.md 7節）を超えます。ここだけ技術の段を跳ばすのは、終盤に新しい能力を要求しないという方針 （GameEndings.md 3節が言う「それまでの遊びの強度を上げる」）とも合いません。

出どころ: #656（望遠鏡は置かない）

5.2 山頂が望遠鏡と同じ重さになる根拠

5.1節から導いたもので、覆すのに人間の判断は要りません。

望遠鏡が要求する研磨ガラスは、青銅を上限とする技術水準から2000年ほど先にあります。 山頂は往復に1日を使う行程が要る場所なので、中盤の目標としての重さは望遠鏡と同じです。 得られるものも同じ——方角と、幅のある海区数が海図に入ります。島には必ず山がひとつあります （terrain_generation.yaml の guarantees）。

5.3 航海の水は、甕とヤシの実の両方で運べるようにする【確定】

航海へ積む水の運び方は1つに絞らず、甕とヤシの実の両方を置きます。 甕には蓋を作り、蒸発を止められる ようにします。蓋を作るかどうかが、そのまま積み方の選択になります——蓋まで作れば少ない重さで済み、 作らなければ何も作らずにヤシの実で積めて、そのぶん積荷の重さを水が食います（5節の4・ Voyage.md 3.9.6節）。

蓋は素焼きで、甕と同じ炉を通ります（pottery.yaml）。粘土1個を平たく伸ばして乾かし、覆い焼きの炉で 焼くだけで、成形そのものは壺より短く済みます。炉は増えません——甕と一緒に並べて一度に焼けるので、 払うのは粘土と成形の時間だけです。載せている間は蒸発も雨受けも止まり、外せば元どおりです （LiquidContainerSystem.md 6.2節）。

出どころ: #2055（航海の水は甕とヤシの実の両方を置く。2026-09-12に回答）

6. アーティファクト

材料を置けない場所に「行きたくなる理由」を与えるのがアーティファクトの役目です （DesignPrinciples.md の「行き先は、行きたくなる理由と同時に作る」節）。

6.1 全周回で24種類、1周回の島に6つ【確定】

全周回に共通する集合は24種類、1周回の島に配置されるのは6つとします。

周回中は何の役にも立ちません。重いだけです。 使い道があると、持ち帰るより使うほうが得になる場面が 出て、航海で積荷を捨てる決断（GameEndings.md 4節）が鈍ります。決断を 立たせるのは重さのほうで、水と食料との枠の奪い合いではありません。

出どころ: #656（アーティファクト24種類・1周6つ）

6.2 出どころ別の内訳と、そこから出る重さと周回数

6.1節から導いたもので、覆すのに人間の判断は要りません。

出どころは、材料の無い行き先です。 浅い洞窟・山頂・沈船の海区・遠征先の小島。

24種類は、1周で6つ持ち帰れたとして最短4周、重複を織り込んで6〜8周で埋まる勘定です。

重さで引き換えになるのは、航海ぶんの水と食料との速さです——ヤシの実で10日ぶんを積んでも、それだけでは 横断は延びません（5節）が、積荷がその段を越えると、帆を張っても 横断が伸びます（Voyage.md 3.2節）。6つ全部を持ち帰るかは、そこで速さと引き換えになります。

7. 海区の顔ぶれと、遠征先の小島

海区は顔ぶれ（7節）から十数個を配ります。 実りの差の付け方は地上の土地と同じつまみで、専用の仕組みは 足しません（GameEndings.md 12.1節、 ExplorationSystem.md 2節の「発見量のつまみ」）。

名前はいずれも見れば分かるものから採るので、名前を得るための探索は要りません （GameEndings.md 12.2節）。

この表の「実り」は、地上のつまみだけで表せています。 卓はsea_zoneが1つだけ持ち、海区は候補の 重みを配るだけで、顔ぶれを表す型もタグもありません（Voyage.md 3.3節）。測った値は stats/voyage.yamlのzone_yields・zone_findsにあります（読み方は VoyageStats.md）。足したのは「何も見つからない」候補1つだけで、 それは地上の探索が持たないもの——地上は1回で必ず1個以上返します （ExplorationSystem.md 2節）。

表せていないのは、実りと渡る時間を結びつけることです。 素の横断時間はどの海区も同じなので、 「実りの濃い海区ほど渡るのに時間がかかる」という形は取れません（Voyage.md 3.2節）。 濃淡が経路の選択へ効くのは下の分かれ道1箇所で、そこでも遠回りを選ぶ理由は時間ではなく実りです （同3.9.1節）。

「最短の航路はここを通る」は、分かれ道が判断にしています（Voyage.md 3節）。近道は 空の海（うねりの海）から流れ藻の海へ直に渡り、遠回りは沖の潮目（潮目）と黒い岩礁（岩礁）を経由して 2区間長くなります。近道が薄いのは、飛ばす2区間が返すものを持っているからです。

岩礁の「荒天で押し流されやすい」だけが見張りの卓の外です。 荒天にさらされてから風下の海区へ 押し流されるまでが、他の海区の半分です（Voyage.md 3.8節）。

7.1 遠征先の小島には錫を置く

青銅の材料のうち、銅は母島の山で採れ、錫は遠征先の小島にしかありません。

これで沿岸航海（GameEndings.md 11節）が「渡らないと道具の最終段に届かない」 場所になります。移動手段だけを先に入れて 後から理由を足すことにならず、SurvivalItems.md 0節が既に銅鉱石と錫鉱石を別々に 挙げているので、材料も増えません。

小島は上陸して探索できる土地なので、アーティファクトの配置先にもなります（6節）。

8. 埋まる時間

同じ28個の山が、明るさ・移動・土地の差を入れると101.4日ぶんになり、島を開く16.0日を足して 1周回は約117日です。1日891分という自由時間は上限であって、実際に使える時間ではありません。

1日を賄う最小労働は549分（stats/balance.yaml の daily_minimum）なので、差し引きの自由 時間は1日891分。4節の山の合計は約63500分なので、 そのまま割れば71.27日ぶんです。しかしこの891分は、 1日のどの時間でも何でもできる場合の数字で、明るさと移動がこれを削ります（8.1・8.2節）。

山の数を増やしても日数は伸びません。 日数は山の合計そのものなので、増やす道は「山を増やす」か 「1つの山の量を増やす」かのどちらかで、合計から見れば同じことです。増やすと決めた場合に選ぶのは、 どちらが同じ作業の反復になりにくいかだけです（DesignPrinciples.md の「失敗の罰に、同じ作業のやり直しを課さない」節が問題にしているのと同じ反復）。

最初の段は、この勘定には乗りません。 足止めしているのが労働の量ではないので（2節）、分で測っても その区間の重さは出ません。乗るのは日数だけで、数日です。

探索は分では軽く、日数では重いものです。 島の土地は10〜20（terrain_generation.yaml の site_count）、探索率100%までの回数は土地ごとに異なり、1回15分 （ExplorationSystem.md 2節）なので、全島を100%にしても2,803分 ——山の合計のごく一部です。ところが日数では16.0日になります。1日に探索できる時間が土地の 明るさで切られ、しかも1つの土地を開き切るまでそこに居る必要があるためで、この差が出るのが8.3節の 「探索の局面」です。なお最初の段の中では探索がほぼ全部で、そこでの探索は時間を埋めているのでは なく不確実性を減らしています。同じ行動が区間によって別の働きをするので、まとめて数えられません。

8.1 明るさが、1日に使える時間を切る

明るさは現実の単位（照度）で持ちます。行動ごとに要る明るさが違い、足りなければその行動はできません。

抽象的な0〜20では、その値が正しいかを誰も確かめられません（DesignPrinciples.md の「現実に単位があるものは、その単位で持つ」節）。ルクスなら、嵐の正午が約190 lx——手元の作業まで できる明るさで、真夜中とは比べものにならない——だと外の知識で確かめられます。

嵐で動けないのは風雨のせいであって、暗いせいではありません（同「1つの原因に、複数の結果を 兼ねさせない」節）。暗さとして表すと、松明を持てば嵐の中でも動けることになります。風雨が止めるのは 屋根の下でない場所での行動です（8.1.4節）が、止めているのは明るさとは別の値です。

線を引くのであって、遅くするのではありません（同「悪条件は、効率を下げるのではなく、できる／ できないの線で効かせる」節）。これで「暗くなる前に切り上げて帰る」「松明を持って出る」「明るいうちに しかできない仕事を先に回す」という、1日の組み立てが要るようになります。

8.1.1 持つのはEV（照度の2を底とする対数）

照度そのものではなく、EV（露出値、EV = log2(照度 / 2.5 lx)）で持ちます。 この世界の明るさは 0.00005 lx から125,000 lx まで9桁に渡るので、そのままでは加減算で扱えません。

EVは写真の「段（stop）」で、ISO 2720 が定める標準の量です（入射光式・ISO100・較正定数250）。1段が 2倍にあたり、掛け算がそのまま足し算になります——樹冠が通す割合も、天気の透過率も、地面の反射率も、 EVでは引き算・足し算の項になります。名前のある単位なので、値が正しいかを外の知識で照合できます （DesignPrinciples.md の「現実に単位があるものは、その単位で持つ」節）。

採らなかった候補は次のとおりです。dB（10·log10）は汎用ですが「照度のdB」という確立した用法がなく、 1段が1.26倍で細かすぎます。視等級は天文で使う本物の照度の対数ですが、明るいほど値が小さくなる ので加算の向きが常識と逆になります。

移動のしきい値が −5（0.1 lx）なのは、暗順応した人間が満月の砂浜を普通に歩けるからです。 満月が 中天にあるとき開けた土地は0.25 lx で、これを歩けないことにすると現実と合いません。この島に満月は 出ません（8.1.1.3節）が、しきい値のほうは現実の目盛りに合わせてあります。

屋外の採取は、手元の作業より2段低いところに線があります。 80 lx は倉庫や廊下の明るさで、縫製の 推奨（750〜1,500 lx）には遠く及びません——それでも手元の作業を通すのは、屋内の粗い作業の下限がその あたりだからです。屋外で草を採るのに要るのはそこまでではなく、現実の熱帯雨林の林床は快晴の正午で 600〜2,500 lx あります。開けた土地では日の出と日没が急峻なので、この2段の差はほとんど動きません （8.1.3節）。効くのは樹冠の深い森と密林だけで、そこでは採れる時間が手元の作業より大きく長くなります。

見る値も違い、手元の作業は据え付けの光源を含む明るさを、屋外の採取と移動は含まない明るさを見ます （IlluminationSystem.md 2節・5節）。

表の夜の3行は、空の側では底（−6）に均されます。 底があるのは、光源が持ち上げる段数を場所によらず 一定にするためで、−6 自体に現実の根拠はありません（同 4節）。土地の樹冠と反射は、その底の上へ 足されます——夜の地表がどうなるかは 8.1.2節です。

しきい値と底は、これが作る1日の形で確かめてあります。 土地×季節ごとに何時間動けるかは stats/climate.yaml の activity_hours が定義から解いていて、開けた 土地は昼の12時間、 密林の雨季に採れるのは1.3時間、 砂浜は夜も歩けて24時間に なります。この3つが揃っていることが、8.1節の狙い——暗くなる前に切り上げて帰る・明るいうちにしか できない仕事を先に回す・松明を持って出る——そのものなので、しきい値（−5・+3・+5）と底（−6）は 今の値のままです。底を1段動かせば、砂浜が夜に開くかどうかが裏返ります（8.1.2節）。

8.1.1.1 夜の空は、月あかりを項として持たない【確定】

夜のあいだ、空が地表へ与える明るさは底そのものです。 月の高度でも天気でも動かないので、 夜には項が1つもありません（底の値は 8.1.1.2節）。

この節が決めるのは空の側だけです。 土地の樹冠と反射はこの底の上へ足されるので（8.1.2節）、 夜に歩ける土地があるかどうかは、この節では決まりません。

出どころ: #656（夜の明るさは月あかりを持たない）

8.1.1.2 光源の明るさは、現実の照度ではなく「底から何段か」で決める

光源の値だけは現実から離します。

底（−6）と移動・手元の作業のしきい値（−5・+5）を決めると、光源の値は引き算で一意に出ます——1つで 歩けるようになる明るさが +1、1つで作業できる明るさが +11 です。獣脂のランプは1つで歩けますが、作業できる明るさに するには11個要ります。 これは障壁として十分で、しかも現実の照度でも一致します（10 lx × 11個 = 110 lx で、100 lx のしきい値を超える）。

離すのは光源だけで、しきい値も自然光も現実のままなので、「その値が正しいかを外の知識で照合 できる」（DesignPrinciples.md の「現実に単位があるものは、その 単位で持つ」節）性質は保たれます。光源は「暗闇を何段持ち上げる道具か」という、ゲーム側のつまみとして 読みます。

松明とキャンプファイヤーは同じ値です。 差を付けても「底では作業できないが少し明るければできる」 という読みにくい段になるだけなので、光源は「歩けるようになるもの（+1）」と「作業できるようになるもの （+11）」の2階層で足ります。両方を同時に使うと雲のまったく無い空の正午を超えますが、しきい値との比較にしか 使わないので害はありません。

段（stages）は、しきい値の境目にだけ置いてあります——pitch_dark（−5未満）・dim・brightで、 bright の境は手元が +5、視界が +3。これらがしきい値の置き場そのもので、条件の側は段の名前で見ます （IlluminationSystem.md 8節）。上の表の値を動かすときに 一緒に見るのは、キャラクタの hand_brightness・looking_brightness の段だけです。

「携行光源か固定光源か」という区別は、明るさの側には要りません。 焚き火が視界を明るくしないのは、 それが動かせない設置物だからで、光源自身は何も知りません（IlluminationSystem.md 3節）。

光源の値も今のままです。 +1 も +11 も底としきい値からの引き算なので（上）、確かめたのはその2つ （8.1.1節・8.1.2節）。+11 のほうは松明1本が何を開くかでも確かめてあり、1段下げれば手元の作業だけが 閉じます（8.1.1.4節）——2階層のうち上の段は、そこでしか置けません。

8.1.1.3 月あかりを落とせる理由は、半月の照度が底を下回ること

8.1.1.1節から導いたもので、覆すのに人間の判断は要りません。

月齢は入れず、半月と仮定します。 満月ではなく半月を採るのは、その状態でいる時間が長いほうを 選ぶためです（DesignPrinciples.md の「周期する状態を固定値で近似 するなら、頻度の高いほうを採る」節）——月が開けた土地を歩ける明るさにするのはひと月の2割弱で、残りの 8割はそこへ届きません。

半月の照度は満月の約1/10（中天で 0.025 lx＝−6.6）です。面積が半分だからではなく、欠け際の影が 長く伸び、満月のときだけ効く衝効果が無いためです。これは暗さの底（0.039 lx＝−6）を下回るので、 月の高度で刻んでも天気の透過率を掛けても、空の側は底のままです——区別できるものが何も残らないので、 項を持たせません。

【いつか: 月齢】 月齢で周期させる案は、画面に月齢を出す形が決まるまで待ちます （Someday.md）。

8.1.1.4 松明1本は2時間で、灯っているあいだは暗さが閉じたものが開く

灯っている松明を持っていれば、どの土地のどの時刻でも、行動のどのクラスも開きます。 底（−6）へ +11 が乗ると手元のしきい値（+5）にちょうど並ぶからで、いちばん深い樹冠の夜でも同じです（夜の地表は すべて底に均される、8.1.2節）。開かないのは嵐の日、屋根の下でない場所での行動で、それを止めて いるのは明るさではありません（8.1.4節）。そこではどのクラスも開きません——松明が買えるのは暗さで 閉じた分だけです。ただし雨の屋外では、松明はそもそも灯っていられません（小雨でも消える、 FireSystem.md 8.2節）。

燃えるのは2時間（fire.yaml の torch の life）。灯すには、燃えている炉から炎を分けてもらうか （FireSystem.md 3.1.2節）、火起こしから作った火種を移します。火種から 灯すと、燃える時間より長くかかります——火種1つが62.0分 なので、下の松明そのものと合わせて127.2分。炉から分けてもらう道があるのはこのためで、その道を 通るなら払うのは松明のぶんだけです。

素材込みの手間は65.2分 ——明かり1分あたり0.54分です。それでも作る価値があるのは、買えるのが時間の延長ではなく、 そうでなければ0の場面だからです。光源を持たない1日は、屋外の693分と 炉端の347分と睡眠の360分と、 嵐で止まる40分で既に埋まっているので、開けた土地では松明を足しても入る先がありません。

効くのは、夜の道と、樹冠の深い土地です。 拠点から平均的な土地への片道は91.61分 なので、日が暮れてから往復するなら2本——1本の2時間では帰り着けません。密林の雨季に採れるのは 1日1.3時間なので、 そこは1本ごとに採れる時間が増える土地になります。ただし松明が効くのは雨の合間だけです ——雨の屋外では松明が消える（上）ので、雨季の雨（季節1本あたり、小雨238.17時間・ 大雨222.39時間・ 嵐78.75時間、 季節の長さは29.91日）の間は灯しておけません。 消えている間は燃え残りが減らないので2時間そのものは失われませんが、止むたびに炎か火種から灯し直す 手間が掛かります。

8.1.2 土地は「樹冠」と「地面の反射」を持つ

土地が明るさへ与える影響は、どちらもその土地の環境光へ入ります。

• 樹冠の透過率 — 空から降る照度のうち、地表まで届く割合。熱帯雨林は1〜2%しか通しません。
• 地面の反射率 — 地面が返す割合。太陽光の下では照り返しが手元も照らすので、手元の作業にも 効かせます。

定義に書くのは合計の1つだけで、内訳を持つのはこの表です （IlluminationSystem.md 2節）。

浅い洞窟はこの表に載りません。 土地ではなく土地の中の設置物で、持っている −6 は樹冠と反射の合計では なく外との差だからです——親の土地の環境光を土台に6段下げます （Dwellings.md 5.1節）。空から光が来ないことを土台を持たないことで表す形 （IlluminationSystem.md 7節、値は底そのもの）は奥の洞窟の値で、 その奥はまだありません（【いつか: 洞窟内部】、Someday.md）。

反射率は基準の地面（0.20）に対する比として掛けます。

夜の地表は、これだけで決まります。 空は底（−6）に張り付いていて時刻でも天気でも動かないので （8.1.1.1節）、夜の明暗を作るのは土地だけです。

夜に歩けるのは砂浜だけです。 反射 +1 を持つ砂浜だけが底の上へ1段乗り、しきい値に届きます （tests/diagnostics/activityHoursAssumptions.test.ts）。 海沿いは夜でも帰れる道になり、他の土地から日暮れ後に動くには光源が要ります。

現実の半月の砂浜は 0.05 lx で、しきい値（0.1 lx）に半段届きません。 底が空の暗さを持ち上げるぶん、 この島の砂浜は現実より明るいことになります。それでも砂浜を開けておくのは狙いです——夜がどの土地も 一様に閉じると、地面の色は線を跨がせる場面を1つも持たなくなります。

砂浜は草原の2倍近く明るい。 乾いた砂の反射率は0.4ほどあり、開けているだけの土地より効きます。 効く量では樹冠のほうが圧倒的（100倍）ですが、反射率が線を跨がせるのは夜のほうです——昼は日の出と 日没が急峻なので（8.1.3節）、同じ1段では境目が数分動くだけです。

夜は、樹冠の差が消えます。 森も密林も浅い洞窟も底へ引き戻されるので、夜の暗さでは区別が付きません。

反射率も今の値のままです。 線を跨がせているのは砂浜の +1 だけで、それが上の表の「夜に歩けるのは 砂浜だけ」を作っています。他の土地の反射を動かしても、昼は境目が数分動くだけ（8.1.3節）なので、 反射率が効いているかはこの1段で見ます。

浅い洞窟の中で作業できるのは、外が曇りの正午（+11）以上に明るいときだけです。 中は外より段が −6 下がり、 手元のしきい値は +5 だからです。曇りの日は正午のあたりだけ、雨の日は 一日中できません（tests/diagnostics/activityHoursAssumptions.test.ts。季節ごとに何時間できるかは stats/climate.yaml の activity_hours の shallow_cave）。アーティファクトの出どころの3分の1が浅い洞窟（6節）で、そこは同時に序盤の住居 （Dwellings.md 5節）でもあるので、朝夕と雨の日に中で手を動かすぶんが燃料の需要に なります。奥の洞窟が開けば（【いつか: 洞窟内部】）、そちらは昼でも光源が要ります。

移動できるかは、出発する土地の明るさで決めます（IlluminationSystem.md 5節）。 道は自分の明るさを持たないので、行き先の暗さは見ません。

8.1.2.1 値は「環境光・手元・視界」に分ける

行動が見るのは手元と視界で、環境光はそれを導くためだけに在ります。

しきい値の対応は——手元の細かい作業は「手元の明るさ」、移動と屋外の採取は「視界の明るさ」を 見ます。

分ける理由があり、どちらか一方をやめても、もう一方が同じ分け方を要求します。

• 底は光源より前に効く必要があります。 底が無いと、密林の夜（−15）と浅い洞窟の夜（−12）とで同じ 松明の効き方が変わり、「1つで歩ける／11個で作業できる」という段が作れません。
• 据え付けの光源は視界に入ってはいけません。 焚き火が視界を明るくすると、真っ暗な夜でも拠点から 出発できてしまい、着いた先で身動きが取れなくなります。

どのオブジェクトがどれを持つかは IlluminationSystem.md 2節、 底の置き方は同 4節です。樹冠が光源を遮ってしまう問題は、底が飲み込みます——密林の夜は樹冠込みで −15 ですが底で −6 になり、そこへ松明の +11 が乗ります。

合成はすべて単純加算です。 対数なので光源を足し合わせるのは厳密には正しくありません（10 lx の ランプ2つは1段しか増えないところ、加算では2段になります）。それでもしきい値との比較にしか使わない ので、誤差が線を跨がなければ結果は変わりません。 乗算や「大きいほうを採る」をエンジンへ足すよりも、 定義ファイルが加算だけで書けることを優先します（同 1節）。

8.1.3 天気は、明るさへは樹冠を通してだけ効く

赤道付近の島（Animals.md 概要）なので、日の出6時・日没18時が年間ほぼ動きません。 太陽高度から出した、雲のまったく無い空の照度に、天気の透過率を掛けます。天気はcore.yamlのweatherの7段すべて です——「寄与」は同じ段がambient_brightnessへ与える段数で、雲のまったく無い空を0として何段暗いかです。 天気の行名は画面へ出る日本語名（locale/ja.yamlのsymbol_texts）です。

照度の単位はlxです。灼熱（scorching）は暑さの名前ですが、明るさの側では雲のまったく無い空——寄与を 持たない基準の段です。晴れ（clear）がこの島でいちばん多い天気で、快晴と曇りの間に落ちます。

照度と実装を突き合わせるのは正午の列です。 hourが正午に与える寄与が+16なので、実装の正午のEVは 「16＋寄与」になります。照度をEVへ直した値（EV = log2(照度 / 2.5 lx)、8.1.1節）とは最大0.4段ずれます ——実装は段を整数で持つための丸めで、正しいのは実装のほうです。正午以外の列は直接は一致しません ——実装のhourの段はその1時間の中央の太陽高度を使うのに対し、この表の列は正時の高度だからです。

夜の列はありません。 半月の月あかりは中天でも 0.025 lx（−6.6）で、天気の透過率を掛けるまでもなく 底（−6）を下回るためです（8.1.1.3節）。天気が明るさへ効くのは昼だけで、夜の砂浜が開くかどうかは 天気によりません。

透過率は正午の実測に合わせました（雲のまったく無い空10〜13万 lx・曇り5,000 lx・嵐200 lx）。晴れ （clear）だけは実測ではなく、実装の−2段（EV 14 ＝ 41,000 lx）から置いています。

土地×季節ごとに1日何時間動けるかは、手で計算せず定義から数えます。 activityHoursOfが、core.yamlのhour・weatherの段 （この節の透過率と太陽高度がambient_brightnessへ与える寄与そのもの）・土地ごとのambient_brightness （8.1.2節）・天気の出現時間（stats/climate.yamlのweather_hoursの実測） から、しきい値（8.1.1節の −5・+3・+5）を満たす時間を積算し、どの列からも嵐の時間を引きます （8.1.4節・8.1.5節）。据え付けの光源は含みません （含めると「焚き火があれば24時間活動できる」になり、表の意味が消えます）。 表そのものは同じYAMLのactivity_hoursに1本だけ持ち、ここでは繰り返しません。

列は行動のクラスと1対1です——travel（移動できる）・outdoor_search（屋外で見て探せる＝採取と 探索）・handwork（手元の細かい作業ができる）。採取と探索が1列なのは、見る値もしきい値も風雨の 扱いも1つに揃っているからで、分けても必ず同じ値になります （IlluminationSystem.md 5節も1行で書いています）。列の間で値が 違う理由はしきい値の差だけです。見る値は違います （採る側はlooking_brightness、作る側はhand_brightness）が、据え付けの光源を含めない限りどちらも土地の ambient_brightnessをそのまま土台にするためです（同 2節）。

嵐を引かないのは浅い洞窟だけです——岩陰に守られているので風雨が届きません（8.1.5節）。 建てた屋根は行になりませんので、handworkの列は「屋根を建てていない場合」を出しています。

夜に動けるのは砂浜だけです。 他の土地は夜になると移動のしきい値を割るので、日暮れ後に動くには 光源が要ります（8.1.2節）。風雨の届く場所で「移動できる」列が明るい時間ぶん丸ごと開かないのは雨季 です——嵐の時間が引かれるためで、砂浜なら夜も含む24時間から、他の土地なら昼の12時間から削れます。 明るさの側でも落ちるのは、樹冠の深い密林と、岩陰の浅い洞窟です——密林は樹冠が−9と深いぶん雨季の 荒天では正午でも移動のしきい値を割ることがあり、浅い洞窟は嵐を引かない代わりに岩陰の−6で落ちます。

土地の差がいちばん大きく出るのは、採れる時間の雨季です。 樹冠が深い森・密林ほど雨季に大きく 削られます（森・密林とも雨季は繊維・バナナ・粘土・小枝の産地——2.3節の表——なので、雨季は繊維が 細る季節になります）。保存の系統（3番）と備蓄が要る理由が、ここで数字になります。

夜は空白になりません。 睡眠が360分、残りの360分は焚き火のそばで手元の作業ができるので、夜は 「集める」から「加工する」へ切り替わります （DesignPrinciples.md の「時間経過に任せる区間を作らない」節）。 嵐の夜だけは、屋根の下でなければその360分も止まります（8.1.4節）。

8.1.4 嵐の日は、屋根の下でなければ何もできない【確定】

嵐の日、屋根の下でない場所では何もできません。 採るのも、歩くのも、探すのも、手元の作業も 止まります。明るさが足りていてもできず、松明でも埋まりません——止めているのは風雨で、それは明るさとは 別の値だからです（8.1節）。屋根の下へ入る以外にすることが無い日になります。

「何もできない」の線は、目や手元の精度が要る仕事です（顔ぶれは 8.1.5節）。暗くても止まらないもの ——食べる・飲む・眠る・火をくべる・留守番の設備が返した実りを受け取る——は、風雨でも止まりません。 雨受けのように、嵐だからこそ効くものもあります（LiquidContainerSystem.md 7節）。

止まる日は嵐だけです。 core.yamlのweatherの段のうち屋外を閉ざすのはいちばん荒れた1段で、 大雨（heavy_rain）の日は屋外で動けます。

海の上で渡ることだけは、この線の外です（理由と効き方は 8.1.5節）。

出どころ: #656（嵐の日は屋外の採取ができない）・ #2055（嵐は屋外の行動をすべて止め、大雨では動ける。2026-09-12に回答）

8.1.5 風雨は、風速（m/s）で持つ

8.1.4節が止めているものは、風速で表します。 明るさと同じく現実の単位なので、値が正しいかを外の 知識で照合できます（DesignPrinciples.md の「現実に単位があるものは、 その単位で持つ」節）。雨のほうは値に入れていません——屋外を閉ざすのは嵐だけで、大雨では動ける からです（8.1.4節）。

単位はm/sです。灼熱（scorching）は明るさと同じく寄与を持たない基準の段——雲も風も無いから 灼けます。値は階級の目安から置いたもので、明るさの透過率のような実測はありません。

屋外が閉ざされる境目は17.2 m/sで、台風の風速の定義（ビューフォート8の下限）そのものです。7段のうち これを超えるのは嵐だけで、境目を持つのはキャラクタの段（player_character.yamlのwind_speedの gale）1箇所だけです。行動の側の条件はその段の名前で見るので、しきい値の数字はどこにも書き写されません。

この段を見ている操作は、明るさの段を見ている操作とちょうど同じ顔ぶれです （IlluminationSystem.md 5節の一覧）。目や手元の精度が要る仕事は 暗さでも風雨でも止まり、手が覚えている粗い動作はどちらでも止まりません。重なっていることは tests/world-codex/stormOutdoors.test.tsが全数で見張ります——どちらか一方だけを書いた操作は、 そこで落ちます。どちらも書き忘れた操作は拾えません（その見分けは同 5節が持ちます）。

海の上で渡ることは、この線の外です。 8.1.4節が線を引けるのは屋根の下という逃げ場が在るからで、海区には それがありません——そのまま当てはめると、嵐の海区は待つ以外にすることの無い区間になります （DesignPrinciples.md の「時間経過に任せる区間を作らない」節）。 海の上の荒天は、渡りを止めるのではなく押し流す形で効きます（Voyage.md 3.8節）。 渡る手には明るさも風雨も要らず、海の上で嵐に閉じるのは見て探す仕事のほう（見張り・釣り・海鳥）で、 そちらは上の顔ぶれに入っています（同 3.10節）。

屋根は風雨を引きます。 守られている場所（sheltered、 ContainerSystem.md 6節）に居る間はこの値が0まで落ちるので、 行動の側は屋外かどうかを知らなくてよくなります。

8.2 1日は、局面ごとに数える

「1日」は1つではありません。 島を開いている最中と、開き切った後とでは、同じ島でも1日の使い方が 別物になります。道1本の片道の平均（stats/terrain.yaml の base_one_way）だけでは、どちらの1日も出ません。

dailyPhasesOfが、生成された島から局面ごとに数えます。道1本の 移動時間には縮尺・歩く速さ・両端の move_cost・高低差が生成の時点で畳まれている （TerrainGeneration.md 3.5節）ので、積むのは最短経路だけです。 表そのものはそちらに1本だけ持ち、ここでは繰り返しません。

数え方は局面をまたいで1つです。

その日その土地で進む仕事（分） = min(屋外の枠 − 往復の移動 − 生存の採取, その土地でその仕事ができる時間)

遠さは移動の項として、暗さは頭打ちとして、風雨は屋外の枠と頭打ちの両方として、同じ1行に入ります。 局面の違いはどこへ行くかと 何を消化するかだけで、式も頭打ちも共有します——どちらの局面もoutdoor_searchの列（8.1.3節）で 頭打ちにします。探索と採取で頭打ちが違うことはありません——明るさも風雨も同じ線で閉じるからです （8.1.4節）。693分は屋外の枠、189分は1日を賄う生存の採取 （stats/balance.yaml の daily_minimum の549分から睡眠360分を引いた分）です。

生存の採取は、暗い土地でも払える形にしています。 密林で1日に働ける時間は土地の組の中でいちばん 短い（stats/terrain.yaml の steady_phase_by_work_share）のですが、 その日の残りの明るい時間は拠点の周りにあります。頭打ちに掛ける前に引くことで、 「密林へ行った日は食べられない」 にならずに済みます。

移動は、8.1節の採れる時間からは引きません。 移動のしきい値は −5、屋外の採取は +3（8.1.1節）で、 その差の時間帯は歩けるが採れない時間です。1日の屋外の枠を決めるのは移動のしきい値のほう ——太陽が出ている12時間から、嵐で閉ざされる時間を引いたものです。

嵐は往復の移動も止める（8.1.4節）ので、風雨は頭打ちだけでなく屋外の枠にも入ります。引く割合は 屋外が嵐で閉ざされている時間の割合（stats/climate.yaml の weather_hours から openAirGaleShareOf が出す）で、拠点の値でも行き先の値でも なく島全体の値を使います——往復は屋外を歩き、島の土地はどれも屋根に守られていないので、どの土地で 1日を使っても嵐に当たる時間は変わりません。嵐は時刻を選ばないので、同じ割合で夜の加工の枠からも 引きます（屋根を建てていない場合。8.1.3節の handwork の列と同じ切り方）。引いたぶんは消えずに 嵐で止まる時間として割り付けに残るので、1日はちょうど24時間のまま揃います（8.3節）。

頭打ちに使うのは採れる時間で、手元の作業ができる時間ではありません。 この式が割っているのは 屋外の枠であって、手元の作業が当たっているのは夜の加工の枠のほうだからです（8.3節）。

引いた線は次のとおりです。 1日は1つの土地で使い（往復1回、余りは翌日へ繰り越さない）、荷物は数えず （運べる量に上限が無いので、採ったものを置いて帰る自由はこの勘定に現れません。 ExplorationSystem.md 1.1節）、探索の抽選は解きません （探索は回数と時間だけで測ります）。

8.3 1周回は、2つの局面を積んで出す

同じ28個の山が、局面ごとに数え直すと約117日ぶんになります。 内訳は 島を開く16.0日と、開き切った後の101.4日です。

局面は2つに割りました。割る位置を決めているのは「探索がまだ残っているか」の1点だけで、 どちらの1日も8.2節の同じ式で出ます。1日の側は500シードの実測 （stats/terrain.yaml の exploration_phase・steady_phase、拠点は片道が 平均で最も短い土地）、消化するものは4節の一覧（同 work_piles）です。日数は島ごとに積んでから 平均します（同 cycle）——島をまたいで平均した1日で割ると、日数は短く出ます （TerrainStats.md）。

28個の山（約63500分）のうち、屋外での採取・伐採・運搬を2/3 （約42300分）、拠点での加工を1/3 （約21200分）と置いています。この割合と、下の土地の配分は 仮置きです。

探索の局面で移動が重いのは、行き先が選べないからです。 未踏の土地は拠点から近い順に開いていく ので、前線が遠ざかるほど往復が滞在時間を食います（上の表の1日の移動は、定常より大きく膨らみます）。それでも 1日に進む探索が、往復と生存の採取を引いた残りの枠にも届かないのは、遠さではなく土地を1つ 開き切るまでその土地に居る必要があるためです——道は [2, max−1] に均等配置されるので、最後の道はほぼ探索し切る直前に出ます （ExplorationSystem.md 3.2節）。

定常の局面では、行き先を選べます。 山の配分を開けた土地1/2・森1/4・密林1/4と置き、その組の 中では最も実入りの多い土地を選びます。ただし配分が決めるのは仕事の量であって、日数ではありません ——実入りの少ない土地ほど、同じ仕事量に多くの日を使います。組ごとの往復の移動・1日に進む山・ 日数の割合・その組を持つ島の割合は、stats/terrain.yaml の steady_phase_by_work_share に1本だけ持ちます。

いちばん高く付くのは密林です。 土地の組のうち1日に進む山がいちばん少ないので、仕事の4分の1が、 密林のある島では日数の35.8%を持っていきます。しかも足止めしているのは距離ではなく暗さなので、 道を短くしても縮みません。配分を動かすには「どの材料がどの土地で採れるか」 （2.3節）から決め直すことになるので、本節では触っていません。

夜は、睡眠360分と、焚き火のそばでの加工347分。 加工の枠は、日暮れから眠るまでの360分から嵐の夜のぶんを引いたものです（8.2節）。1日は、屋外の枠・ 夜の加工・睡眠に、嵐で止まる40分を足してちょうど24時間になります （tests/diagnostics/dailyPhaseAssumptions.test.ts が見張ります）。 律速は屋外です——拠点での加工は約21200分で、夜の枠に対して 61日ぶんなので、約117日の中に余裕で収まります。夜が足りなくなることはなく、 足りないのは昼です。 言い切りが崩れるのは嵐が夜を食う割合が膨らんだときか、拠点の加工が積み 上がったときで、その境目は tests/diagnostics/nightCraftBudget.test.ts が持ちます。

この約117日は上限としても下限としても読めません。 上へ振れる材料は、4節の山の多く ——なめし革の背負い袋（1日）のように objects が空の行——に まだ宣言が無く、日数が実測ではなく置いた値であること。下へ振れる材料は、探索の局面の 16.0日に山を1分も乗せていないこと ——1日の枠325分に対して探索は 175分しか進まないので、 余る150分×16.0日は山へ回せます。

「1周回は約480日」という前の結論は取り下げます。 480日は、密林のような暗い土地でも生存の採取を 丸ごと引いていた（そこでは1日に働ける時間がそれに足りないのに）ことと、移動を「一様に選んだ行き先へ 1箇所」（251分）と置いていたことの2つで膨らんでいました。日数の側から山を減らす理由は無く、 GameEndings.md 8.1節の想定はこの実測に合わせてあります。

8.3.1 泊まりがけは入れない【確定】

拠点へ戻らずに泊まる行程は、骨格に入れません。今の島は端から端まで日帰りで届くので、入れても 日数はほとんど浮きません。

退けたのは「島を広くして成立させる」ほうです。 泊まりを選ぶ理由を作るには島の広さから変える ことになり、そのために動く量に対して、返ってくる短縮はごくわずかです。

【いつか: 泊まりがけ】 島の広さが変わったら入れます（Someday.md）。

出どころ: #656（泊まりがけは入れない）

8.3.2 日帰りだけで足りている実測と、そこで落ちる段

8.3.1節から導いたもので、覆すのに人間の判断は要りません。

土地ごとに日帰りと泊まりの安いほうを採っても15.14日で、日帰りだけの16.01日とほとんど変わりません。 500島のうち100.0%が、日帰りだけで全土地を開き切ります。縮尺（#797）が入って、往復が屋外の枠693分から 生存の採取189分を引いた残りを使い切らなくなったためです。

端まで届くことも同じ枠で出ます。 拠点から最も遠い土地への往復は、最も広い島でも 450分で、上と同じ残り ——屋外の枠から生存の採取を引いたぶん——に収まります（同 base_farthest_round_trip）。補給を持ち出す理由が島の広さからは生まれないという ことでもあり、そちらはGameEndings.md 9.2節が扱います。

「端から端まで」は拠点を選んだ側の話です。 どの土地を拠点にしてもよいなら端まで届かない島は あります（同 base_farthest_round_trip の base: any）。プレイヤーは拠点を選べるので1周回で実際に 払うのは選んだ側のほうで、8.3.1節の確定もこの範囲を指しています——条件の悪い土地に住めば届かない のは、島が広いからではありません。どの土地がそうかは、この節からは出ません（base: any は 拠点ごとの値を1本にまとめた分布で、土地の型を持ちません）。

これで移動の距離を安くする段が2つ落ちます——泊まりの行程（2日）と、遠い場所へ置く前線（4日）です。 残る段が無くなったので、移動の距離は系統から外れました（3.1節）。そりは落ちません。積む量が4〜6日ぶんへ 縮んでも、浜までの陸の運搬は1度で担げる重さを超えます（5節の4番）。

9. 骨格の都合で要ると分かった、まだ無い文法

ここでは決めません。 本当に要るかは、骨格が固まってからまとめて判断します。

• 段の解放条件（スキルの連言）は SkillSystem.md に既にあり、新設は要りません。

未決事項・今後の検討課題

• 1周回の日数（8節）。局面ごとに数えると約117日（探索16.0日＋定常101.4日、8.3節）。残る仮置きは 屋外の割合（2/3）と土地の配分（開けた1/2・森1/4・密林1/4）の2つで、日数を支配しているのは後者 ——密林で1日に進む山の少なさが、4分の1の配分で日数の35.8%を持っていきます。どの材料がどの土地で採れるか （2.3節）を決めると、この数字は動きます。
• 天気の7段の風速（8.1.5節）。明るさの透過率と違って実測に合わせたものではなく、ビューフォート 風力階級の目安から置いただけです。線を跨ぐのが嵐だけであることは決まった（8.1.4節）ので、 残っているのはその形を保つ範囲での6段の値です。
• 散らばりをどこまで許すか（2.3.3節）。「大きすぎる」の線は実測の分布を見てから引きます。
• 固定シナリオ（山がある島・湖がある島のように、その島が何であるかを保証で決めたもの）を用意するか。 用意するなら、そのぶん生成の自由度が下がるので、2.3.3節の散らばりも一緒に動きます。
• アーティファクトの24種類の中身と、1つあたりの重さ（6節）。出どころごとの数だけを決めてあり、個々の物は 未定です。重さは、6つ積んだときに積荷が横断を長くする段を越えるかどうかで決まります（Voyage.md 3.2節）。
• 手当てを系統に数えなかったこと（3節）。段の連なりを持たないという理由ですが、治療の道具・薬草に段が できるなら3節の表に入ります。