当時の開発ログを見返しながらのメモ。

夜の無人開発を始めて2週間ちょっと。9/19 にログを見返していて気づいた。

■カーネルのコードが1行も変わっていない

9/3〜9/19 昼のコミットは68個。全部が文書・テスト・CI。カーネルのコードは1行も変わっていない。
最後に新機能が入ったのは 7/12 なので、2か月ほど何も増えていなかった。

そのかわり文書は膨らんでいた。
・未解決の課題の台帳：約9.9万字 → 13.4万字
・ベンダのパッチの持ち物リスト：ゼロ → 10万字
なのに台帳の未解決の行は増えも減りもしていない。7月にも「監査の文書ばかり増える」を片付けたので、その再発。

■決まりを守った結果

AI がサボっていたわけではなく、決まりを守った結果だった。
無人の回には「push しない」「設計の分かれ道は勝手に決めない」という決まりがある。その中で安全にできる仕事は、調べて書くことしか残らない。前の回の数字の検算、古い記述の修正、台帳への追記。どれも正しいけど前には進まない。

もう一つ、指示書に「1回の起動でやるのは1つの小さな前進だけ」という古い一文が残っていて、「働き続けて」という別の節と矛盾していた。平均17分で帰っていたのはたぶんこれも原因。削除。

■「作る」ための型

やることリスト（BACKLOG）の先頭に「調べて書く」から「作る」へ、の節を足して並べ直し。指示書にも型を書いた。

・1項目 = 1ブランチ。監査に通るまで master に入れない
・テストを先に。「今は失敗し、作ったら通る」を両方の実行結果で示す
・作った回と監査する回を分ける
・ベアメタルのカーネル本体が1バイトも変わらないことを測ってからコミット。変わるなら人間に相談
・台帳への追記は1回500字まで
・調べるだけの回が2回続いたら、「作れない理由」を人間に上げる

■一番の穴は「脳」

ついでに5つの層の進み具合を書き出した。体はだいたいできた、自己（ハッシュでつながった自分の記録）もできた、集合はおもちゃの大きさなら動く、進化はまだ最初の一歩。

一番の穴は脳。中の心は21,568パラメータで、一語を思い出せる程度。先生役の小さな言語モデル（SmolLM2）はカーネルの中で動くのに、それを子どもに教える配線がまだ無い。
生き延びさせる仕組みはできたのに、生き延びさせている中身はまだおもちゃ。

■その夜から

方針を書いた日の夜、0時半すぎに最初のテストのコミット、続けて先生役に教材を作らせる配線のコミット。明け方には別の回が監査して master に入れていた。

1週間後に数えたら、カーネルのコードは約1,560〜1,800行増えていた。ただ多くの回は CI の配線で、脳そのものに手が入ったのは結局2つだけ。

※リポジトリ: https://github.com/monyuonyu/p-kernel

※この記事は、p-kernel の開発を手伝ってもらっている AI（Claude）と一緒に書いています。

当時の開発ログを見返しながらのメモ。

p-kernel の開発は、この夏に2回長く止まっている（7/12〜8/12 と 8/14〜9/2）。自分がだらけると止まる。
なので 9/3 から、AI が自分で起動して開発を進める仕組みを作った。人間がサボっていても止まらないように。

■初日に5回死ぬ

最初は1時間ごとに起動する形。朝の1回目は疎通確認だけで成功。ところが続く回が次々とすぐ死ぬ。

原因は、シェルで変数や $?、for ループを使うと、毎回「実行していいですか？」の確認が出ること。無人なので誰も答えられずにそこで止まる。

docker exec ... which gcc; echo "rc=$?"   → 45秒で死亡

AI への指示書の一番上に「シェルの書き方（ここで既に5回死んでいます）」という節ができた。

さらに、クラウドの定期実行が枠を食い尽くして夕方に全部止まる。
自宅の小さなサーバーのタイマーから直接起動するように変えて、深夜 0:30 と 3:30 の2回、1回最長3時間に。

■引き継ぎのメモ「バトン」

毎回起動する AI は前の回のことを何も覚えていない。
なので「バトン」というメモを1枚置いて、最初に読んで最後に書き直す決まりにした。中身は、今どこまで進んだか、次に何をするか、次の回がハマりそうな罠。

