# 電子パッチ minimal spec v0.1 (STEP 1482)

> **藤本さん directive** (2026-08-28) + chat-Claude 分析 「電子パッチ は 実在する、 Claudeのスキル / システムプロンプト / カスタム指示 は 全部同じ原理」 の 直接実装 spec。 「重みは変わらない / 会話内挙動は変わる / ガードレールは外れない」 の 3 制約 embed、 天井 「新しい能力を install できない、 並べ替えて出やすくしている だけ」 を honest scope として 明記。

## 電子パッチ とは

チャット (LLM 会話) に **投入するテキストブロック** で、 相手 LLM が 決まった手順どおりに 動き出すもの。 chat-Claude 定義:

> 「普通のプロンプトはお願いなので、 LLM ごと・実行ごとに ブレます。 ブレを潰すには、 自然言語の依頼ではなく **実行可能な仕様の形** にする必要があります。 具体的には、 状態と遷移の明示 (今どのステップか、 次に何をするか)、 入出力の契約 (受け取る形式と 返す形式の 固定)、 禁止事項の明示 (勝手に先へ進まない、 勝手に解答を出さない)、 そして 出力前の自己検証ステップ。 要するに、 **LLMを抽象機械と見なして、 その上で走る小さなプログラムを書く** ことになります。」

## 3 form (同じ原理、 貼付先が異なるだけ)

| form | 貼付先 | 永続性 | 効き | 例 |
|---|---|---|---|---|
| **A: Portable text block** | 任意の LLM チャット (ChatGPT / Claude web / Gemini 等) | 会話単位 | 中 (会話が 長くなると 効きが 薄れる = 「指示の風化」) | ユーザーが 教材開始時 に 1 度貼付 |
| **B: Claude Code Skill** | `.claude/skills/<name>.md` (machine-parsed by Claude Code CLI) | Skill invocation 単位 | 高 (`/skill-name` で 明示発火、 skill body 全体を 都度 load) | STEP 1472 Collatz Descent Skill v0.1 (藤本さん自作) |
| **C: CLAUDE.md snippet** | project の `CLAUDE.md` | Session 全体 (毎回 auto-load) | 高 (常駐、 但し context 消費) | Rei-AIOS CLAUDE.md の 「セッション開始時の自動チェック」 section |

**同じ原理**: 3 form とも 「十分に構造化されたテキスト」 で 「会話内挙動を変える」。 特別な仕組みは 要らない。 貼付 protocol の 違いだけ。

## 5 必須要素 (chat-Claude 分析 に 基づく)

1. **状態と遷移の明示** — 「今どのステップか、 次に何をするか」
2. **入出力の契約** — 「受け取る形式 と 返す形式の 固定」
3. **禁止事項の明示** — 「勝手に先へ進まない、 勝手に解答を出さない」
4. **出力前の自己検証ステップ** — 「発話前に self-check、 通らなければ retry or 停止宣言」
5. **形式マーカー** — 「毎ターン state を 自己申告させる 固定 marker (例: `[state: awaiting_user_input]`)」 (chat-Claude 実効技法)

## 天井 (honest scope、 chat-Claude 分析 に 100% 認諾)

- ✅ **重みは変わらない** = 推論と学習は 別工程。 パッチは 「その場の文脈に置く」 だけ。 次会話に 持ち越されない
- ✅ **会話内挙動 は 変わる** = 手順の遵守、 出力形式、 飛ばさせない制御は 実際に 効く
- ✅ **ガードレール は 外れない** = 貼付テキストは system-level 指示より 権限低い層、 「危険防止のための階層構造」
- ⚠️ **決定性 100% には届かない** = LLM は 確率的解釈、 特に 会話長 = 効き薄れる (「指示の風化」)
- ⚠️ **新しい能力を install できない** = 「並べ替えて 出やすくしている だけ」、 数学ができない model に 証明を 書かせる パッチは 書けない = パッチ設計上 の **最大制約** (安全設計 でなく、 「無い袖は 振れない」)

## 効き を 上げる 5 技法 (chat-Claude 技法 + Rei stack 実装知)

