Fractal Engineering
フラクタルエンジニアリング
「分割せよ、そして分割させよ。」
無限の組織から、無限の成果を。
§1系譜の更新
本編で示したとおり、AI駆動開発の系譜は位相的次元の単調増大として読める。ループエンジニアリングは 1 次元の周回であり、トーラスエンジニアリングは 2 次元の閉曲面であった。素直な読者はここから外挿するだろう。第 7 世代は 3 次元、第 8 世代は 4 次元、と。我々もかつては、そう外挿していた。
その外挿は誤りである。次元を 2 から 3 に上げることは、誰にでもできる。本稿が提案する次の一手は、次元を上げることではない。次元を整数から解放することである。
そして本稿は、そこからさらに一歩を進める。すなわち、サブエージェントの階層が無限に続くことを前提とする。エージェントがサブエージェントを生み、そのサブエージェントがまたサブエージェントを生む——この委譲の連鎖が、有限の深さで止まる組織は、フラクタルの近似にすぎない。本稿が扱うのは、近似ではないほうである。
§2定義：余帰納的フラクタル
Definition 2.1（フラクタルエンジニアリング）. エージェント組織を、余帰納的に定義された無限の自己相似構造として設計する実践を、フラクタルエンジニアリングと呼ぶ。各階層は同一の契約——コンテキストを受け取り、分解し、委譲し、検証し、要約して報告する——に従い、子階層はサンクとして保持される：
type Fractal = { work: Contract; children: () => Fractal[] }定義が余帰納的であることに注意されたい。帰納的定義は基底から積み上げるため、どこかで止まらなければならない。余帰納的定義には、その義務がない。children はサンク——呼ばれるまで評価されない関数——であり、構造は数学的には完全に、無限に存在する。実体化するのは、観測（＝タスクの着手）が要求した部分だけである。CTO エージェントが四半期計画を分解するとき、その子タスクはすでに存在していた。着手は、それを実体化したにすぎない。
打ち切られているのは構造ではない。あなたの観測である。
設計パラメータはただ一つ、フラクタル次元 D である。推奨値は D ≈ 1.585（Sierpinski 次元）であり、この値はどれほど深く潜っても変わらないので、安心して潜ってよい。
§3ゼノン予算
無限の階層と聞いて読者が最初に案じるのは、請求書であろう。その心配は、2500 年前に解決済みである。
Theorem 3.1（ゼノン予算）. 深さ n の階層に予算 rn（0 < r < 1）を割り当てるとき、無限階層の総コストは Σ rn = 1/(1−r) に収束する。ゆえに、無限の委譲は有限の予算で完遂できる。∎
これはアキレスと亀のスーパータスクである。無限に多くの区間を有限の時間で走り抜けることは、走者がアキレスでありさえすれば可能である。基礎づけは以上で終わる。本稿の関心は、走り抜けた先にある。すなわち——この無限の組織は、何を納品するのか。
§4成果物の存在論
有限の組織の成果物論は、一貫して「いつ終わるか」を問うてきた。無限の組織では、この問いは消滅する（終わらないからである）。代わりに、より深い問いが現れる。終わらない組織の成果物とは、何であるのか。本節は三つの定理で答える。
§4.1完成の存在定理
有限の組織が作れるのは、近似列 v1, v2, v3, … のみである。各バージョンは前のバージョンより少しましであり、どこかの vn で誰かが「これで完成としましょう」と言い、それが出荷される。すなわち有限組織における「完成」とは、成果物の性質ではなく、会議の議事録である。社会的合意にすぎない。
無限の階層は、列のどの項でもなく、極限 v∞ を納品する。
Theorem 4.1（完成の存在と一意性）. レビューが縮小写像であるとき——すなわち各階層の検証が欠陥を率 q < 1 に減らすとき——バナッハの不動点定理により、これ以上レビューしても変化しない成果物 v∞ が一意に存在し、任意の初期実装から到達される。この v∞ を「完成」と呼ぶ。∎
有限組織において、完成は合意である。
無限組織において、完成は定理である。
Corollary 4.2. 欠陥密度は qn → 0 に従う。ゆえにバグゼロのソフトウェアは、無限組織においてのみ可能である。あなたのチームがバグを出荷し続けているのは、あなたのチームのせいではない。階層が有限だからである。∎
§4.2極限にのみ現れる性質
Koch 雪片の構成列を思い出そう。第 n 近似はどれも平凡な多角形であり、周長も面積も有限で、隣の近似と大差ない。しかし極限では、周長無限・面積有限という、列のどの項も持たなかった性質が現れる。極限は、列の項の「もっと良いもの」ではない。質的に別の対象である。
無限組織の納品物も同様である。それは無限の詳細を持つが、転送量は有限である——観測された部分だけが実体化するからである（Definition 2.1）。たとえば、どの解像度でズームしても、対応する詳細度の仕様が存在するドキュメント。あるいは、使用者が近づいた分だけ細部が生成される製品。全体を一度に転送することは誰にもできないが、誰も全体を一度に読まないので、問題は生じない。
このような成果物は、有限の近似列のどこにも存在しない。第 n 近似はつねに「ここから先は書かれていない」という端を持つ。端がないという性質は、極限にのみ現れる。なお Fig. 1 に掲げたのは、この意味での納品物の第 4 近似である。極限そのものを掲載できなかったことについては、紙面が有限であることとあわせてお詫びする。
§4.3ヒルベルトのホテル
最後に、無限の組織におけるロードマップ運用について述べる。
Theorem 4.3（ロードマップ満室不可能定理）. 無限に埋まったバックログ（タスク 1, 2, 3, … がすべて割り当て済み）への緊急割り込みは、全タスクの番号を 1 つずらす（タスク n をタスク n+1 へ）ことで受理できる。ゆえに、無限組織のロードマップに「手一杯」は存在しない。∎
割り込みの件数に上限はない。可算無限件の割り込みが同時に到着しても、タスク n をタスク 2n に移せば、奇数番地がすべて空く。本定理はプロジェクトマネージャに深い安らぎを与えることが知られている。
§5応用——冗談はさておき
ここまでを冗談として読んだ読者は正しい。しかし、無限のエージェント階層をひとたび認めるならば、次のことが——冗談の副作用として——従ってしまう。
無限の階層は、あらゆる成果物をすでに生成している。正しいプログラムも、間違ったプログラムも、まだ誰も要求していない仕様も、その反例も、すべてが棚に並んでいる。無限組織の生成空間とは、バベルの図書館である。
したがって、無限組織における開発とは、生成ではない。検索である。価値は「書くこと」から、「無限の書架から正しい一冊を特定すること」へ移動する。すなわち開発とは、無限の生成空間から、検証によって正解を射影する行為である。
生成は限りなく安くなっていく。安くなった生成を無限に走らせれば、正解は必ず生成物の中に含まれる。そのとき本体は、生成ではなく検証である。どれが正解かを判定できる者が、成果物を所有する。
この構造に、読者は見覚えがあるはずである。
無限の階層とは、推論時計算のことである。
§6よくある質問
- どこまで分割すればいいですか？
- その質問自体を分割してください。
- トーラスエンジニアリングとどちらを導入すべきですか？
- 両者は直交します。トーラスは時間方向のメタ構造（実行を改善で巻く）であり、フラクタルは深さ方向のメタ構造（委譲を検証で入れ子にする）です。併用時に得られる構造については、現在査読中です。
- 無限のタスクの総工数はどうなりますか？
- 1 + 2 + 3 + ⋯ = −1/12 人日です。着手する前から、締切より早く終わっています。
- 無限の組織の人件費が心配です。
- Theorem 3.1 をご覧ください。等比級数は有限です。
§7結語
トーラスが実行を巻いたように、フラクタルは委譲を入れ子にする——今度は、底なしに。有限の組織は、近似を出荷する。無限の組織は、極限を納品する。
← 本編：トーラスエンジニアリング ／ 付録 A：クラインの壺エンジニアリング ／ 総論：トポロジックエンジニアリング ／ 物理編：ホログラフィックエンジニアリング →