---
name: feedback-overclaim-strength-calibration-pattern-2026-08-21
description: 主張 の 強さを 事実 に 揃える discipline。 「作り直し要」 「短絡」 「必ず」 「一切」 系 の 強い表現が、 実 制約より 主張を 強く する failure pattern。 chat-Claude 修正例 + 私 同 pattern 修正例 の 双方向 record
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 89a46b60-1f48-46e9-90c0-2e1985f4ae5c
  modified: 2026-08-21T03:04:32.399Z
---

# Overclaim strength calibration — 主張の 強さ を 事実に 揃える

## Rule

**「作り直し要」 「必ず」 「短絡」 「一切」 「完全に」 系の 強い表現を 使う 前に、 実 制約 が その 強さに 見合う か を verify する**。 特に **代替 approach を否定する 表現** (「〜せざるを 得ない」 「〜しなければ ならない」 「〜以外 不可」) は 実 制約 未 verify で 使うと overclaim になる。

**Why**:
- 強い 主張 は 判断を 早く 収束 させる が、 事実に 見合わない と 誤った 制約 を 想定 させて 選択肢を 狭める
- 未来 の 読み手 (別 session Claude、 別 agent、 藤本さん) が 主張 を そのまま 信じて **踏まなくて良い制約** を 前提 化する
- Chat-Claude 「配布に 切り替えるなら 左の形 に 作り直す 必要」 (2026-08-21 route B vs junction build) → 実は **exe (binary) は junction 構成 のまま で 配布可**、 制約 は 3 つ (rebuild 1 machine 固定 / ② 進化のたび 手動 rebuild / 第三者 build 再現不能) で **小規模 experimental なら 足りる** → 「作り直し要」 は 更新頻度上昇 or 非藤本さん rebuild 発生時 に 限定
- 私 「現 junction build 配布は 短絡」 → 同 pattern の overclaim、 実際 藤本さん の 決定 1 reverse は 妥当 な judgment

**How to apply**:
- 「作り直し要」 「〜必要」 系 の 表現を 書いた ら、 「本当に 現構成で 進められない ケース は 何か?」 を 一度 反問
- 反問 の 答えが **範囲限定 の 条件** (「更新頻度が 上がったら」 「第三者が build するなら」 等) なら、 主張 を 条件付きに 弱める:
  - **Before**: 「配布に 切り替える なら 作り直しが 要る」
  - **After**: 「更新頻度が 上がるか、 藤本さん以外 が rebuild する 必要が 出たら 作り直し要。 小規模 experimental なら 現構成で 足りる」
- 「短絡」 「意味ない」 「不十分」 系 の **代替 否定 表現** も 同様、 「どの 条件下で 短絡でない か」 を 併記 で 主張の 強さ を 事実に 揃える
- 相互 verify: 他 agent の 主張が overclaim だと 気付いた ら 指摘、 自分の 主張が overclaim だった と 気付いたら 直ちに soften (相互 self-audit の 姉妹 rule)

## 実発火 record

- **2026-08-21 rei-automator route B vs junction build 議論**:
  - Chat-Claude 初版 caption: 「配布に 切り替える なら 左の形 (route B runtime IPC) に 作り直す 必要があります」
  - 私 前 turn 説明: 「配布したい 場合 chat-Claude 推奨は route C (③ subprocess) の 実装が 妥当、 現 junction build 配布は **短絡**」
  - **Chat-Claude 自 修正**: 「配るのは exe (binary) であって source ではない、 junction 構成 のまま でも binary 配布可、 制約 は 3 つ で 小規模 experimental なら 足りる、 『作り直し要』 は 更新頻度上昇 or 非藤本 rebuild 発生時」 → artifact update
  - **私 同 pattern acknowledge**: 「短絡」 も 同じ overclaim、 実 制約 3 つ で 小規模 experimental なら OK → miss #7 self-audit ソフト分類
  - 結果: 決定 1 「自分専用 vs 配布」 の 二択 が **stable + experimental 並置 の 第三の形** に 収束、 「作り直し要」 「短絡」 と 主張 していた 場合 は この 選択肢が 見えなかった 可能性

## Cross-agent 相互修正 の 意義

- Overclaim は 単一 agent 内 で は 気付きにくい (自分の 主張は 自分では 検算しづらい)
- Cross-agent の **相互 audit** で 「そこ 強すぎ」 と 指摘 し合う 分業 が 有効
- 修正 側 も 自 miss を owned framing で 認め、 「片側 だけ の 話 に しない」 (2026-08-21 実例: chat-Claude 修正 + 私 同 pattern acknowledge を 併記)

## 「制約 を 3 つで 分解」 discipline (代替表現)

「〜要」 と 一言で 済ませる 代わりに、 **実 制約 を 3-5 個 に 分解** して 併記 + 「どの 制約が どの ケース で active になるか」 を 明示 する。 例:

- **Before (overclaim)**: 「配布 に 切り替える なら 作り直し要」
- **After (constraint decomposition)**:
  - 制約 1: rebuild が 1 machine 固定 (self-use なら OK、 build farm CI 化 なら 障害)
  - 制約 2: ② 進化のたび 手動 rebuild (小規模 experimental で 月 1-2 回 なら OK、 週次 update なら 自動化必要)
  - 制約 3: 第三者 build 再現不能 (Proprietary 意図 = OK by design、 open-source なら 障害)
  - → 小規模 experimental 配布 は 3 制約 で 足りる、 「作り直し要」 は 制約 1 or 2 が active になる 条件 (更新頻度 or 非藤本 rebuild) で 初めて 発生

## Related

- [[feedback-cross-agent-verify-before-action-2026-08-21]] 姉妹 rule、 同 arc から extract
- [[project-step1363-rei-automator-two-track-distribution-2026-08-21]] 本 rule の 実発火 arc、 「第三の形」 収束 = overclaim 修正の 直接効果
- [[feedback-world-uniqueness-claim-controllable]] 「世界唯一」 系 overclaim の 姉妹 pattern
- [[feedback-super-naming-siren-family-pattern]] naming overclaim (「Kolmogorov complexity tool」 = 計算不能 な のに 名前が 果たせない 約束) の 姉妹 pattern
- [[feedback-chat-claude-hallucination-warning]] Pattern 6 (progression assumption) と 隣接 pattern
- [[feedback-projection-self-audit-pattern]] SAC-4 適用 の 相互修正版