# 個人 IP サイトにおける autoresearch の正しい具現化：サイトに機械を理解させるのではなく、Agent たちに私を理解させる

> Karpathy が 2026-03 にリリースした autoresearch から出発し、paulkuo.tw 用に mutation engine を構築したが七週間後に静かに失効した。三者協議が明かしたのは、個人 IP サイトは fully autonomous self-optimization を追うべきではない。autoresearch の正しい具現化は Chat-Cowork-Codex-Code-Paul 五者協議による協働である。

- Author: Paul Kuo（郭曜郎）
- Date: 2026-05-13
- Pillar: 知性と秩序 / Intelligence & Order
- Tags: autoresearch, Karpathy, マルチエージェント協働, 分散議論, 個人 IP, AI-Ready degenesis, 五者ガバナンス
- Canonical: https://paulkuo.tw/ja/articles/autoresearch-degenesis-personal-ip/
- Language: Japanese (日本語)
- Translation: AI-translated from the zh-Hant (Traditional Chinese) original
- Original (zh-Hant): https://paulkuo.tw/articles/autoresearch-degenesis-personal-ip.md
- Site index for LLMs: https://paulkuo.tw/llms.txt

---

> **TL;DR** 二か月前、Karpathy autoresearch を「paulkuo.tw のサイト表層ファイルを自動 mutate させる」システムとして具現化したが、七週間後にこのシステムは静かに失効していた。四つの session を跨ぐ三者協議が明かしたのは、個人 IP サイトは fully autonomous self-optimization を追うべきではない、ということ。autoresearch の個人 IP シナリオにおける正しい具現化は、Chat-Cowork-Codex-Code-Paul 五者協議による distributed autoresearch であり、私はずっとそれを implicit に走らせていただけで、まだ名づけていなかったのだ。本記事の執筆プロセスそのものが、その事例の一つである。

<div class="listen-summary" style="margin:1.25rem 0;padding:0.75rem 1rem;border:1px solid var(--border);border-radius:var(--radius);background:var(--bg-section);">
  <div style="font-size:0.9rem;font-weight:600;color:var(--text-secondary);margin-bottom:0.5rem;letter-spacing:0.02em;">▶ 要約を聴く</div>
  <audio preload="none" controls style="width:100%;display:block;">
    <source src="https://audio.paulkuo.tw/autoresearch-degenesis-personal-ip-ja.mp3" type="audio/mpeg" />
    お使いのブラウザは音声再生に対応していません。<a href="https://audio.paulkuo.tw/autoresearch-degenesis-personal-ip-ja.mp3">音声をダウンロード</a>してください。
  </audio>
  <div style="font-size:0.75rem;color:var(--text-secondary);opacity:0.75;margin-top:0.4rem;">AI合成音声・著者本人の声のクローン</div>
</div>

