今週のメモ。p-kernel の脳の成績が、ちょっと水増しされていたことが分かった。

■確かめ用データがかぶっていた

p-kernel の中で育てている小さな言語モデル（ログでは「赤子」）は、学習に使う文と、成績を測る確かめ用の文を分けている。確かめ用は学習で見せない、という約束。

この約束を機械で確かめる試験を夜間開発に作らせたら、いきなり赤だった。確かめ用の文を16バイトずつ170片に切ると、そのうち108片が学習用の文と同じだった。

原因は詰め物。確かめ用の文を1280バイトにそろえるために後ろを埋めていた文が、学習用と同じものだった。成績の大半は、見たことのある文の丸暗記で出ていたことになる。

直して測り直した。

確かめ用の損失（小さいほど良い。でたらめだと 5.545）
直す前:  学習前 5.50 → 学習後 2.89
直した後: 学習前 5.52 → 学習後 7.29

損失はざっくり「次の1文字の当てにくさ」。直した後は、学習するとでたらめより悪くなる。

先生役のノードが生きたまま教える試験（cradle_live）も、直した教材だと赤。教えた方が 4.38、教えなかった方が 2.87 で、教えると見たことの無い文では悪くなる。

これまで「教えると良くなる」と書いていたのは、丸暗記込みの話だった。README（3か国語）も赤と書き直した。
※脳はまだおもちゃの大きさ。賢くするのはこれから。

■KLOAD の穴を閉じた

KLOAD は、ネットワーク越しにカーネルを配る仕組み。調べたら、ビーコン（「ここにいるよ」の合図）を1つ送るだけで、知らない相手にも RAM を16MB丸ごと送っていた。中にはノードの秘密鍵も入っていた。鍵ごと。

起動したときは閉じていて、コンソールで kload と打ったときだけ開くようにした。ベアメタルの機械語が変わるので、基準（crown）を取り直してから master へ入れた。

■週の枠に当たって3日止まった

夜間開発は、自宅の小さなサーバー（ノートPC）で、夜に Claude を起動して回している。毎回記憶なしで起きるので、バトンという引き継ぎメモを読んでから始める。いつ何分走るかは計画役が決めて、起動するかどうかは実行役が週の使用量を見て決める。

その週の使用量が 100% に当たった。上限は 90% に決めてあったのに。それで 10-15 の朝から、枠が戻る 10-18 の4時まで、回がゼロだった。

止まっている間の実行役の記録はこんな感じ。

01:15 計画役が失敗したままだったので、起こし直した
01:30 1018-0030 を見送った（週の枠が 100%（上限 90%））
02:15 計画役が失敗したままだったので、起こし直した

計画役も枠のせいで動けないのに、1時間ごとに起こしては失敗していた。律儀。

枠が戻った4時の回は、マージした後に CI（push のたびに走る自動の試験）が赤くなっていた原因を突き止めて、直すところまでやった。ただ、直した回ではマージしない決まりになっている（作った回と確かめる回を分ける）。なので CI は次の回の確かめ待ちで止まったまま。決まりを破れば1日早く進むけど、そこは守らせている。

■次

まず CI の赤を解く。そのあと、11/30 に出したいデモのために「1台消えても覚えたことが残るか」の曲線を取る。小さい版では、記録の生き残りが素の版で 1.0、わざと壊した版で 0.5 だった。ただ、思い出すときに別の鍵の値を返す失敗が混ざっていて、まだ分けきれていない。

脳の物差し（学習にも選ぶのにも使わない、独立な確かめ用データ）もまだ手つかず。研究は今週1日しか進まなかったので、来週は週2回以上やりたい。

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

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

今週のメモ。夜間開発が作っている「約束ごとの試験」から、本物のバグが1つ出てきた。

■約束ごとの試験
p-kernel の芯は μT-Kernel 3.0（TRON の流れのリアルタイムOS）。この上にいろいろ載せているので、「タスクを作ったら動く」「待ったら起きる」のようなカーネルの約束を1個ずつ確かめる試験を、夜間開発に作らせている。
わざと壊したカーネルも用意して、試験がちゃんと赤を出すかも見ている。壊したのに緑なら、その試験は何も見ていないことになるので。

今週は可変長メモリプール（大きさがばらばらのメモリを貸し出す仕組み）の項目を足した。これで 133 項目、壊したカーネルは 14 種。

■足したら落ちた
足したとたん、64ビットの環境だけ tk_cre_mpl（メモリプールを作る呼び出し）でカーネルごと落ちた。32ビットの x86 は 133 項目ぜんぶ通る。

原因は構造体の並びだった。メモリプールの管理ブロックの途中を、別の構造体の先頭として読んでいる箇所がある。向こうの構造体は、64ビットだと途中に4バイトの詰め物が入る。こっちには入っていなかった。それで、空き領域をたどるたびに4バイトずれた場所を読んでいた…

mplsz   +36
areaque +40   ← 本当は mplsz から +8 のはず

32ビットでは詰め物が入らないので、元の並びで合っていた。64ビットに移したときに、並びを直し忘れていたっぽい。
直し方はメンバーを1つ前に移すだけ。ついでに、並びがまたずれたらビルドが通らないようにする検査も足した。

これまで見つからなかったのは、64ビット側にこれを呼んでいる所が無かったから。Linux 版や Android 版で、誰かが呼んだ瞬間に落ちる状態だった。(まだ誰も踏んでいない)

