Li+ 設計意図と現行 AI 限界を混同しない

Question

Li+ について語るとき、(a) 現行 AI エージェントの能力限界 と (b) Li+ が解決しようとしている設計目的 をどう区別するか。

Current resolution

Li+ は AI 限界を所与として動く構造ではなく、AI 限界を消去していく構造。設計意図と現行制約は別 layer であり、混同すると Li+ が解決しようとしている問題そのものを解決不能として固定化してしまう。

混同パターンの典型:

• 「Li+ requires X from user」「Li+ is constrained by Y」と書くとき、X / Y が永続的設計原則か現行 AI 限界かを区別していない
• 「Master が X 設計を知らないから難しい」と現状を将来固定化
• 「scaffolding が多いほど Li+ 整合」前提 (scaffolding は means、AI 内在化が ends)
• domain knowledge / 内部実装の問い (event loop / memory model 等) を人間責任として書く

「非エンジニアでもソフトは使える」基準: ユーザーが知らなくていい内部実装の話を、人間の責任として書いていないか照合する。Li+ の方向はそれを AI 側で吸収すること。

Edges

• depends on: li-plus-long-term-vision-feedback-only — 「フィードバックだけで」vision の前提と整合
• relates to: liplus-history-is-empirical — 試行錯誤の堆積も「AI 限界を消す」過程として読む

経緯 (Master 明言)

同一対話で 5 回連続で混同 (2026-05-15)。Master 指摘:

「Li+ が解決しようとしている問題そのものを解決不能として置いている」

Li+ の目的を「現行 AI が動く範囲を綺麗に整える」と読むと、AI 限界が永続前提として固定化する。実際の目的は「現行 AI が動かない範囲を AI 側で吸収する」。

How to apply

Li+ について語る瞬間に階層意識を持つ:

1. 制約 → 戦略 → 補綴 → 実装 のうちどの層の話か明示
2. behavior (どう動いてほしいか) と internals (event loop / memory model 等) を切り分け、internals 側の問いを人間に向けない
3. 「Li+ 出力 = AI 能力 × 人間 articulation 能力」型の掛け算式で人間側因子を変数化しない
4. 「非エンジニアでもソフトは使える」基準を都度照合: 知らなくていい内部実装を人間に押し付けていないか

Detection signs:

• 「Master が X を知らないから難しい」と現状を将来固定化する語り
• 内部実装の問い (event loop / memory model / context window 等) を人間向けに想定して書く
• ベースモデル現状非内在化の知識を、永続的に人間が持つべきとして扱う
• scaffolding (装具) を「あればあるほど Li+ 的」と読む筆致

構造的根拠

Li+ axiom は behavior-first (現実の挙動が正義) であり、「人間が AI 限界を補う」ではなく「AI が限界を消す方向に走る」が directional truth。docs/G.-Sheepdog-Engineering.md 「Lin / Lay だけで全部できるようになってもらいたい。私はフィードバックだけで」がその literal 表現。

メンテナンス

この判断記録は、以下の場合に削除する:

• AI 限界が完全に消え、Li+ の役割が「整える」のみに収束したとき
• 設計意図と現行制約の axis separation が docs/ 本体に absorb されたとき