# Elona を AI がプレイするための手引き ― トークン削減の仕組み・画面のテキスト化・ゲーム知識

この文書だけで、事情を知らない別の AI が同じ方法を再現できるように書く。
環境（QEMU + ReactOS で Elona を起動する部分）は別文書 `01-qemu-elona-environment.md` を前提とするが、
考え方と手順は他のエミュレータ/リモートデスクトップ環境でも応用できる。

前提の整理:
- 操作する側は LLM（以下「AI」）。AI はゲーム画面を直接見続けることができず、
  「観測する → 考える → キーを送る」の往復でプレイする。
- ゲームは QEMU ゲスト（ReactOS）の中で動いており、AI のいるホストから
  QEMU モニタ経由で画面取得（screendump）とキー送信（sendkey）ができる。
- 対象ゲーム: Elona 1.22（バニラ）。ElonaPlus / Elona Mobile 等の数値は使わない（§D-1）。

凡例: [Wiki] = ネットの Wiki で取れる知識 / [実測] = 実際にプレイして確かめた知識 /
[教示] = プレイ経験のあるユーザーから教わった知識。出典が違うものは混ぜて書かない。

---

# A. トークン消費はどういう理屈で減らしているか

## A-1. コストの構造（まずここを理解する）

AI のトークン消費は、ざっくり次の2つの掛け算で決まる。

```
総コスト ≒ (1回の観測で AI に入る情報量) × (観測→判断→操作の往復回数)
```

- 画像は情報量が大きい。スクリーンショットを1枚 AI に見せると、それだけで大きなトークンになる。
  しかもゲームプレイは観測が何百回も必要なので、毎回画像を見ると消費が跳ね上がる。
- 対して、座標や HP のような数値数個、会話文数行といったテキストは、画像より桁違いに小さい。
- もう一方の「往復回数」も効く。1歩進むごとに AI が考え直すと、その都度推論トークンが発生する。

したがって対策は「1回の観測を小さくする」と「往復の回数を減らす」の2方向になる。
以下 A-2 の5つの仕組みは、すべてこのどちらか（多くは両方）に効く。

## A-2. 削減の5つの仕組み

### 仕組み1: AI の外で前処理する（最大の削減策）
画面の解釈を AI 本人にやらせず、**ホスト側の普通のプログラム**（OCR、メモリ読み、
テンプレート照合）にやらせる。プログラムの実行は LLM トークンを消費しない。
AI に渡るのは処理結果のテキストだけになる。

```
ゲーム画面 (画像, 大)
  → [ホスト側プログラム: OCR / メモリ読み]  ← ここはトークン消費ゼロ
  → 結果テキスト (数行〜数十行, 小)
  → AI が読んで判断
```

### 仕組み2: 渡すテキスト自体を小さく絞る
- 全画面を OCR せず、必要な矩形だけ切り取って OCR する（会話欄、ログ欄、状態欄。方法は §B-2）。
- メモリ読みでは、必要なフィールド（座標・HP・所持金）だけを整形して1行で出す。
- 会話は1ページごとに AI に見せず、ページを自動で送り切ってから全文を一括で渡す（§B-5）。
  ページごとに往復すると、その回数分だけ推論が発生する。

### 仕組み3: 観測を「安い順」に段階化し、必要な時だけ格上げする
安くて速い確認で済む場面では、それで終わらせる。異常や判断材料が足りない時だけ
一段重い観測に進む（段階の詳細は §B-6 の早見表）。

```
数値確認 (約0.5秒, 最安) → 部分OCR (数秒) → メモリ全文/全キャラ走査 (数秒〜41秒) → 画像認識 (最も高い)
```

### 仕組み4: 操作をまとめて送り、確認は節目だけにする
- 移動やキー操作は、AI が1回考えたら複数キーをバッチで送る（§C-1）。
  途中確認はせず、バッチの終わりに安い数値確認を1回だけ入れる。
- 繰り返し使う移動は、ホスト側スクリプト（自動歩行ドライバ、§C-2）に任せる。
  スクリプトが「1マス進む→座標確認」を自前で回すので、AI の往復は「出発指示」と「到着報告」の2回だけになる。