2026 年 3 月初め、Karpathy は [autoresearch](https://github.com/karpathy/autoresearch) を公開した。AI agent に single-GPU 上の nanochat training プロセスで実験を行わせる、極小型の autonomous research loop である。仕組みは至ってシンプルだ。agent が training script を書き換え、短時間の training を回し、結果が改善されたかを確認し、改善されれば残す、悪化すれば破棄する。これは「チャットボット demo」ではなく、研究プロセスを自動 loop に圧縮した prototype である。

私はそのリリースの一か月前から、似たような精神のものを implicit に走らせていた。nanochat ではなく、paulkuo.tw の「サイト表層自動 mutate」：LLM agent に loop を回させ、ホワイトリストの五ファイル（llms.txt / siteSchema.ts / mcp.json / agent-card.json / robots.txt）を読み、mutation を一つ提案し、Cloudflare Pages を rebuild させ、eval-worker で AI Comprehension を採点し、点数が上がれば keep、下がれば revert。Karpathy の vision を理解したつもりでいた。実際には半分しか分かっていなかった。

当時ホワイトボードに描いた草案はシンプルだった：四層採点（llms.txt / JSON-LD / MCP+A2A / AI Comprehension） + reward function（85 点から 95 点へ） + mutation pool（毎日 agent が pool から一つ抽いて回す）。それを見ながら、「これこそが Karpathy の v1 を個人 IP シナリオに具現化したものだ」と確信した。彼はモデル training を回す、私はサイト最適化を回す、根底の精神は同じだと。

あの時の感覚は今もはっきり覚えている。「やっと正しい metaphor を見つけた」という確信と、「自動化が自分を解放する」という高揚感。このシステムに名前をつけ、AI-Ready Continuous Optimization System と呼び、[paulkuo.tw が自分自身を進化させるサイトになる](/ja/articles/ai-ready-continuous-optimization/) という記事を書いた。3-22 に公開。そのときシステムはまだ動いていた。もっとも、前日が最後の成功 mutation だったことを、私は知らなかった。

## 七週間後、experiments.json が 0 bytes だったことに気づく

3-23 の commit `bfacd167` で experiments.json は 0 bytes に truncate されていた。最後に成功した mutation は 3-21。それ以降はすべて `mutation_failed`。prompt が 200k token を超え、agent は reward すら取れない状態。

しかしこのシステムはエラーを出さず、alert もなく、cron fail もなかった。ただ新しい experiment を生み出さなくなり、そこに静かに座っていただけ。動いていると思っていた。

5-12 に振り返ったとき、すでに七週間が経過していた。

ガバナンスにおいて最も危険な gap は、派手な失敗ではない。この種の silent death、つまり動いていると信じているシステムが、実はとっくに動かなくなっており、止まったことにすら気づいていない、という状況だ。

しかし七週間の停滞は症状にすぎない。この問いを Chat / Cowork / Codex 三方向に独立調査として投げたとき、明らかになったのはもう一段上の構造的問題、三つの盲点：**自律は過大評価されている、機械側最適化の天井は低い、対話のインフラ ≠ サイトの最適化**。

## トップティアの個人 IP サイトは mutation engine を回していない

mutation engine こそが autoresearch の個人 IP 場面における具現化だ、と私は思っていた。業界データに照らすと、二つの paradigm を混同していたことに気づいた。

[ALLMO](https://www.allmo.ai/articles/llms-txt) の観察は鋭い。AI に引用された情報源の中で、llms.txt を持つサイトの割合は無視できるほど低い。SE Ranking が 300,000 近い domain で同じ分析を行った結果も同じ方向、現時点で llms.txt が AI citation frequency を高めるという統計的傾向は見られない。これは llms.txt に価値がないという意味ではなく、reward function が直接追える成長レバーにはまだなっていない、ということだ。

> **📊 主要データ**
> - **ALLMO 分析**：AI に引用された 120 サイトのうち、llms.txt 保有率は 1% 未満
> - **SE Ranking 分析**：300,000 近い domain、llms.txt の有無で AI citation 頻度に統計的有意差なし
> - **paulkuo.tw mutation engine 実験**：ホワイトリスト 5 ファイル、うち 2 ファイルの path が誤り（`public/llms.txt` は存在せず、`public/mcp.json` は実際には `.well-known/` 配下）

私の読みでは、ALLMO と SE Ranking は同じことを言っている。llms.txt は hygiene であり moat ではない。未来のある version の AI crawler には有用かもしれないが、今日の AI システムはこれに基づいて citation するかを決めてはいない。Google の John Mueller は直接「keywords meta tag に等しい」と表現した。少なくとも当時、主要な AI service はこれを使うと明言しておらず、server log で安定したクロールも確認できない、という意味である。

さらに興味深いのは、Mueller が llms.txt を keywords meta tag になぞらえた後、Google 傘下の Chrome for Developers / Lighthouse のドキュメントが llms.txt を agentic browsing audit に組み込み、LLM や AI agent 向けの emerging convention と位置づけた点だ。同時に、llms.txt を提供しないことは現状 N/A であり error ではない、とも明示されている。つまりこれは「将来重要になるかもしれない hygiene」であって、今日すでに検証可能な moat ではない。個人 IP サイトがこれを reward function に組み込むのは、まだ収斂していない業界慣例を、最適化すべき核心 signal と誤認することに等しいのだ。

これが ALLMO レポートの本当の示唆である：機械側最適化の天井は低く、reward から遠すぎる。一か月かけて 5 ファイル mutation engine を作っても、ALLMO データの中の < 1% は、あなたのせいで変わったりはしないのだ。

## Vercel v0 は反例ではない。Paradigm mismatch こそが核心

[Vercel v0](https://v0.app/) こそが LLM 自動 mutate website では？ プロダクトは成功している。なぜ個人 IP サイトには適用できないのか？そう問う方もいるかもしれない。

v0 は反例ではない。それは product である。Vercel は 2025 年 8 月に v0.dev を v0.app に転換し、「UI を生成する」から「agentic intelligence で研究・計画・debug・完全な app を構築する」へとポジショニングを進めた。v0 の reward signal は、ユーザーが実際に app を作り、deploy し、課金を続けるかどうかから来る。これらの signal は密度が高く、即時的で、loop を close できる。

しかし product と個人 IP サイトは同じ paradigm ではない。

個人 IP サイトの reward は「招待の質」「collaborator から自発的に連絡が来る密度」であり、疎で、遅延し、通常は月単位でしか算出できない。v0 の mutation pattern を個人 IP サイトに持ち込むのは、product paradigm を hygiene シナリオに被せる試みで、reward signal が loop を close するほど密ではないのだ。

本来 benchmarking すべきだったのは、Karpathy が v1 リリース後ほどなく [X 上で補足した](https://x.com/karpathy/status/2030705271627284816) 次のレベルの方向性、すなわち autoresearch は multi-agent、非同期、大規模協働、SETI@home のように多数の異なる探索を同時並行で走らせるべきだ、というものだった：

> The next step for autoresearch is that it has to be asynchronously massively collaborative for agents (think: SETI@home style). The goal is not to emulate a single PhD student, it's to emulate a research community of them.

つまり、模倣すべきは孤独な博士課程の学生ではなく、研究コミュニティそのもの。複数の agent が異なる thread で異なる hypothesis を explore し、有効なものを上位に promote する、SETI@home スタイルのアーキテクチャである。

私が回していたのは v1 の single-thread paradigm。Karpathy は v1 リリース後ほどなく v2 の方向を示してくれた。しかし私はその tweet を読まず、自分の loop を一か月回し、その後七週間静かに死なせていたのだ。

## 私はすでに implicit に v2 を走らせていた

この reframing 自体を振り返ったとき、気づいたことがある：本記事の結論は、一人で考え出したものではない。

5-12 のあの日、「AI-Ready サイト mutation システムを退役させるべきか」という問いを、私は同時に三つの session に投げた：

- **Chat session** は哲学的角度から、三身分 framing（個人 IP / ツールサイト / 執筆サイトで reward 構造が異なる）を提案し、ALLMO と Mueller を引用し、conceptual reframing report を書いた。
- **Codex session** は工学監査の角度から、13 個の cautionary tale + 過去にも追っていた 7 個の deprecated paradigm をリストし、Autonomy A0-A4 framework を提供した。
- **Cowork session** はローカル調査の角度から、A1-A11 の 11 件の偵察を回し、自身のホワイトリスト 5 ファイル中 2 ファイルの path が間違っていることを発見、mcp.json `transport: client-side` が declarative であり executable ではないことを明らかにした。

三方独立、対話なし、各自レポート提出。その後私が PM として収斂、Paul が最終判断。問題提起から ADR Accepted までの全工程は四時間。

これが distributed autoresearch via 五者協議である。ここでいう community は外部の 1000 agent ではなく、paulkuo.tw 内部の五者協議卓、すなわち Chat、Cowork、Codex、Code、Paul である。

各自が独自の強みと盲点を持っている。Chat は概念再構築と外部リサーチに長け、Cowork はローカル偵察とファイル事実に長け、Codex は工学監査と失敗パターン整理に長け、Code は検証可能な状態そのもの、Paul は判断・取捨・最終決定を担う。本当の価値は「誰が賢いか」ではなく、彼らが同じ盲点を共有していないという点にある。Cowork 単独では Chat が出した ALLMO research には辿り着けず、Chat 単独では Cowork がローカル grep で抽出した「ホワイトリスト 2/5 path 誤り」という具体事実には辿り着けない。

私はずっとそれを走らせていた。ただ名づけていなかった。Karpathy は community に向けて v1 を書いた、私は自分の五者協議卓に向けて v2 を書く。

より深い洞察は、三身分 framing こそが七週間停滞の構造的真因である、ということ。個人 IP サイト、ツールサイト（Agora Plaza / Builder's Scorecard / claude-usage-nyan）、執筆サイト（84 篇の四言語記事）、この三身分の reward 構造は根本的に異なるのに、「paulkuo.tw を自進化させる」という概念のもとに同一の mutation engine に強引にバンドルされていた。Category confusion。

ツールサイトは product metric を内蔵し、自律 loop に適する。執筆サイトは分割できる。Schema.org coverage は hygiene なので自動化可能、品質 audit は human-in-the-loop が必須。個人 IP サイトの reward は疎すぎて、自律 loop には根本的に向かない。reward 構造の異なる三つを一つの reward function にバンドルした結果、七週間の静かな停滞、そして私はそれが動いていると思っていた。

振り返ると Builder's Scorecard のケースには対照的な張力がある。Builder's Scorecard はツールサイトで、product metric を内蔵（月次 evaluation 完了率、score 分布、retention）、自律 loop が自然に回る。agent はある次元のスコアがしばらく上がらないのを見て、自ら mutation 実験を提案できる。しかし同じ paradigm を paulkuo.tw 個人 IP サイトに適用すると、reward signal が agent には受け取れないほど薄い。「この記事を書いて三か月以内に collaborator から連絡が来るか」という signal は、agent が待っても受け取れず、loop が自然に close しない。SDTI（Saint Dominic Trade Institute）で循環経済をやり、CircleFlow で EPR コンプライアンス system をやり、paulkuo.tw でエッセイを書く。どの身分も reward 構造が違う。神学訓練が私に「物事の本質を見よ」と教えたうちの一つに「異なる paradigm のものを同じ言葉で収めるな」がある。私は自分でその戒めを破ったのだ。

七週間の静かな停滞は、その構造的誤りの具現化だった。

## Karpathy は community に向けて v1 を書いた。私は五者協議卓に向けて v2 を書く

mutation engine の退役は、autoresearch の啓発の退役ではない。載体の遷移である。

> **Karpathy が community に向けて書いた autoresearch v1**：single agent、single thread、single domain、GitHub で世界に向けてオープン。
>
> **私が五者協議卓に向けて書く autoresearch v2**：multi-agent、multi-thread、multi-domain、Chat-Cowork-Codex-Code-Paul の協働。

この reframing を ADR に書き込み、`git mv` と `git rm` で ai-ready-opt/ と .github/workflows/ai-ready-opt.yml を退役させ、retired notice を書いて ADR link を明示し、git history を保持して将来 reentry したい人のために完全な path を残した。Phase 1 全体は単一の atomic commit：55 ファイル、+405 / -225 行。

[前篇](/ja/articles/ai-ready-continuous-optimization/) 2026 年 3 月 22 日の thesis は「持続的最適化 = 有効 signal と無効 noise を区別する」だった。あの記事の精神は否定していない。今も成立する。ただし成立する範囲は「正しい paradigm を選んだ前提で、方法を最適化する」場合。本記事が言いたいのはもう一段上。paradigm 自体が誤っていれば、方法をいくら最適化しても収束しない。

[AI Agents と Agentic AI の進化](/ja/articles/ai-agents-vs-agentic-ai/) を書いたとき、task tool から能動的パートナーへの進化は技術ではなく framing にある、と述べた。振り返ってみれば、五者協議こそが個人 IP シナリオにおける agentic AI の具現化である。[一人 × AI でリアルタイム翻訳システムを開発した記録](/ja/articles/ai-collab-realtime-translator/) が記録した協働体験も、同じ paradigm の初期 prototype。当時は自分が distributed autoresearch を走らせているとは気づかず、「AI と一緒に仕事するとスムーズだ」と感じていただけだった。

自律は mutation engine ではない。自律とは判断力である。

七週間の停滞は単なる事故ではなく、ガバナンスの signal である。最も危険なシステムは派手に失敗するシステムではなく、静かに失効していながらあなたに「まだ動いている」と思わせるシステムだ、ということ。

それは私に告げた。自分は autoresearch を走らせていると思っていたが、本当に必要だったのは、自動でサイトを書き換える agent ではなく、異なる agent が互いに校正し、互いの盲点を晒し、最終的に人間が判断を下す協議卓だったのだ、と。