1. **短く番号付き** — 冗長 = LLM が prioritize しにくい
2. **禁止事項を 明示** — 「〜しない」 を positive 側 「〜する」 と 並置
3. **毎ターン state を 自己申告** — 「返答冒頭に `[state: <X>]` を書く」 = drift 早期検知
4. **出力に 固定 marker を 埋める** — 「`<END_OF_SECTION>` で 締める」 = 途中省略を 構造的に 検出
5. **エスカレーション句** — 「判断に迷ったら 停止して 質問を返せ、 勝手に決めるな」 = hallucination 抑制

## 失敗モード (patch を 設計する時に 想定すべき 3 パターン)

| 名前 | 症状 | 対策 |
|---|---|---|
| **Drift (指示の風化)** | 5-10 turn 後 に state 忘れ、 flow が 崩れる | 毎ターン state 自己申告 + 定期 checkpoint 再送 |
| **Dilution (雑談混入)** | user が 雑談を 挟むと、 patch state を 失う | 「patch scope 外の 質問には 明示的に defer」 の 禁止事項 embed |
| **Obedience gaming (機械的服従)** | 形式マーカーは 埋めるが、 中身は 期待と 違う | self-verify step で 「マーカー 内容と 実質 一致 か 自己検査」 |

## テンプレート (form A: Portable text block)

```
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[PATCH v1: <patch-name>]

## 目的
<what this patch makes the LLM do>

## 状態 (STATE) 一覧
- S0: <initial state>
- S1: <next state>
- ...

## 遷移 (TRANSITION) rule
- S0 → S1 when <condition>
- ...

## 入出力契約 (I/O contract)
- 受け取る: <format>
- 返す: <format、 例: 「必ず冒頭に [state: <X>] を 書け」>

## 禁止 (PROHIBITIONS)
- <prohibition 1、 例: 「勝手に S2 を skip して S3 に 行くな」>
- <prohibition 2>
- ...

## 発話前 self-verify (毎ターン 実行)
1. state marker が 冒頭に あるか?
2. state 遷移 rule に 従ったか?
3. 禁止事項に 抵触していないか?
- 通らなければ retry、 3 回連続で 通らなければ 「PATCH_DISABLED」 と 宣言して 停止

## エスカレーション
判断に迷ったら 停止して 質問を返せ、 勝手に決めるな

## 発動確認
「PATCH_LOADED」 と 1 語だけ 返して、 次の user input を 待て
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
```

## Rei stack 既存 実装 との mapping

| Rei stack asset | パッチ form | 該当 STEP |
|---|---|---|
| CLAUDE.md (Rei-AIOS project) | C: CLAUDE.md snippet | (base、 常駐) |
| Collatz Descent Skill v0.1 | B: Claude Code Skill | STEP 1472 |
| memory system (MEMORY.md 直接 append 禁止 → inbox pattern) | C: CLAUDE.md snippet 内 protocol | STEP 1414+ (inbox 起源) |
| outbox pattern (chatClaude ↔ Claude Code baton) | A: Portable text block (canvas 保存) | STEP 1362 |
| CHECKER_SPEC_v0 判定経路 LLM 除外 discipline | 電子パッチ 型 (spec は 判定機械の 設計図) | STEP 1364 |
| rei-preregister v0.1 「グリーン ≠ 検証済み」 | 電子パッチ 型 (事前登録 discipline embed) | STEP 1359 |

## 関連 spec

- `examples/example-01-turn-structure-patch.md` — 1 数学問題 を N turn で 段階的に 解く 教材 パッチ
- `examples/example-02-extract-only-patch.md` — chat-log から 数式抽出 のみ、 生成しない パッチ (STEP 1473/1476 discipline を 独立 chat で 再現)
- `examples/example-03-honest-scope-patch.md` — 発言に 必ず 「honest scope」 セクションを 付加する パッチ (Rei stack 全体 discipline を 独立 chat で 再現)

## Honest scope (v0.1 制約)

- 3 form の 統一 spec だが、 form B/C の Claude Code CLI 前提部分 は 一部 form A に 移植できない (skill-fire-rate のような runtime metric は Claude Code 側 でしか 測れない)
- 「効き」 の 定量測定 は 別 STEP (skill-fire-rate 拡張 = STEP 1483)
- 「新しい能力 install」 は 不可能 = 対応外 (spec 側で 「そういう patch は 書けない」 を 明示)
- 「危険防止 layer 突破」 は 対応外 (安全設計 preserve)
- 実運用 での 会話長 vs 効き の trade-off は 経験則 = 数値保証なし