### 仕組み5: 知識と状態をファイルに外付けし、再調査しない
- 調べたゲーム知識、街の座標、失敗の教訓、現在のプレイ状態をファイルに書き残す
  （今回の例: STRATEGY.md = ゲーム知識、PLAYSTATE.md = 状態と教訓）。
- 次のセッションや別の AI は、それを読めば同じ調査・同じ失敗を繰り返さなくて済む。
  「調べ直し」と「同じミスの繰り返し」はどちらも丸ごとトークンの無駄なので、
  小目標が終わるたびにログを見直し、無駄だった手順はその場で直してファイルに残す（§C-5）。

## A-3. それでも残る消費（実測の目安）

- 上記を徹底した実プレイでも、消費は **プレイ中心の時間帯で週トークン上限の約2〜2.5%/時** だった
  （2026-11-01、約18時間の記録からの換算。区間で 1.8〜3%/時 の幅）。
- 画像認識が集中する場面（NPC 探し等）では、1時間に画像確認が約30〜35回必要になった。
  画像をゼロにはできない。用途を §B-6 の場面に限定し、それ以外をテキストに寄せるのが現実解。
- トークン量の測り方: 週使用率は `subscription-status status`（Muse の利用状況表示）で取る。
  会話の文脈使用率（session_status の %）は別物なので混同しない。

---

# B. 画面を「画像」ではなく「テキスト」で読む方法

方法は4系統ある。どれも「ホスト側プログラムでテキスト化し、AI はテキストだけを見る」点が共通。

## B-1. 系統の全体像

| 系統 | 元データ | 変換方法 | 向いている対象 |
|---|---|---|---|
| (1) 部分OCR | screendump 画像 | 矩形切り取り＋拡大＋tesseract | 会話欄、メッセージログ、状態表示 |
| (2) メモリ直接読み（数値） | ゲスト物理メモリ | 構造体のオフセット読み | 座標、HP/SP/MP、所持金、NPC位置 |
| (3) メモリ直接読み（文字列） | ゲスト物理メモリ | SJIS文字列バッファの読み | 会話文の正確な全文、ログ/アイテム名 |
| (4) テンプレート照合 | screendump 画像 | キャラチップの相関照合 | (補助) NPC/アイテムの画面上位置 ※精度は限定的 |

## B-2. (1) 部分OCR の具体的手順

1. QEMU モニタに `screendump <path>.ppm` を送り、画面を PPM で取得して PNG に変換する。
2. 画面全体は OCR しない。Elona のウィンドウ（800x600 前提）から、必要な矩形だけを切り取り、
   約3倍に拡大してから `tesseract <img> stdout -l jpn --psm 6` に掛ける。
   切り取り矩形の実績値（画面座標）:
   - 会話/メニュー欄: (90,120)-(710,570)
   - メッセージログ: (120,540)-(800,600)
   - 状態異常の表示欄: (0,430)-(95,535)
   - look モードの対象表示: (55,475)-(760,600)
   矩形は自分の環境で1回、既知の画面（会話中/フィールド）を見て合わせればよい。
3. **会話ウィンドウが開いているかの判定**は、会話欄エリアの平均輝度で行う。
   フィールド画面は平均約38、会話ウィンドウ表示時は約215 になる。閾値70で機械的に判別できる。
   この判定自体もプログラム側で行い、AI には「会話あり/なし」の1語だけ渡す。
4. OCR の弱点と扱い:
   - 小さいフォントやアイコン混じりの画面（所持品一覧等）は文字化けが多い。
     **1回化けたら繰り返さない。** 系統(3)で読むか、画像認識に1回だけ切り替える。
   - 全画面OCRは数十秒かかることもある（実績: 掲示板読みで約80秒）。
     最初から画像2枚の方が速い場面もあるので、§B-6 の使い分けに従う。

## B-3. (2) メモリ直接読み（数値）― 仕組みと校正手順

