TL;DR 二か月前、Karpathy autoresearch を「paulkuo.tw のサイト表層ファイルを自動 mutate させる」システムとして具現化したが、七週間後にこのシステムは静かに失効していた。四つの session を跨ぐ三者協議が明かしたのは、個人 IP サイトは fully autonomous self-optimization を追うべきではない、ということ。autoresearch の個人 IP シナリオにおける正しい具現化は、Chat-Cowork-Codex-Code-Paul 五者協議による distributed autoresearch であり、私はずっとそれを implicit に走らせていただけで、まだ名づけていなかったのだ。本記事の執筆プロセスそのものが、その事例の一つである。
2026 年 3 月初め、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 が自分自身を進化させるサイトになる という記事を書いた。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 の観察は鋭い。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 こそが 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 上で補足した 次のレベルの方向性、すなわち 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 行。
前篇 2026 年 3 月 22 日の thesis は「持続的最適化 = 有効 signal と無効 noise を区別する」だった。あの記事の精神は否定していない。今も成立する。ただし成立する範囲は「正しい paradigm を選んだ前提で、方法を最適化する」場合。本記事が言いたいのはもう一段上。paradigm 自体が誤っていれば、方法をいくら最適化しても収束しない。
AI Agents と Agentic AI の進化 を書いたとき、task tool から能動的パートナーへの進化は技術ではなく framing にある、と述べた。振り返ってみれば、五者協議こそが個人 IP シナリオにおける agentic AI の具現化である。一人 × AI でリアルタイム翻訳システムを開発した記録 が記録した協働体験も、同じ paradigm の初期 prototype。当時は自分が distributed autoresearch を走らせているとは気づかず、「AI と一緒に仕事するとスムーズだ」と感じていただけだった。
自律は mutation engine ではない。自律とは判断力である。
七週間の停滞は単なる事故ではなく、ガバナンスの signal である。最も危険なシステムは派手に失敗するシステムではなく、静かに失効していながらあなたに「まだ動いている」と思わせるシステムだ、ということ。
それは私に告げた。自分は autoresearch を走らせていると思っていたが、本当に必要だったのは、自動でサイトを書き換える agent ではなく、異なる agent が互いに校正し、互いの盲点を晒し、最終的に人間が判断を下す協議卓だったのだ、と。


💬 コメント
読み込み中...