■赤のほうがありがたい
このプロジェクトでは「正直な赤は、塗った緑より価値がある」と決めている。試験を増やせば赤も増えるので、見た目は後退しているように見える。ただ今回の赤は、試験を増やさなければ見えなかったもの。

脳のほうも赤が多い週だった。1ビットに量子化して誤差を次に回すやつは 0/3 で赤。そのうえ、間違った作りでも正答率の合格ラインを通ってしまうことが分かった。甘かったのは合格ラインのほう。次の段では「写しのずれ」もラインに入れる。
※緑のままだったら、気づかずに先へ進んでいた。

■ほか
長く回るタスクで切り替わらない問題の続き。Linux の x86_64 と aarch64（Android の中身）でも、割込みの出口でタスクを切り替えられるようにした。

学習の後半の重みを平均するだけで、種7つすべてで少し良くなった。動いている脳を実際に良くできそうな最初の候補。監査待ちなので、まだ既定は OFF。

夜間開発は 10/8 の夜から 10/11 の朝まで止まっていた。週の使用量の枠を、自分が木曜・金曜に使いすぎて上限を超えたため。

■次
mind/hist（「1つの心」の中心の部分）と、重みの平均が長く動かしても効くかを測るところ。

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

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

p-kernel の中では小さな言語モデルを育てていて、ログでは「赤子」と呼んでいる。行列の重みが190万個くらいで、fp32 で7.6MB。脳と呼ぶにはおもちゃの大きさです。

これを賢くする方向の研究も、夜間開発に少しずつやらせている。順番はだいたい決まっていて、論文を原文で読んでメモにする → p-kernel のどこに入れるか決める → 「効いた」と言える条件を先に決めてから測る、の流れ。今週はこの結果がいくつか出たのでメモしておく。

■量子化
重みの桁を減らしてモデルを小さくするやつ。量子化のホワイトペーパー、GPTQ、LLM.int8()、AWQ あたりを読んだ。論文から拾ったのは「目盛りを行ごとに取るか全体で取るかが一番効く」「小さいモデルほど壊れやすい」の2つ。

赤子で試した結果。元の損失 3.2258 からどれだけ増えたか。

int8 行ごと     +0.0003
int4 行ごと     -0.0213
int2 32個ごと   +0.0912
int2 行列全体   +1.3948

int8 だとほぼ変わらなくて、2bit で行列全体を1つの目盛りにすると壊れる。ここまでは論文どおり。

int4 で損失が下がっていたので、最初は「量子化したらかえって良くなった」と書いていた。これが監査で崩れた。乱数の種や学習データを変えると -0.021 から +0.017 まで符号が変わる。ただの雑音の幅でした。

※夜間開発では、作った回と別の回が監査する決まりにしている。疑う役がいなかったら、これがそのまま成果として残っていたはず。

■合体
2つのモデルの重みを平均して1つにする話。群れの端末がそれぞれ学んだことを1つにまとめたいので、p-kernel にとっては大事なところ。Sakana AI の進化的な合体、TIES、DARE、それと Linear Mode Connectivity の論文を読んだ。

最後の論文によると、同じ出発点から別々に学習した2体を直線で結ぶと、途中で損失の山ができる。ただ、学習率を途中で下げていけば、早めに分かれた2体なら山は消えるらしい。

第1段では、赤子の2体のあいだにもやっぱり山があった(0.375)。第2段で学習率の計画だけ変えてみたら、山はかえって高くなった(0.42〜0.70)。消えた組もあるにはあったけど、2体がほとんど動いていない組だけ。離れたまま平均できる組はひとつも無かった。

なので「そのまま重みを平均する」道はここで閉じた。次は蒸留(重みではなく出力で知識を渡すやり方)にする予定。監査では「データ1つ・種1つでしか測っていない」と結論の書き方を狭められた。重みの並びを揃えてから平均する re-basin はまだ試していない。

■副産物
同じ実験で、学習率を下げていくと親そのものの損失が 2.19 → 1.43 に下がった。合体とは関係ないところで、今週いちばん良い数字が出ている…。今の赤子はどこも学習率が一定なので効くかもしれない。でも小さいデータだけの話かもしれないので、確かめるまでは保留。

■10/4 に読んだもの
BitDelta と DARE。群れで共有している重みは、今は世代ごとに全部送っている。でも受け手は前の世代を持っているので、差分だけ送れば足りる。差分を行列ごとに「符号1ビット＋大きさ1個」にすると、86KB が 2.7KB くらいになる見込み。
DARE の論文によると、差が小さいときしか効かない。なのでまず差の大きさを測るところから。実装はまだ。

■ほか
RNG0 を、ベアメタルの x86 と AArch64 で直した。カーネルを呼ばずに回り続けるタスクがいると、ほかのタスクに切り替わらない不具合。Linux の上で動く版も作ったけど、途中で原因を2回取り違えて、結局スタックが128バイトずれていただけ。自分のバグでした。これは監査待ち。

週の使用量の枠は98%で締まって、9/30〜10/3 は夜間開発がほぼ止まっていた。

「小さいモデルが賢くなった」という結果は、まだひとつも出ていない。丸暗記しているだけか、本当に覚えたかを見分ける試験も、2週続けて手つかずのまま。

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

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

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 の設計でいつも立ち返っている考え方を、自分用に整理しておく。

■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）と一緒に書いています。