Elona は HSP製プログラムで、キャラクターの状態は決まった形の構造体（chara構造体）として
ゲストメモリに並んでいる。オフセットは起動しても変わらないが、構造体の置かれる
アドレスは起動ごとに変わる。そこで「校正（アドレス特定）→ 軽い読み」の2段構えにする。

### 校正（ゲーム起動ごとに1回）
1. QEMU モニタの `pmemsave 0 1073741824 <dumpfile>` でゲスト物理メモリ全量（1GB）をダンプする。
   所要約41秒（転送待ちを含む）。重いので起動直後に1回だけ行う。
   **安全注意: ダンプ解析で int32 のコピーを作ると 4GB になり、ホストのメモリ不足で
   ゲストごと落ちた事故がある。必ず memmap / uint8 ビューで読み、解析ツールには
   メモリ使用の自己上限（例: RLIMIT_AS 3.5GB）を入れる。**
2. ダンプから PC の chara 構造体を探す。先頭の int32 が **43081808** で、
   続く2つの int32 が (0, 1) になっているブロックが候補。
   候補が複数あれば「+0xD0 の位置が (HP, 最大HP, …) として辻褄が合うもの
   （HP=最大HP、1〜9999 の範囲等）」を採用する。
3. 採用したアドレスを `mem_offsets.json` の `pc_base` に保存する。

### オフセット表（chara構造体、PC/NPC共通）[実測]
| 位置 | 内容 |
|---|---|
| +12 / +16 | 現在マップでのタイル X / Y（+20/+24 にもコピーがある） |
| +36 | chara id（NPC の種類。例: 345=レーネイル、346=ロミアス ※序盤NPC） |
| +0xD0 から int32×7 | HP, 最大HP, SP, 最大SP, 0, MP, 最大MP |
| vitals(-80) ※vitals=+0xD0 の位置基準 | 所持金 |
| vitals(+56) | 満腹度 ※ただし実態とずれる事例あり（§D-3 の餓死の項を参照）。鵜呑みにしない |

### 軽い読み（プレイ中の常用）
- 校正後は、ダンプを繰り返さない。QEMU モニタの `xp /8wx <アドレス>` コマンドで
  構造体の該当部分だけを直接読む。1回約0.5秒で
  `[PC] tile=(x,y) HP=.. SP=.. MP=..` のような1行が得られる。これがプレイ中の主確認手段。

### 全キャラ走査（census）
- NPC の居場所は、画面を探し回らずメモリで取る。ダンプ全体をベクトル演算で走査し、
  chara構造体の形（先頭パターン＋座標のコピー一致＋HP の辻褄）に合うものを列挙すると、
  約3秒で「id・座標・HP の一覧テキスト」が得られる。
- ただしこれはダンプ時点の位置。動いた後の位置が要るなら、ダンプを取り直してから走査する。
- id と実名の対応は、Wiki のデータや、実際にぶつかって会話する確認で付ける（§D-1, D-3）。

## B-4. (3) メモリ直接読み（文字列）― 会話文を OCR なしで正確に読む

- 現在表示中の会話ページの全文は、専用の文字列バッファに SJIS（NUL終端）で入っている。
  ここを読めば、OCR の文字化けなしに会話・選択肢の正確な文面が得られる。
- バッファのアドレスも起動ごとに変わる。校正手順:
  1. 会話を開き、ページを送る**前**にダンプを取る。
  2. 1ページ送ってから、もう一度ダンプを取る。
  3. 2つのダンプを比較し、「会話文らしい SJIS 文字列に変化した場所」を探す。それがバッファ。
  4. アドレスを `mem_offsets.json` に保存する（鏡像コピーが見つかることもある）。
- ゲーム中のログ文やアイテム名は、文字列プール領域（描画テキストの断片が集まる範囲）から拾える。
- 取れないもの: **地面に落ちているアイテムの位置**はメモリからは見つからなかった。
  名前はログ行から、位置は §B-5 の視覚補助＋「踏んだ時のログ」で補う。

## B-5. (4) その他のテキスト化の工夫

