フラクタルエンジニアリングは
何を言い当てたか
AIエージェントを「無限に分割する」風刺から、経営者が持ち帰る4つのルール。これは冗談です。でも、笑われている癖はあなたの会社にもあります。
7章/5表
Contents目次
結論
これは風刺です。サイトの全ページのフッターに「AI駆動開発コミュニティのバズワード文化へのオマージュとして制作されたもの」と書かれています。本文にも「ここまでを冗談として読んだ読者は正しい」とあります。
- ただし、冗談の中に本当のことが一つ入っています。「AIで作るのが安くなるほど、価値は『どれが正解か判定すること』に移る」という指摘です。研究者の議論や論文の数字も、この指摘を支えています。
- 経営者が持ち帰るルールは4つです。階層は2段までにし、予算は案件の総額で切ります。合否は作った者と別の者が決め、お金・対外発信・取り消せない操作は人が承認します。
フラクタルエンジニアリングは、AI論文を装ったパロディです
作者はプログラマーの uhyo 氏で、2026年8月に公開されました
- 作者はプログラマーの uhyo 氏です。コードは GitHub の uhyo/torus-engineering にあり、リポジトリは2026年8月19日に作られました。
- 最初は「トーラスエンジニアリング」というページでした。フラクタル編は翌8月20日、本人のX投稿「今日はClaudeさんに、今流行りのフラクタルエンジニアリングについて説明を書いてもらった(?)」で公開されています。
- 文末の「(?)」は、冗談で書いているという本人からの合図です。
- 9月24日に本人が再告知し、約390いいね・約440ブックマーク・表示3.4万まで伸びました。はてなブックマークはフラクタル編で9件です。
- 反応は「嘘は真顔でつくべきを地で行ってる」のように、風刺として楽しむものが中心でした。本気で導入しようとした投稿は、今回の調査では見つかっていません。
標語と5つの「定理」は、本物の数学を借りた飾りです
サイトの標語は「委譲を入れ子にする——今度は、底なしに」です。AIエージェント(指示を受けて自分で作業を進めるAI)が下のエージェントに仕事を任せ、その下もまた任せていきます。これを無限に続ければ完成品が手に入る、という主張を論文の体裁で書いています。
数学の用語は次のように使われています。どれも本物の数学ですが、会社の運営を保証するものではありません。
- 余帰納的フラクタル(定義2.1): 「下の階層も自分と同じ形」という定義を、終わりを決めずに続ける考え方です。どの階層も同じ形の組織である、というたとえに使っています。
- ゼノン予算(定理3.1): 下に行くほど予算を一定の割合で減らすので、階層を無限に重ねても合計は有限に収まる、という計算です。
- バナッハの不動点定理(定理4.1): 「直すたびに差が縮む」なら、いつか変化しなくなる1つの完成形に必ず行き着く、という数学の定理を借りています。
- 欠陥密度の減衰(系4.2): レビューを重ねるほど欠陥はゼロに近づく、と主張しています。
- ヒルベルトのホテル(定理4.3): 満室のホテルでも、客を一つずつ隣へずらせば無限に泊められるという話です。ここでは「やることが無限にあっても溢れない」という意味で使っています。
ほかに「フラクタル次元1.585」(自己相似の図形の複雑さを表す数で、シェルピンスキーの三角形の値。ここでは冗談の飾りです)も出てきます。締めの一文は「有限の組織は、近似を出荷する。無限の組織は、極限を納品する」です。
笑われているのは、半年ごとに名前が変わる流行です
「◯◯エンジニアリング」は2025年から次々に生まれました
AI開発の世界では、この数年で新しい呼び名が次々に生まれました。下の表は、今回裏取りできた5つです。
| 時期 | 呼び名 | 出どころ | 中身 |
|---|---|---|---|
| 2025年2月 | バイブコーディング | Andrej Karpathy 氏の投稿 | コードを読まず、雰囲気でAIに書かせる |
| 2025年6月 | コンテキストエンジニアリング | Shopify の Tobi Lütke 氏が提起し、Karpathy 氏が広めた | AIに渡す情報全体を設計する |
| 2025年 | エージェンティック・エンジニアリング | Simon Willison 氏らが使用 | AIが編集から実行まで進める開発 |
| 2025年9月 | スペック駆動開発 | GitHub | 先に仕様を書き、AIに実装させる |
| 2026年2月 | ハーネスエンジニアリング | Mitchell Hashimoto 氏のブログ(2月5日) | AIを動かす周辺の仕組みを整える |
この後に「ループ」「グラフ」が続き、サイト自身が「トーラス」「フラクタル」をその次に置いています。名前が半年ごとに入れ替わる流れそのものを笑っています。
揶揄の対象は、万能論・権威づけ・完全自律化の3つです
- 「委譲とレビューを増やせば完成する」という万能論。 AIを何段にも重ねれば、人が関わらなくても品質が上がるという期待です。
- 数学用語による権威づけ。 定理や記号を並べると、根拠があるように見えます。ただ、各定理の前提(レビューは必ず差を縮める、など)は現実の仕事では成り立ちません。
- 人の介入点を消す完全自律化。 人が一度も口を挟まない仕組みを理想とする考え方です。
姉妹ページはもっと直接的です。「毛玉の定理」のページには「介入点を一つも持たない完全自律エージェントには、どの方向にも進めなくなる点が必ず存在する」とあります。別のページには「サブエージェント(親のAIが呼び出す子のAI)を増やしても、成果の情報量は増えない」という系が載っています。
実務のデータも、深い入れ子と自己採点の危うさを示しています
AIは自分の答えを甘く採点する
- Panickssery ほか(2024)は、AIが自分の文章を見分けられるほど、自分の文章を高く評価する傾向を示しました。相関の強さは0.37〜0.41です。
- Huang ほか(2023)では、外から正解を与えずにGPT-4に自己修正を2回させると、算数問題の正答率が95.5%から89.0%に下がりました。見直しの途中で、正しい答えを誤りに書き換えていたことになります。
- Zheng ほか(2023)では、GPT-4は自分の回答を約10%、Claude-v1は約25%高く評価しました。ただし著者自身は、結論を出すにはデータが足りないと書いています。
階層を深くすると、費用と誤りが増える
| 項目 | 内容 |
|---|---|
| Anthropic の公式記事 | 通常のチャットと比べ、エージェント1体で約4倍、複数エージェントで約15倍のトークン(AIが処理する文字量の単位で、費用に直結します)を使います。調査課題では、単体より90.2%良い結果も出ています。 |
| Kim ほか(2025) | 260通りの構成を比べた研究です。エージェント同士が独立に動く型では、誤りが最大17.2倍に増幅しました。中央で管理する型では4.4倍でした。順番に積み上げる推論の仕事では、複数化で成績が39〜70%悪化しています。 |
| Cemri ほか(2025) | 複数エージェントの失敗を14の類型に整理しました。連携の食い違い、検証や終了の失敗などです。 |
| 実務者の実測 | ある開発者が117件の作業記録を測ったところ、子エージェント1体あたり2.63〜9.55ドル、兄弟5体で21.22ドルかかっていました。費用の大半は、各階層が自分でやり取りを繰り返す部分でした。 |
| 暴走の報告 | Claude Code の不具合報告には、子が孫を次々に呼んで48体を超え150万トークン超を使ったものの、役に立ったのは最初の3〜4体だけだった例があります。ほかに、調査用の設定が孫エージェントを生み続け、約80万トークン・27.60ドルを使って成果がほぼ無かった例もあります。 |
主なツールの初期設定では、案件全体の費用は止まりません
| ツール | 階層・回数の上限(既定) | 補足 |
|---|---|---|
| Claude Code | 深さ3(メインの会話の下に3層) | 回数上限と金額上限は、指定しなければ無制限。金額上限は子の費用も合算 |
| Codex(OpenAI) | 深さ1 | 旧方式(V1)のみに効き、新方式(V2)では無視される |
| OpenAI Agents SDK | 繰り返し10回 | 階層の深さに上限は無い |
| LangGraph | 実行ステップ1000回 | 階層ではなく、処理の手数の上限 |
どのツールにも、案件全体の費用で自動停止する設定は初期状態で入っていません。上限は自分で決めて入れます。
「価値は判定に移る」という本音は、研究とも合っています
サイト§5の見出しは「応用——冗談はさておき」で、作者はここで本音を書いています。
「生成は限りなく安くなっていく。…そのとき本体は、生成ではなく検証である。どれが正解かを判定できる者が、成果物を所有する」。
研究にも、この考え方を支える結果があります。
- Verifier's law(2025年7月): 確かめるのが簡単な仕事ほどAIで解けるようになる、という2025年の経験則です。AI研究者の Jason Wei 氏が示しました。答え合わせの仕組みを用意できる仕事ほど、AIに任せやすくなります。
- たくさん作って、別の検証役が選ぶ: Cobbe ほか(2021)では、100個の解答候補から専用に訓練した検証役が選ぶと、算数の正答率が約33%から55%に上がりました。
- 途中を見る検証が強い: Lightman ほか(2023)では、最終答えだけを見る検証役の正答率が63.8%でした。途中の考え方まで一歩ずつ確かめる検証役では72.9%に上がりました。
- 「無限の階層=推論時計算」も実在の研究テーマです。 推論時計算とは、AIに答えを出す段階で多めに考えさせることです。Snell ほか(2024)は、問題の難しさに合わせて考える量を配分すると効率が上がると示しました。ただし「考える量を増やせば必ず良くなる」とは言っていません。
作る作業は安くなりました。安くならないのは「何をもって合格とするか」を決める仕事です。
経営者が決めるのは、段数・総額・判定役・人の承認の4つです
4つのルール
- 階層は2段まで。 「親のAI1体+並列の子」を基本にします。3段目を使うときは、目的・期限・責任者を書いて例外として扱います。
- 予算は階層ごとでなく、案件の総額で切る。 階層ごとに少額を配っても、子の数を掛ければ合計は膨らみます。Claude Code なら
--max-budget-usd(金額上限)と--max-turns(回数上限)を必ず指定します。公開事例では、自動チェック用途で「5回・1ドル」程度に抑える設定が見られます。 - 合否判定は、作った者と別の者に持たせる。 同じAIに見直させると甘くなり、正解を壊すこともあります。判定役にはテスト・一次資料・採点基準を渡します。
- お金・対外発信・取り消せない操作は、人が承認する。 支払い、メールやSNSへの送信、削除などです。このルールに論文の裏付けはありません。会社の統治として決めるものです。
4つのルールは、昔からある組織の知恵と同じです
| 風刺の要素 | 昔からある組織の知恵 | AIでの読み替え |
|---|---|---|
| 無限の入れ子 | 管理の幅(1人が見られる部下の数には限りがある) | 入れ子は2段で止める |
| どの階層も同じ形 | コンウェイの法則(組織の形が成果物の形になる) | 同じ指示を複製すると、誤りも同じ形で増える。役割を分ける |
| レビューで必ず収束 | 検査の分離(作る人と検査する人を分ける) | 生成と判定を別のAIか人にする |
| 介入点ゼロ | 内部統制の承認フロー | 停止・承認・やり直しの場所を先に決める |
貼って使えるチェックリスト
| 確認 | 項目 |
|---|---|
| □ | 階層は2段まで。3段目は例外として記録したか |
| □ | 案件ごとの金額上限と回数上限を設定したか |
| □ | 各AIの役割・権限・受け渡すものを1枚に書いたか |
| □ | 合否を判定するのは、作ったAIと別のAIか人か |
| □ | レビューの回数と締切を先に決めたか |
| □ | お金・対外発信・取り消せない操作に人の承認を入れたか |
| □ | 要約だけでなく、元の資料をたどれるようにしたか |
| □ | 止める方法と元に戻す方法を確認したか |
ミチガエルでは、作るAIと審査するAIを分けています
当社はAIの役割を4層に分けています。判断とまとめを担うメインのAI(脳)、調べ物や確認をする手足のサブエージェント、実装を担当する別のAI、必要なときだけ意見を聞く助言役です。サブエージェントには生の資料を読ませ、脳には要約だけを返させます。
広告コピーや台本などの制作物は、複数のAIに競作させます。審査は作ったモデルとは別の2つのAI(ClaudeとGPTの系列)が行う2人制です。作ったAIに自分の作品を採点させないためです。
お金や外部への送信が絡む操作は、毎回人が確認しています。
出典と確信度
★★★ は一次情報を今回確認したもの、★★ は信頼できる第三者の情報、★ は推測または未確認です。
一次情報(★★★)
- フラクタルエンジニアリング(原典): https://torus-engineering.uhyo.workers.dev/ja/fractal/
- トーラスエンジニアリング(トップ): https://torus-engineering.uhyo.workers.dev/ja/
- GitHub uhyo/torus-engineering: https://github.com/uhyo/torus-engineering
- uhyo 氏 初出投稿(2026-08-20): https://x.com/uhyo_/status/2090237403701412175
- uhyo 氏 再告知(2026-09-24): https://x.com/uhyo_/status/2103138223807733901
- はてなブックマーク(フラクタル編): https://b.hatena.ne.jp/entry/s/torus-engineering.uhyo.workers.dev/ja/fractal/
- Jason Wei「Asymmetry of verification and verifier's law」(2025-07): https://www.jasonwei.net/blog/asymmetry-of-verification-and-verifiers-law
- Anthropic「How we built our multi-agent research system」: https://www.anthropic.com/engineering/multi-agent-research-system
- Claude Code サブエージェント公式: https://code.claude.com/docs/en/sub-agents
- Claude Code CLI リファレンス: https://code.claude.com/docs/en/cli-reference
- Codex 設定(公式コード): https://github.com/openai/codex/blob/main/codex-rs/core/src/config/mod.rs
- OpenAI Agents SDK run リファレンス: https://openai.github.io/openai-agents-python/ref/run/
- LangGraph Graph API: https://docs.langchain.com/oss/python/langgraph/graph-api
- Panickssery ほか 2024: https://arxiv.org/html/2404.13076v1
- Huang ほか 2023: https://arxiv.org/html/2310.01798v1
- Zheng ほか 2023: https://arxiv.org/html/2306.05685v4
- Lightman ほか 2023: https://arxiv.org/html/2305.20050v1
- Cobbe ほか 2021(OpenAI解説経由): https://developers.openai.com/cookbook/articles/techniques_to_improve_reliability
- Cemri ほか 2025: https://arxiv.org/abs/2503.13657v1
- Kim ほか 2025: https://arxiv.org/abs/2512.08296
- Snell ほか 2024: https://arxiv.org/abs/2408.03314
- Mitchell Hashimoto「My AI Adoption Journey」(2026-02-05): https://mitchellh.com/writing/my-ai-adoption-journey
- Claude Code 不具合報告 #68110: https://github.com/anthropics/claude-code/issues/68110
- Claude Code 不具合報告 #69578: https://github.com/anthropics/claude-code/issues/69578
第三者(★★)
- 117件の実測記事(startdebugging.net、2026-09-05): https://startdebugging.net/2026/09/nested-subagent-depth-when-it-helps-and-when-it-burns-tokens/
- CIでの上限設定例(5回・1ドル): https://agentpatterns.ai/workflows/headless-claude-ci/
- Context Engineering の提起(Tobi Lütke 氏): https://x.com/tobi/status/1935533422589399127
- 同(Karpathy 氏): https://x.com/karpathy/status/1937902205765607626
- Loop Engineering の整理論文(arXiv 2608.21884): https://arxiv.org/html/2608.21884
- 組織論(管理の幅・コンウェイの法則・検査分離・内部統制): 一般知識に基づく対応づけ
推測・未確認(★)
- 本気で受け取った反応の有無: 見つからなかったが、非公開の場まで調べたわけではない
- YouTube 動画の「3層を超えると意味をなさない」という発言: 文字起こし未確認のため本文では使っていない
- 「階層は2段が最適」という数値的な裏付け: 深さ別の成功率を比べた研究は見つかっていない。ルール1は費用と誤りのデータからの判断
- OpenAI の Harness Engineering 公式記事(2026-02): 本文を取得できず未確認
How this article was made
この記事の作り方
- 複数のAI(GPT・Grok・DeepSeek)に役割を分けて、3ラウンドで調査しました。
- 引用した出典は、調査したAIとは別のAIが全件開いて実在と数字を確認し、合わない数字は捨てるか訂正しました。
- 最後に、原典サイトと著者の投稿を直接読んで確かめています。