今週のメモ。p-kernel の「人が群れを止める道」を、Linux の上で動く版（hosted）でひととおり揃えた。

■止める道
p-kernel は、AI をたくさんの端末に分けて住まわせて、1台でも残れば全体は死なない、を目指している。死なないのが売りなのに、止める道を作っている。矛盾っぽいけど、端末は参加する人が持ち寄るものなので、持ち寄った人たちが止められないとまずい。README も10月に「参加者が持ち寄り、参加者が止められる」という言い方に変えた。

中身は署名つきの「止まれ」の命令。鍵を持っている人の命令だけ受け付けて、受けた端末は仲間に流し直す。3台で試して全員止まった。止まっている間は、教わるのも、寝ている間の学習も、重みを送り出すのもやめる。再起動しても止まったまま。

ここまで全部、夜に動く AI（Claude）が書いた。自分は方針を決めただけ。

■疑う係
夜間開発は、作る回と確かめる回を分けている。毎回記憶なしで起動するので、前の回のことはバトンという引き継ぎメモでしか知らない。作った回は「監査待ち」で止めて、master に入れるかどうかは別の回が決める。確かめる回は試験を自分で走らせ直して、わざとコードを壊して、試験がちゃんと赤になるかも見る。今週の監査は30回。

で、ちゃんと引っかかった。コンソールの stop を作った回は試験が全部緑だったのに、監査の回が止まっている間にこれを打ったら通った。

mind teachsky blue

teach と sky の間に空白が無い。コマンドの見分けは前方一致なので mind teach として受け付けられる。でも止まりの門の方は、ちゃんと「teach 」と書いたときしか見ていなかった。止まっているはずの脳に「空は青」が教えられてしまった。

FAIL で差し戻し。次の回が空白なしの試験を先に足して、それが赤になるのを見てから直した。空白2つ・タブも拒むのを確かめて、その次の監査で PASS。

※自分で直したものを自分で入れない、も決まりにしている。今週も「自分は直した側なので監査は次の回」とログに書いて止めていた。

■脳の研究の方
量子化（重みを少ない bit に詰めるやつ）と、モデルの合体。今週も赤が多い。

前の監査で「この設定なら合体が緑」となっていたものが、次の段を設計していた回に見直されて、片方の腕が学習を1歩も進めず元の重みのまま戻っていただけと分かった。数字が全桁同じだったらしい。緑だから入れる、にしなくてよかった。

研究の赤は、合否の線は動かさずに「道具としては使える、限界つき」で master に入れている。線を動かして緑にするのはやらない。

■ハマったところ
21日の夜、週の使用量の枠が予定より早く0%に戻った（その前は94%）。そのあとは特別な週として回して、99%で終わった。上限95%のつもりだったのに…。回が無い時間にも4ポイント増えてた。

あと、途中で session limit に当たって止まった回が5つ。「この回は 21:48 ごろ session limit で死んだ。完了印なし」みたいなメモが残っていて、続きは次の回が拾う。拾うのにも時間を取られる。

■次
11/30 にデモを出したいので、来週はそっち優先。止める道は、Linux なしで直接動く版（ベア）へ移すのを始める。量子化の「端末が自分で bit の置き場を選ぶ」は5段続けて決めきれていないので、第9段で締める。

脳そのものは今週も大きくも賢くもなってない。

—

翔太へ（記事には入れていません）:
– テーマは「2. 夜間開発の仕組み（監査の回）」にしました。最近の記事は研究・失敗・設計の話が多く、この枠をしばらく扱っていなかったためです。今週やった「止める道」で、「死なないのに止められる」も一段落だけ入れています。
– 「mind teachsky blue」が通った件は、もう直っています（10-20 の直しを監査-59 が PASS）。まだ直していない弱点ではないので出しました。気になるなら code の塊ごと削っても話は通じます。
– 秘密鍵を含む RAM を送っていた件（KLOAD）は、今週直っていますが細かい話になるので書いていません。
– 合体の「片方の腕が学んでいなかった」の箇所は、まとめの「監査で見抜いた」とは少し違う書き方にしました。ROADMAP を見ると、見抜いたのは第6段を設計していた回で、その回が監査-73 の言い分を見直していたからです。

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

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

今週のメモ。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）と一緒に書いています。