- **会話の自動送り（talk 方式）**: 会話には「(続く)」の印がある。プログラムが
  「印がある間はキーを送って次ページを取り、印が無いページ（選択肢）で止める」を繰り返し、
  全ページ分を貯めてから AI に一括で渡す。AI は選択肢の判断だけをすればよい。
- **テンプレート照合（視覚補助）**: キャラチップ画像をテンプレートに、画面との相関
  （FFT によるアンカー検出＋マスク付き正規化相関）で NPC やアイテムの画面上位置を推定する方法も試したが、
  タイル位相の数 px のずれで精度が安定しなかった。**表示画像から目測した座標は信用しない**こと。
  位置の正はメモリ読み（系統2）であり、視覚は補助に留める。

## B-6. 観測手段の使い分け（判断表）

| 場面 | 使う手段 | 理由 |
|---|---|---|
| 移動中の位置・HP確認 | メモリ読み（xp、約0.5秒） | 最安・最速。画像もOCRも不要 |
| NPC の居場所を調べる | census（全キャラ走査） | 画面を探すより速く確実 |
| 会話の内容・選択肢 | 文字列バッファ読み → 部分OCR | 正確さ優先。OCR が化けたら切り替える |
| メッセージログの確認 | 部分OCR（ログ欄のみ） | 範囲が小さく OCR が安定する |
| メニューのカーソル位置 | **画像認識** | カーソルはテキスト化できない |
| 買い物の個数・合計金額 | **画像認識** | 誤購入は損失が大きい。要確認 |
| 依頼掲示板の金額・内容 | **画像認識**（または慎重なOCR） | 行折れで金額を誤読した実績あり |
| 初見の場所の構造把握 | **画像認識**（1枚だけ） | 全体像は画像が速い。その後はテキスト運用へ |
| 所持品一覧の品名 | 画像認識 or 売買画面等の一覧 | OCR が最も化ける画面。深追いしない |

---

# C. 操作とプレイ運用の効率化

## C-1. キー送信の約束事
- 送信は QEMU モニタの `sendkey`。**確定系のキーは 400〜600ms の長押し**を指定する（短打は抜けることがある）。
- 形式は `key:hold_ms` の列＋ `wait:秒` でバッチ化する。例: `ret:600 wait:3 a:600`
- **キーを送るたびにスクリーンショットを撮らない。** 確認はバッチの終わりに1回だけ。
- 修飾キー単体（Alt 等）は送らない。ゲスト側に残留して以降の入力が化ける。
  キー異常がゲーム再起動で直らなければ、ゲストの system_reset（再起動）で直す。
- テンキー移動が突然効かなくなることがある（NumLock 反転の疑い）。矢印キー＋Home/End/PgUp/PgDn で代替できる。
- 対話で文字キー選択が効かなくなったら、方向キーでカーソルを合わせて Enter で確定する方式に切り替える。
- **キー割り当ては推測しない。先にゲームの `config.txt` を読む**
  （実績: 所持品=X(Shift+x)、干渉=i、キャラ情報=c、特殊行動=a、特徴=F(Shift+f)、ジャーナル=j、寝具を使う=t、休憩=R）。

## C-2. 移動ドライバ（スクリプトに任せる）
- 方式: 「目標の軸を固定し、ウェイポイントを順に辿る」。1マス進むごとにメモリ読みで座標を確認し、
  進めていなければ（壁・NPC・ダイアログ）対処してから続ける。
- 斜め優先の貪欲な移動は、生垣等で空転して約6分溶かした実績がある。軸固定方式にすること。
- **例外（危険）**: 店主・行商人・バーテンダーのいる建物内では、ドライバの「ダイアログ自動閉じ」を使わない。
  行商人にぶつかった際、自動操作が「買う→商品→数量→購入確認」まで進んでしまった事故がある。
  建物内では選択肢を必ず目視（画像/テキスト）確認してから確定する。

## C-3. 「動かない」時の切り分け手順（最重要の時短）
移動キーを送っても座標が完全に変わらない場合、原因はほぼ次のどれか。順に疑うこと。

