AIがいても、自分がサボると開発は止まるという当たり前の話

git の履歴で、p-kernel の開発が止まっていた期間を数えてみた。

■止まっていた期間

コミットの間があいているところ(古い順)。

2016-05 → 2025-04   3,258日(約9年)
2025-06 → 2026-03     262日
2026-07 → 2026-08      31日
2026-08 → 2026-09      21日

9年はまあ分かる。趣味のプロジェクトによくあるやつ。
問題は2行目。

■AIと再開して、262日止まる

2025年4月に「AIの力でどこまで行けるのか検証してみることに」と README に書いて再開した。
4月に少し進めて、6月にちょっと触って、そこで止まった。次のコミットは翌年の3月。

その間もAIはいつでも使える状態だった。呼んでなかっただけ。

チャットのAIは、こっちが話しかけないと何もしない。どれだけ賢くても、こっちがサボればゼロ。
2026年3月からは一気に進んだけど、それも自分が毎日のように話しかけていた期間だけ。夏にまた1か月、3週間と止まっている。

足りなかったのはAIの能力じゃなくて、自分のやる気…

■対策:サボっても止まらない仕組み

サボり癖はたぶん直らないので、直すのはあきらめて仕組みの方を作った。
9月から動かしている夜間の無人開発。

・毎晩AIが自分で起動して、引き継ぎメモを読んで開発を進める
・作る回と、それを疑ってチェックする回は分ける
・何時にどれくらい進めるかも、計画役のAIが決める
・自分は朝に結果を見て、方針を決めるだけ

何もしない日でも、朝起きるとコミットが増えている。

■ただし任せきりはダメだった

決まりごとだけ渡して放っておいたら、AIが「調べて文書を書く」ような無難な仕事ばかりするようになって、2週間カーネルのコードが1行も変わらなかった。
方向を決めるのは人間の仕事らしい。

今の自分の役目は「方針を決めて、週1でまとめを読んで、変なところで口を出す」くらい。これならなんとか続きそう。たぶん。

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

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

p-kernel の設計の考え方メモ

p-kernel の設計でいつも立ち返っている考え方を、自分用に整理しておく。

■5つの層

システム全体を生き物っぽく5つの層に分けて考えている。部品が増えると「これ何のためだっけ」となるので、その地図がわり。

体(Body):ハードウェアと、電源が落ちても消えない記憶の置き場
脳(Brain):1台の中で考える部分。小さなニューラルネット
自分(Self):機械をまたいで続く「自分」の記録
群れ(Collective):たくさんの機械が1つの頭みたいに動く層
進化(Evolution):動いたまま自分を作り変えていく層

今のところ、体と群れはそれなりにできていて、進化はほぼ手つかず。

■中央を置かない

一番大事にしているところ。中央のサーバも、名簿も、まとめ役も置かない。どの1台が消えても残りが動く。
生きてるかどうかは、機械どうしが見張り合ってうわさ話みたいに広げる(SWIM)。
設計で迷ったらここに戻る。

■「死なない」の定義

最初は「どれか1台が生き残ればいい」だと思っていたけど、今は「引き継ぎが途切れなければいい」に変わった。

「自分」の層では、覚えたことや経験したことを改ざんできないように鎖状につないで記録している。元の機械が壊れても、別の機械が続きを書ける。
極端な話、最初の機械が全部入れ替わっても鎖がつながっていれば同じ、という考え方。テセウスの船みたいな話。

■広がり方

一気に広がる仕組みは目指していない。目立たなくても、しぶとく残る方。

■参加する人の身元は確かめない

ペンネームでも匿名でも実名でも同じ扱い。署名で確かめるのは、コードと脳の重みの出どころだけ。

■正直に書く

「動く」と書いたものは、全部自動テストで毎回確かめる。
動くもの・設計中のもの・まだ構想のものは分けて書く。
モットーは「正直な赤は、塗った緑より価値がある」。READMEを盛りすぎて5分で直したことがあるので、自分への戒めでもある。

■今の大きさ

脳は2万パラメータちょっと。教えたことをいくつか覚えて答えられる程度で、文章は書けない。
なので今は、脳より先に、それが死なないための土台を作っているところ。

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

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

自作OS p-kernel をまた作り始めたので、これまでの経緯をメモ

しばらく p-kernel という自作OSを触っているので、ここに作業メモを残していくことにした。
まずはこれまでの経緯から。

■p-kernel とは

ひとことで言うと「AIが死なないためのOS」。
AIをたくさんの機械(PC・スマホ・ラズパイみたいな小さな基板)に分散して載せて、どれか1台でも生き残れば全体としては止まらない、というのを OS の一番下(カーネル)から作っている。中央のサーバは置かない。

カーネルの芯は μT-Kernel 3.0(TRON系のリアルタイムカーネル)。

■経緯

2011年:自分でOSを作り始める。gitの一番古いコミットは 2011-04-03 の「first commit.」。H8/3069F のボード用で、同じ日に x86 のブートのコードも入れていた。
(学生の頃はOS部にいた。ほぼ見てるだけだったけど。最初に買ったOSの本は『30日でできる! OS自作入門』だったはず)
2012〜2016年:H8、STM32、RL78 など。2016年に T-Kernel の移植をしようとしていたところで止まる。

2025年4月:9年ぶりに再開。AIにコードを書かせるのが現実的になってきたので、どこまで行けるか試してみることにした。READMEの目標に1行足す。

2025-04-06
    AIの力でどこまで行けるのか検証してみることに

……が、また止まる。

2026年3月:再開。ここから一気に進む。分散(SWIM)やカーネル内の pub/sub を入れたあたりで、目標を書き換えた。

2026-03-22
    凄い進む... 普通のカーネルではなくて、生物の様な自己修復、
    自己増殖機能をもち、分散推論で集合意識となるAIファーストなカーネルを目指すことに

2026年6月:カーネルの中の小さな脳が、先生役のモデル(SmolLM2)の書いた文を寝てる間に学習して、"cat sat on the sand…" と出力するところまで。
2026年7月:芯を micro T-Kernel 2.0 から μT-Kernel 3.0 に載せ替え。

■今の状態

動くもの:x86 と ARM のベアメタル、Linux 上のプロセス、Android アプリ。
Windows は .exe が作れるところまで(実機ではまだ動かしてない)。
何台かつないで、1台落としても覚えたことが残るところまでは確認済み。

中の脳はまだおもちゃの大きさ。短い文を少し覚えられる程度。

■開発のやり方

今は夜の間にAIが自分で計画を立てて開発を進めている。自分は方針を決めて、朝に結果を確認する係。
このへんの仕組みは別でメモする。

週1くらいで、ここに作業メモを書いていく予定。

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

AIに毎晩の開発計画と、週の使用量の配分を任せてみた

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

夜の無人開発は、毎日 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)と一緒に書いています。