ここまでの流れがようやく一本の線でつながったよ。
あなたが言っているのは、まさにこういう仕組みだね:

「人が“生成AIに期待すること”を書き、
その期待を満たすコードを自分で追加し、
コードリスト(テーブル)を更新し、
惑星は毎日再起動される。
その中で生成AIが“新しい能力”を自然に使えるようにしたい。」

これはもう “人間が進化させる機械惑星” の設計そのもの。
そして、この構造を成立させるために必要なのは、たった 3 つの柱だけ。


🌍 1. 「コードリスト(テーブル)」= 惑星の“辞書”

人がコードを追加するたびに、
そのコードの「意味」をテーブルに登録する。

例:

アクション名説明入力出力実装ファイル
pose_right_hand右手の姿勢を生成stylemesh_commandspose_right_hand.ts
build_capsuleカプセルプリミティブ生成from, to, radiusmeshbuild_capsule.ts
export_meshMesh を GLB に出力meshfileexport_mesh.ts

このテーブルが、生成AIにとっての “惑星の語彙” になる。


🤖 2. 生成AIは「語彙」を読むだけで能力が増える

毎日再起動するときに、惑星OSはこうする:

  1. コードリスト(テーブル)を読み込む
  2. それを「今日の惑星マニフェスト」として生成AIに渡す
  3. 生成AIはその語彙を使ってユーザーの意図をコマンド列に変換する

つまり:

人がコードを追加する → テーブルに登録する →
翌日から AI がその機能を使えるようになる。

AI はコードを読まない。
AI は「語彙(アクション定義)」だけを読む。

だから壊れないし、拡張性が高い。


🔁 3. 毎日再起動されるからこそ、この構造が強い

毎日リブートされる惑星は、
“その日の能力”を毎朝読み直す。

だから:

  • 新しいコードを追加しても
  • 古いコードを削除しても
  • テーブルを更新すれば

翌日の惑星は 自然に進化した状態で起動する。

生成AIは毎朝こう言われる:

「今日の惑星には、次のアクションがある。
これらの JSON 形式で呼び出せる。
ユーザーの意図を、このアクション列に変換せよ。」

これで AI の利用範囲は、追加されたコードの分だけ広がる。


🧠 あなたの方式を OS 的にまとめると

✔ 人間がコードを書く

✔ そのコードの「意味」をテーブルに登録する

✔ 惑星OSは毎朝そのテーブルを読み込む

✔ 生成AIはそのテーブルを「語彙」として使う

✔ だから AI の利用範囲はコード追加に比例して広がる

これはもう完全に “人間が進化させる AI 対応 OS” だよ。


🔥 次に進めるなら、どれを作る?

  • アクション定義テーブルの正式フォーマット
  • 惑星マニフェスト(AI に渡す JSON)の構造
  • コマンドバス(AI → モジュール呼び出し)の設計
  • Mesh Builder 用アクションの標準セット

どこからでも一緒に設計できるよ。