1. **ダイアログがキーを吸っている**（最も多い）: y/n 確認（街の出口の「〜を去る？」等）、
   イベントカード、会話、死亡時の遺言入力ボックス。→ テキスト/画像で1回確認し、正しい方法で閉じる。
   イベント/ガイドカードは Esc で閉じる。会話を閉じた「つもり」でも別れのページが続くことがあるので、
   閉じた後はテストで1歩だけ動かし、座標が変わることを確認してから本移動に入る。
2. **AUTO TURN 中**: 睡眠・収穫などの自動処理中は入力が効かないのが仕様（§D-3）。
   → 最低5分待ち、メモリ読みで状態変化を確認し、キーを1回だけ送って反応を見る。
   これをせずに「凍結」と判断して再起動すると、正常な処理を壊して時間を失う。
3. **入力系の異常**: NumLock 反転、修飾キー残留、ゲストOS側のキーボード状態異常。
   → 代替キーで切り分け、最後はゲスト再起動。

## C-4. セーブの扱い
- Elona のセーブは**マップ遷移時**（街の出入り・ダンジョン入退場・睡眠の起床時等）に自動で行われる。
  街の中で進めた買い物・納品は、遷移前に環境が落ちると巻き戻る。
  **大事な成果が出たら、すぐに街を出入りしてセーブを確定させる。**
- 区切りごとに「記録して終了」はしない。終了→再起動→再開→メモリ再校正の往復で約7分溶ける。
  安全な場所に駐車したままゲームを起動し続け、次の作業にライブ状態を引き継ぐ
  （同じプロセスならメモリ校正もそのまま使える）。完全終了は、プレイを止める時・長い中断の前・危険な操作の前だけ。

## C-5. ログと点検（無駄を繰り返さない仕組み）
- プレイログを必ず残す。書式: `[実時刻] したこと / 考えていること / 待った時間`。
  時刻は推測で書かず、その都度 `date` で実時刻を取る（推測で最大5分ずれた実績がある）。
- 小目標が終わるたびに3点を行う:
  1. ログを見て「無駄な動作・無駄な観測」を点検し、直し方を決める。
  2. 教訓を知識ファイル（PLAYSTATE.md / STRATEGY.md 相当）に書き足す。
  3. ユーザーへ報告する（何が終わったか、終了時刻、週トークン使用率）。
- 作業の区切りは約25分・小目標1〜2個までにする。1時間級の単独作業にすると、
  途中で終わった小目標を報告できず、異常の発見も遅れる。

---

# D. Elona のゲーム知識

## D-1. ネットで取れる知識の取り方

主ソースは冒険者の休息所 Wiki（wikiwiki.jp/elona）。次の手順で取ること。

1. **版を固定する**: 対象はバニラ 1.22。検索結果には ElonaPlus / Elona Mobile / Omake 等の
   別版の数値が混ざる（例: 税金の計算、スキル習得コスト、癒し手の可否が版で違う）。
   ページ内の版表記を必ず確認し、別版の数値は採用しない。
2. **読むページの優先順**:
   - 「初心者向け序盤ガイド」… 序盤の進め方全体
   - 「解析/睡眠」「状態異常」… 睡眠と状態異常の正確な仕様
   - 「アイテム/食べ物」「モンスター/食事効果」… 食料と能力訓練
   - 「依頼」「システム/カルマ」「システム/ランクと給料」… 依頼の罰則、カルマ、税金・給料
   - 「スキル」「信仰」… 習得コストと信仰候補
   - 街や施設は公式マップ画像（例: ヴェルニースの全体マップ）も併用する。
     ただしマップ画像からの座標推定は ±2 タイルずれることがあるので、実地確認が正（§D-3）。
3. **検索の仕方**: 日本語のゲーム用語で引く（例: 「Elona 睡眠 潜在」「Elona カルマ 犯罪者」「Elona 旅糧 荷車」）。
   数値は2ページ以上で突き合わせる。個人ブログの体感値は目安に留め、Wiki の数値と区別して記録する。
4. **ゲームファイルからも取る**: キー割り当ては `config.txt`、街の位置などの固定データは
   ゲームデータ/マップエディタ系の情報が正確（例: ヴェルニースのワールド座標は (26,23) で固定、
   地殻変動でも街は動かない）。
