設計でどう潰しているか
ai-desk 方法論 — 沖井広行 · 2026-05
この批判は 普通の書き方をしていれば正しい。
では「普通の書き方」をしないと何が起きるか。
AI が壊れるのは AI の限界ではなく、設計が AI 向けじゃないから。
普通の設計原則 (DRY / 抽象化 / カプセル化) は、人間がコードを 読みやすくする ために作られた。AI はそれと逆の最適化を必要とする:
これが Bible §0.0「認知非対称性」。同じコードが、人間には読みにくく、AI には読みやすい。
普通の書き方こそが AI を殺している。
1 つの関数で完結させる。AI が「その関数だけ読めば全部わかる」状態を作る。
機能ごとに大きな関数を作る。データ加工・条件分岐・副作用トリガーを 1 つのスコープに inline する。
200-500 行の関数は問題ない。AI のスポットライトに収まれば良い。短く分割するほど他関数への依存ジャンプが増える。
普通の感覚と真逆。だが 1 関数完結 = 編集の影響範囲が関数内に閉じる。スケールしても他関数を壊さない。
複数の関数から呼ばれる「共通ヘルパー」は作らない。重複を恐れない。
巨大ファイルを「物理分割せず仮想分割」して AI に局所読み込みさせる。
// [ai_s_emblem:#layer Name] でセクション宣言node ai-desk.js file.js skeleton → 全 emblem の目次表示 (数十行)node ai-desk.js file.js focus EmblemName → 該当 emblem だけ抽出node ai-desk.js file.js apply patch.js → 原子的適用 (pre-flight 検証 + tag immutability)データの流れと状態の責任を構造的に分離する。
L1 物理 → L2 意図 → L3 ロジック → L4 描画。データの流れが固定 → どこを編集すれば何に影響するかが構造的に決まる。
L3 だけが REAL_state を更新できる。他層は read only。状態漏れバグが 原理的に発生しない。
派生値は変数に保存しない。生成して即捨てる。「同期漏れ」バグが消える。
層を跨ぐ呼び出しは // [ai_s_bridge:L3toL4] でタグ付け。AI が「ここは認知ジャンプ点」と分かる。
if/else ネストを「全可能世界 → filter」に置き換える。
最小実証: constraint-janken.js — 3 人ジャンケン 27 世界、if 文ゼロ。
実用例: fighter-cancel.test.js — 1920 世界全網羅、1 ファイル。
改修可能性と検証可能性を構造で保証する。
GPU 実装と並走する CPU 純粋関数で計算を検算。バグが出ても「描画のバグか論理のバグか」を断定できる。
状態を上書き保存せず、Command の履歴を JSON で追記。各イベントは前ハッシュを含む直列ハッシュ。改ざん検知が数学的に保証される。
→ 過去のどの時点でも再現可能、改修時に「なぜこの状態になったか」が完全に追える。
規模が大きくなっても 履歴を遡って原因特定できる。
これらは 規模 (ファイル数 / 行数) に依存しない。
10 万行になっても、各数値は変わらない。
普通の codebase だと、これらは全部規模に比例して増える。ai-desk は設計でそれを切断している。
「AI 開発は規模で死ぬ」は、
普通の書き方をした場合の話。
設計を AI 向けに作り直せば、死ぬ理由がなくなる。
Heavy Function · 共有禁止 · Emblem 局所読込 · 4 層 + REAL/SHADOW ·
Constraint Folding · Twin + Event Sourcing
── これらが揃うと、規模はもう破綻原因ではない。
github.com/AoyamaRito/ai-desk
沖井広行 · 蒼山りと