自己改修ループ — shirusu が shirusu を作る

更新: 2026-07-03。shirusu 自身の開発を shirusu の write mode で行う運用の記録と手順。

これは何か

shirusu にタスクファイルを渡し、**shirusu 自身のソースコードを AI が直接改修し、
その工程 (勝利条件・破壊レビュー・採点の攻防・変更ファイル・人間の採用判断) が
KOKUIN として自動的に残る**運用。dogfooding の最終形であり、
「説明できないAI活用は、仕事では使えない」を自分自身に適用したもの。

なお、AIラボが安全性の文脈で警戒する「再帰的自己改善」(モデル自身を賢くするループ)
とは別物である。ここでやるのはプロダクトの自己改修で、モデルは変わらない。
品質はレビューゲートが、安全は人間承認の境界が担保する。

実績 (証拠)

2本目の初稿 66 点は標準の合格線 (80) にも届かない水準で、deep の工程
(採点基準への拘束 + 別プロバイダの破壊レビュー) が品質を実際に引き上げたことを示す。
各 run の decision-log に全経緯が残っている。

回し方

# 1. タスクを書く (tasks/xxx.md)。write: true / depth: deep を frontmatter に。
#    「制約」(触ってよい範囲・テスト必須・build通過) と「人間が判断すること」を必ず書く
# 2. 実行
shirusu run tasks/xxx.md --write
# 3. ループを閉じる — 作った機能を、作った本人の次世代ビルドで使って検証
npm run build && node --test test/
# 4. 検収 → /feedback approve|fix → コミットは人間 (または人間の指示を受けたAI) が行う

安全境界と作法

• 確定は人間: コミット・push は AI がやらない。git checkpoint と file_changes が 巻き戻し手段と証跡を保証する
• dist 自己改修の性質: 実行中の shirusu は起動時にメモリへロード済みのため、 作業中に npm run build で dist/ を上書きしても走っている run には影響しない。 新ビルドは次回起動から有効。実行中プロセスの再起動は不要 (タスクにも明記する)
• write run 中に人間がリポジトリを編集しない: 終了時の差分検出が人間の編集を AI の変更として記録してしまう (checkpoint は開始時の dirty は除外するが、 実行中の並行編集は区別できない)
• タスクの完了条件に必ず「build + 全テストパス」を入れる: 検証なき自己改修は 劣化する。これは業界の先行事例が失敗から学んだ共通の教訓でもある

AI 選定の方針 (2026-07-03 決定)

• GLM (GLM Coding Plan) は自己開発機専用。顧客案件を扱うマシンには API キーを 置かない (キーが無ければ glm runner は自動的に無効 = 機械単位の分離)。 理由はデータ境界: 顧客のコード・資料を国外エンドポイントに送らない
• 自己開発機の推奨構成 (config.yml):

models:
  prefer: [glm, claude]   # 物量 (make/revise) は定額の GLM
  avoid: [codex]          # codex は温存 (critique ローテーションでは使われうる)

• 目標形: GLM が手を動かし、claude が計画して壊し、人間が確定する。 破壊レビュー (critique) は生成者と別プロバイダに自動で振られる (同一モデルの自己批判は甘くなるため)
• 順位の変更は感想でなく shirusu stats の evidence (score・リトライ率・人間判断) を見てから行う

なぜ記録つきでやるのか

プロダクトを自分のツールで開発する企業は珍しくない。しかし「AI がなぜその変更を
したか・何点で何が差し戻され・人間が何を採用したか」を監査証跡つきで残す例は
ほとんどない。この記録があるから: 失敗した run も証拠として価値を持ち、
モデルを入れ替えても経緯が引き継がれ、顧客や監査に「AI にどこまで任せているか」を
実物で説明できる。自己改修ループは shirusu の機能デモであると同時に、
思想 (philosophy.md) の実証実験である。