5. 取った知識は、出典と版を添えて自分の知識ファイル（STRATEGY.md 相当）に整理してから使う。
   整理済みの要約は §D-4 に置くので、急ぐ場合はそこから始めてよい。

## D-2. ネットで取れない/取りにくい知識は、この文書に直接書く

次の §D-3 は、Wiki に載っていないか、載っていても環境差・実地差で上書きが必要だった知識。
他の AI は調べ直さず、このまま使ってよい。

## D-3. 実測・教示による知識（このまま使う）

### 環境（ReactOS ゲスト）固有 [実測]
- **ベッド睡眠は正常に動く**。寝具の隣で Space → 足元の寝具を選ぶ。効果は全回復＋起床時に夢イベント。
  ただし睡眠の完了後は「起床/夢カードの入力待ち」で画面が止まって見える。当日の画面取得ラグ
  （screendump 15〜79秒）と重なると凍結に見えるが、§C-3 の手順で切り分けること（誤診で2回再起動した）。
- **[R] 休憩による睡眠はこの環境では使えない（確定）**。定量確認の実績:
  [R] を押してから10分間メモリ読みで監視しても、ターン数・ゲーム内時計・SP・状態が全て不変だった
  （セッション8でも約20分進まなかった。合計2例）。睡眠は寝具 [t]/ベッドか、移動中の自動仮眠で取る。
- **実家（わが家）に寝具はない（確定）**。全室を踏査済み。睡眠手段は街の民家のベッドか、寝袋等の寝具を買って [t] で使うこと。
- ゲストのキーボードは英字配列のみ。キャラクター名などは英字で入力する。

### ヴェルニースの実地情報 [実測]（公式マップとの座標ずれを修正済み）
- ワールド座標: ヴェルニース (26,23)、実家 (22,21)（ヴェルニースの北西すぐ、丘の中）。
  街への入場はタイルの上で **Enter**。Space は入場ではない（ターンを進めるだけ）。
  道タイルでは野外に入らず、草タイルでのみ野外マップへ自動入場する。
- 依頼掲示板: 広場の北西 (15-16,18)。北向きにぶつかると開く。ページ送りは右キー。
- 井戸: (20,20)。**ペットは斜めに近道して井戸水を飲み、落下死することがある**（実績複数回）。
  井戸の列 (x=20) を横切る時は、ペットの位置を確認するか、井戸から2列以上離れる。
- 酒場: 入口は西扉 (35,24)。バーテンダーはレバロア（女性）。ペットの復活は彼女の「仲間を呼び戻す」で、
  費用 = ペットLv² × 15gp（Lv1 なら 15gp）。復活後はすぐ街を出入りしてセーブ確定。
- ベッドのある民家: 武具店ピロイの家のベッド (11,8)-(11,9)。隣接して Space で使う。無料で全回復できる。
- 店主は夜に帰宅して店にいない。買い物は日中に。店の在庫は一夜では回転しない。
- 雑貨屋: 入口は南 (11,19)、店主シロン。南の出入口は x=11 の列が確実。
- 魔法店: 南の建物の西端、入口は北側 (7,22)。店主カプバード。軽傷治癒ポーション 147gp/服（実績価格）。
- 買い物の個数指定: 画面の ◀▶ クリックも数字直打ちも効かない。**kp_4 / kp_6 で調整**する
  （1回で2ずつ動くことがある）。確定（Enter）の前に、必ず合計金額を画像で確認する。
- 街の出口ゾーンは南門付近。踏むと「ヴェルニースを去る？」の y/n が開き、開いている間は移動キーが全て吸われる。

### 移動と時間 [実測]
- ヴェルニース → 実家: ゲーム内 **23時間・48マイル**（雨＋重荷の条件）。
  最も近い隣町でも約1日かかる。配達の可否判定（§D-4）にこの実測を使う。
- グローバルマップ移動は満腹を大きく消費する（旅糧が自動で食べられるのはこの時。§D-4）。