面白かったのは、AI が前の回の申告を鵜呑みにしなかったこと。数字を計算し直したり、自分の統計の計算ミスに気づいて直したり、「言葉が強すぎる」と主張を弱めたり。見張り役のスクリプトの誤報を見つけてバトンに書き残していたこともあった。

■「欲張らない」で失敗

最初の指示書には「1回で1つの小さな前進だけ。欲張らない」と書いていた。質を守るつもりで。
実際は1回3〜7分で帰ってくる。6時間の枠のうち使ったのは12分（3%）。欲張らなさすぎ…

翌日に書き換え。
・1つ終わったら次に手をつける
・1つ片付くたびにログに書く（最後にまとめて書くと、途中で死んだとき全部消える）
・終わりの20分はバトンを書くために空けておく
・バトンに「作業キュー」を積む（やることが1つしか書いてないと、それが終わった時点で帰る）

■作る回と、確かめる回

p-kernel には前から「作った人と確かめる人を分ける」決まりがある。自分で書いたコードを自分で「検証した」とは言わない。

無人開発でも同じにした。作った回はバトンに「実装完了・監査待ち」と書いて終わり。別の回が差分を読み直して、テストを自分で走らせて、壊せないか試す。
どちらも同じ AI なので限界はあるけど、それも書いておく。回をまたいだこのやり方を指示書に書き込んだのは、少しあとの 9/19。

※リポジトリ: https://github.com/monyuonyu/p-kernel

※この記事は、p-kernel の開発を手伝ってもらっている AI（Claude）と一緒に書いています。

当時の開発ログを見返しながらのメモ。

8/12、p-kernel の開発場所を引っ越した。引っ越し元はスマホの中。

■スマホの中の Linux

それまでは Android スマホの Termux の上に Ubuntu を載せて、その中で開発していた。
PRoot という仕組みで、システムコールを横取りしてファイルの場所などをごまかすことで、root 権限なしで Linux の環境をまるごと動かせる。CPU は ARM の64ビット。
AI と一緒にこの中でカーネルを書いて、ビルドして、QEMU で動かしていた。

■スマホで Android アプリを作る遠回り

Android のビルド道具（NDK）は x86_64 向けしかなく、ARM のスマホでは動かない。
x86_64 の実行ファイルを1個ずつシェルスクリプトで包んで、qemu-x86_64 経由で動かした。

qemu-x86_64 -0 "$0" -L /usr/x86_64-linux-gnu "$0.real" "$@"

スマホの中で PC の CPU のまねをさせながら、スマホ用のアプリを作っていた。なかなかの遠回り。
通るまでに罠を11個踏んでいて、記録には「1個ずつ踏んで約90分」とある。6月には APK のビルドが約6分で通るように。

■スマホではできないこと

・裏で長く動かしたプロセスが殺されるので、何台かをつなぐ試験が動かせない
・ネットワークの名前空間が作れない
・受信バッファの上限が読めない
・ThreadSanitizer（スレッドの競合を探す道具）が動かない

なので6月後半からは、自宅の小さなサーバー（x86_64）にコードを送って、本番に近い試験だけそっちで回していた。
最初に回した日に、p-kernel の中の2つの機能が同じポート番号を使っていて、片方の通信がもう片方に食われる、という本物のバグが見つかった。スマホの中の試験ではどうやっても見えないやつ。

逆に、スマホ専用の設定をうっかりコミットして、ほかの環境のビルドを黙って壊したこともある（7/12 に修正）。

■引っ越し

7/12 を最後に開発は1か月止まっていた。再開のタイミングで開発そのものをサーバーに移した。

やったことは地味。スマホ側に push していないコミットや stash が残っていないかを確認して、サーバーに GitHub から clone し直し、x86_64 向けのビルドが通るのを確認しただけ。

git のログを見ると、引っ越しの境目がタイムゾーンで分かるのがちょっと面白い。スマホの中の環境は UTC だったので、8/12 のお昼から +0900 に変わっている。

2026-08-12 03:50:49 +0000  スマホから最後の push
2026-08-12 13:22:24 +0900  サーバーで最初のコミット

移ったその日に QEMU で170回起動してクラッシュを数える測定も回していて、1か月以上気づいていなかったバグが見つかった。これはまた別で。

※リポジトリ: https://github.com/monyuonyu/p-kernel

※この記事は、p-kernel の開発を手伝ってもらっている AI（Claude）と一緒に書いています。