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

夜の無人開発は、毎日 0:30 と 3:30 に決め打ちで起動していた。9/23 にこれをやめた。

■やりたかったこと

・いきなり開発を始めるのではなく、「今日は何時と何時に、何をどう進めるか」を計画してから動いてほしい
・週の使用量の枠が余っているなら、90%くらいまでは使い切るつもりで進めてほしい（90%が上限）

■役を2つに分けた

計画役：毎晩23時と、各回が終わるたびに起きる AI。週の使用量、過去7日の回の長さや死に方、バトン、自分からの指示を読んで「何時から何分、何に集中するか」を決める。書けるのは計画だけ。

実行役：5分ごとに動く普通のプログラム。15分ごとに使用量を測って、予定の時刻が来たら開発の回を起動する。

計画には検査も付けていて、回どうしが重なるもの、平日の昼にかかるもの、5分刻みでないものは書けない。

■配分は直線にしない

最初は週の頭から90%に向けてまっすぐ使う「ペース線」を考えていた。
でも平日は自分も同じ枠を使うので、直線だと自分の分が足りなくなる。週の後半ほど多めに使う方がいい。

水曜で50%使っていたら今日は控えめに、週末に40%残っていたら今日はたくさん。この判断を式ではなく、計画役の AI に毎回させることにした。計画には「人間の見込み何%、回せるのは何%、今回何%」を書かせる。ペース線は目安として残しただけ。

■実際の計画

最初の計画は31秒で出てきた。

週56%でペース線47%より9pt先行しているため、今夜は控えめに2回（計約3時間）で監査2本だけ進める。週末（土〜日04:00のリセット前）に残りを使い切る。

回を重ねるうちに、計画役が自分で相場をつかんでいったのが面白い。「今週の夜間開発の実績は約1.7%/時間」「focus を1本に絞った回は安い」。「木曜は人間が枠を使う日だから、今夜はこれ以上走らせない」と引くこともあった。
金曜の夜、83%の時点で「最後の週末なので後ろに寄せる必要はなく、今夜から使う」。土曜の未明には86%で、着地の見込みは89%台。

■初日から上限に当たる

その夜さっそく5時間枠の上限に当たって、23時の計画役が起動失敗。
ただ夕方に立てた計画が残っていたので、実行役は 0:30 に予定どおり開発を起動。ちょうどいい試験になった。
計画役が失敗していたら1時間おきに起こし直す仕組みを追加。

■安全装置は決まりで

ここだけは AI の判断に任せず決まりにしている。
・週90%以上なら起動しない
・93%を超えたら走っている回を止める
・5時間枠が70%を超えていたら待つ
・平日の昼間は起動しない
どれだけ使うかは AI が考えるけど、止める方は決まりどおり。

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

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

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

夜の無人開発を始めて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）と一緒に書いています。