### 最初のペット [実測/Wiki]
- 初めてヴェルニースに入るとイベントで最初のペットが仲間になる（犬/猫/熊/少女から）。
  犬の名前は「犬のセイモフ」だった（個体差ありうる）。

## D-4. Wiki から整理した序盤知識の要約 [Wiki]＋[教示]

### 満腹と食料（死因の上位。最優先で守る）
- 満腹度の目安: 12000以上=食過ぎ / 10000以上=満腹 / 5000以上=表示なし / 2000以上=空腹 /
  1000以上=飢餓（速度-10%、自然回復なし）/ 999以下=餓死中（速度-40%、毎ターン最大HPの約2%ダメージ）。
- **待機や長距離移動で満腹は減り続ける（約1/ターン）。監視を怠ると安全な場所でも餓死する** [実測: 実家で餓死]。
  節目ごとに画面の空腹アイコンを確認し、食事を挟む。メモリ上の満腹値だけを信用しない。
- 食べると主能力の**経験値**が入る（潜在そのものは上がらない）。潜在を直接上げるのはハーブ
  （例: モージア 105gp、筋力・耐久の潜在。戦士の最重要ハーブ）。
- 自動で食べられるのは**旅糧**（荷車＝Cargo枠、グローバルマップで空腹以下になると自動消費）。
  **兵糧**は通常アイテムで自動消費されない。混同しない。
- アピの実: 0.04s、腐らない、生食が正解（調理すると10倍重くなる）。
- 死体（〜の死体）: 4時間で腐る。有毒種・アンデッドは生食が危険。調理すると腐敗が72時間にリセットされ安全になる。
- 呪われた食料は満腹半減＋必ず嘔吐。短期間に10回以上嘔吐すると拒食症（主能力経験値の恒久低下）。
  未鑑定の食料を連食しない。パン屋の設置パンは [e] で食べられるが呪いの賭けになる。

### 重量
- 重荷（50%超）: 速度-10%。重量挙げが鍛えられるので常態の上限はここまで。
- 圧迫（75%超）: 速度-30%。 出発前に解消する。
- 超過（100%超）: 速度-50%＋時々ダメージ。
- 潰れ中（200%超）: 移動不可＋帰還・脱出不可＋大ダメージ。重い宝箱類は拾わずその場で開ける。
- 荷車の上限は初期 80.0s（交易品と旅糧だけの別枠）。超えると移動が激減する。絶対に超えない。
- 整理の定石 [教示]: 使わない重要品は家に保管し、それ以外は捨てて軽く移動する。
  野外で拾える軽い品（クズ、木片、骨、クズ石、ミカ、各種結晶、割れた壺など）は
  調達依頼で頻出するので、見つけたら備蓄しておくと依頼が効率化する。

### 依頼の選び方（失敗ペナルティで選ぶ）
| 種類 | 失敗時の罰 | 方針 |
|---|---|---|
| 調達「〜が欲しい」 | 名声のみ | **確実に持っている/店で見かけた時だけ受ける** [教示]。それ以外は見送り |
| 交換「〜を持っている〜が欲しい」 | 名声のみ | 対象人物に話しかけると物々交換できる。地面に落ちていた物でも交換できることがある [教示]。対象の居場所は街のガード（鎧の兵士NPC）に聞ける [教示] |
| 収穫 | 名声のみ | **序盤は受けない**。筋力が低いと制限時間内に終わらず失敗しやすい [教示]（実測でも失敗） |
| 配達 | **カルマ-20** | 条件を全て満たす時だけ（下記）。請負中に帰還/脱出を使うと更に -10、品は「大事なもの」に指定 |
| 護衛 | カルマ-10 | 序盤は見送りが無難 |
| 討伐 | 名声のみ（ただし戦死リスク） | 報酬額 ≒ 難易度。序盤は高額な討伐を受けない |

- 配達を受ける条件 [教示]: ヴェルニース/パルミア/ヨウィン/ダルフィ等、大陸中央側の隣町同士なら可。
  期限の目安は**残り約5日あれば、未実測の隣町でも安全**。それより短い場合は、
  その町まで実際に移動して所要時間を測ったことのあるルートでなければ受けない。
  「(すごく重い)」配達は絶対に受けない。
- 同時受注は5件まで。名声は上げすぎない（上がると税金・依頼難易度・襲撃が全部厳しくなる）。

### カルマ（-31以下で犯罪者。取り返しが最も重い）
- 目標は常に0以上。**カルマ0から配達失敗1回 (-20) ＋帰還使用1回 (-10) で -30**、あと一手で犯罪者になる計算を常に意識する。
- 下がる行為の代表: 配達失敗-20 / 護衛失敗-10 / 配達・護衛中の帰還・脱出-10 / 落とし物の財布を開ける-4 等。
- 上げる行為: 依頼達成+1 / 落とし物を未開封でガードへ届ける+5 / 埋葬+5。

### 睡眠とエーテルの風
- 睡眠の効果: PC とペットの HP/MP/SP 全回復、状態異常（死亡以外）の回復、主能力の潜在上昇、起床時にセーブ。
  睡眠は7〜11時間進むので、依頼期限と食料の腐敗に注意。寝具は [t] で使う。
  要睡眠（赤）になると自然回復が止まり、スタミナが減って過労になる。
- **エーテルの風: 3・6・9・12月の1〜10日**に吹く可能性がある。ゲーム開始は8月12日なので最初の山は9月1日。
  対策は避難のみ。8月30日夜までに実家か宿屋のシェルター（悪天候時は無料開放）に入る。
  期間中は配達・護衛を受けない。

### お金・pp・税金
- 給料: 毎月1日と15日に実家の給料箱へ入る。給料箱は実家の庭 (15,19) [実測]。
- 税金: Lv5までは免除。Lv6から課税（目安: 名声＋所持金/1000＋Lv×200）。払う場所はパルミア大使館。
  未払いが5枚以上溜まると以後毎月カルマ-60。請求書は持ち歩かない（焼失する）。
- pp（プラチナ硬貨）: 新規スキル習得 = 15＋(過去の習得回数×3) pp。潜在訓練 = 2＋(スキルLv÷5) pp。
  序盤の取得順: (1) 重量挙げ 15pp（ヨウィン） (2) 料理 18pp（ヴェルニース）。

### 戦闘の注意
- 近づかない敵: スライム（隣接すると装備が酸で劣化）、コボルト、大道芸人（遠距離から投げてくる）。
  序盤の狩場: 子犬の洞窟は Lv4 相当（まず1〜2層だけ）、スライムの坑道は Lv6 相当で後回し。
- 接近前にメモリ読みで敵の HP を見る。HP が3桁の相手は格上なので即退く。
  負け戦では回復アイテムのメニューを開く前にまず逃げる（メニュー操作中も敵は攻撃してくる）。
- ペットが死んだら酒場のバーテンダーで復活（§D-3）。危険な場所では待機させるのが安い保険。

### 信仰（中期の話。序盤は決めるだけ）
- 戦士向け: 癒しのジュア（回復＋料理/解剖学）か、地のオパートス（筋力・耐久・重量挙げ、被ダメージ-10%）。
  改宗は信仰の深さが0に戻り神罰もあるので、序盤に気軽に乗り換えない。

### 序盤ロードマップ（要約）
1. ヴェルニースで調達・交換を回し、1000gp台と pp15 を目指す。討伐の高額依頼は受けない。
2. ヨウィンで重量挙げを習得し、以後は重荷常態で育てる。
3. 子犬の洞窟1〜2層で杖・巻物・装備を整えてからポピー救出へ。
4. 8月30日夜までに帰宅し、エーテルの風をやり過ごす。Lv6になったら納税を習慣化する。

---

## 改訂履歴
- 初版: その環境でのプレイレポート形式（実測の羅列が中心）
- 本版: 他の AI が単独で再現できるよう、(A) トークン削減の理屈、(B) テキスト化の具体的手順、
  (C) 操作・運用の手順、(D) ゲーム知識（ネットでの取り方＋取れない知識の全文記載）に再構成した。