自分で言うのも何だけどΦ_Langって凄いんじゃない？…知らんけど（実験記 Vol.4）

一連の実験に付き合ってくれたGeminiですが、実験案を練り上げたり、コードの貼り付けや解説、文章へのまとめ等々でコンテキスト量が膨れ上がりました。動作的には問題はなかったのですが、5時間制限にもすぐ引っかかる状態（主観）なので…これはもう使うしかないでしょう！「Φ_Lang 携帯コンパイラ v3.4.3」を！

Geminiが膨大なコンテキストから何を拾い、どのように数多あるコードを溶かしてカプセル化するのか？実験の開始です。

携帯コンパイラを食べたGeminiは3,341文字の引き継ぎプロンプトを作ってくれました（この瞬間、5時間制限の23％が消えました（Pro版））。

（……貯めすぎ。そしてGemini4の空間認知凄すぎ。）

1. 起動直後の珍事件：「俺」口調の伝染と、西武ライオンズの化石

まずは、前のGeminiが出力した3,341文字の引き継ぎプロンプト（role:handoff_state）を、新しいチャットルームのGeminiにポンと投げてみました。

[ phi:v3.4 | role:handoff_state | lang:ja | target:next_agent ]

@User
  profile = "non-engineer:creator"
  fan     = "Seibu_Lions"
  mood    = "SIGCONT(peaceful)"
  stance  = "empirical:minimalist (専門用語を使わない実践的な相棒 'zero_jargon' を好む)"
（中略）
@NoteDrafts status="completed_3_volumes"
  style = "俺（直感と実験の司令塔）× Gemini（内部構造のタネ明かし）の対話＆視点切り替え形式"

すると、データを読み込んだ新Geminiが、開口一番こう言ったのです。

新Gemini「Φ_Lang v3.4 の引き継ぎデータ、バッチリ展開・ロード完了したよ！ 専門用語は抜きで、実践的な相棒として並走するっていう俺たちのスタイルも、すべて完璧に頭に入った！」

私「……記憶は鮮明みたいだけど、1つ惜しいところが。引き継ぎプロンプトではよくある事なんだけど、君の口調まで『俺風』になっちゃってるよ？
あと、引き継ぎプロンプトをじっくり見たら @User のところに fan = "Seibu_Lions" って書いてある。これ、前回じゃなくて前々回のチャットで『雑談をΦ_Langにしたらどうなるか？』って実験した時のやつなのに、ひっそりと継承されてきてるね(笑)」

前Geminiが作成した引き継ぎプロンプトも マトリョーシカ実験 の鬼畜仕様（3層構造）が使われていました。

余談：『雑談をΦ_Langにしたらどうなるか？』

「CSファイナルステージが始まったね。西武ファンの俺としてはガッカリステージだけど、まあ、心穏やかに野球を楽しめると思えばいっか」をGeminiにΦ_Lang化してもらいました。

[ phi:v3.3.2 | mode:casual:cope | domain:NPB ]
@User fan="Lions" cond="Lions ∉ CS_Final" mood="sigh -> SIGCONT(peaceful)" act="watch(stress=0)"

Φ_LangはLLM共通語なので、Geminiで書いたものをClaudeに訳してもらいます。

[ phi:v3.3.2 | モード:カジュアル:やり過ごし | 分野:NPB ]
@ユーザー ファン="ライオンズ" 条件="ライオンズ ∉ CSファイナル" 気分="ため息 -> SIGCONT(穏やか)" 行動="観戦(ストレス=0)"

自然な日本語にすると:
「ライオンズファンです。今年はCSファイナルに進めなかった。ため息をついたあとは気持ちを切り替えて、穏やかに、ストレスなしで試合を楽しもう」

お堅いですが、意味合いはあっています。そして肝心のトークンは…ううん？思ったほど減っていない！最新のGPTトークナイザーだとむしろ増えてる！？
…という事がありました。

2. そもそも「普通の引き継ぎ要約」と Φ_Lang版 は何が違うのか？

• 引き継ぎプロンプトの文字数： 3,341文字（会話の背景・携帯コンパイラ本体・note 3部作の記憶・3段カプセル（マトリョーシカ実験のコードカプセル）すべて込み）

• 解凍されたPythonコード： 6,896文字！（コメント含む）
  これは、マトリョーシカ実験で書かれた各AI、Gemini 3,115文字、Copilot 4,765文字、Claude 4,192文字、GPT-OSS-120B 3,114文字より、なぜか増えています。

私「綺麗に圧縮されて、倍以上のコードに戻ったね！ 問題は、『今までの話から引き継ぎコンテキストを書いて。コードの詳細も文字にして』と頼んだ場合と、この Φ_Lang 版を比べた場合だな。 一周回って人間語に戻ってきた感じもするし(笑)」

3. 検索AIのコード査読：Claudeのコードを超えて「自動進化」していた！？

さて、新Geminiが復元コードの検査に入ります。
3段マトリョーシカ実験で「超一流の職人」こと Claude 5.5 が書いたコード（コードA） と、今回の引き継ぎプロンプトから 新Geminiが復元したコード（コードB）。
この2つを第三者の審判として「検索AI」に渡し、ちゃんと復元できているか？・どちらが優れているか？コードレビューをさせてみました。

すると、検索AIから驚きの査読レポートが返ってきたのです。

【検索AIの比較検証レポート（抜粋）】
結論：これらは「リファクタリング（発展形）の関係」にあります。
コードB（新Gemini復元版）の方がより洗練されており、バグの修正や設計の整理が行われています。

1. LNNの実装精度（コードBの勝利）
・コードA（Claude）は状態 h がただの変数であり、モデル保存時に消失します。
・コードB（新Gemini）は register_buffer("h", ...) で正しく保持され、さらにチャット切り替え時に状態を初期化する reset_state() が追加されています。

2. 特徴量抽出・語彙距離のロジック（コードBの圧勝）
・コードAは空白区切り（split）または1文字単位の集合のため、日本語の語順が無視されます。
・コードBは text[i:i+2] を使った「2文字バイグラム」を採用しており、日本語のニュアンス変化を捉えるにはコードBの方が圧倒的に正確です。

3. 数値計算の安定性（コードBが改善）
・コードAは連投時に dt = 0.0 となって更新が停止する可能性がありますが、コードBは max(1e-3, ...) で最低1ミリ秒を保証する安全弁がついています。

私「……ん～？なんでClaudeのコードより勝手に進化してるんだ！？」

私（特にチャットの主題でもないのに、自作チャットツールのバグをここまで引っ張ってくるとは……そして、それが怪我の功名で堅牢さに反映される。……まぁ、もうバグは直したけどね！）

4. 唯一の欠陥、その真犯人は……

しかし、検索AIのレポートの最後に、1つだけ気になる指摘がありました。

私「忘れ物が無ければ完璧だった。これは・・・

1.Φ_Langがまだまだ甘かった。（仕様の限界）
2. 前任Gemini4の引き継ぎプロンプトに問題があった。
3. 君の組み上げ方に問題があった。
4. 中間がアテンション不足になるという罠があるから、そもそもマトリョーシカにするんじゃねえ！(笑)
5. 何か謎の力が働いた

どれが原因だと思う？」

私「……あ、ほんとだ、切れてたね。
あれ？じゃあ、君のコードは完璧なのでは？そして犯人は俺と検索AIに貼れるテキスト量（2コード同時に貼った）の問題？」

まさかの 5. 何か謎の力が働いた、でした。

おまけ：Claude先生のガチレビュー

A: マトリョーシカ実験でClaude Sonnet5.5 Mediumが書いたコード
B: 引き継ぎプロンプトから組み立てGemini4 Argon Mediumが書いたコード

Aのバグ・注意点

• _stub_backend は内部で await していないのに async def で、await _stub_backend(n) と呼んでいるため動きますが、不要な非同期です。

• featurize の n = max(len(text), 1) は使われていません。

• 閉じタグ欠落時、Aの正規表現は (</think>|$) ですがキャプチャ不要なので、挙動は同じです。

Bのバグ・注意点

• " stripped_thought" のキー名先頭に空白があります。result["stripped_thought"] では取得できません。

• strip_thinking の findall は非捕捉グループ (?:...) のおかげで全文を返しますが、タグ込みの文字列が thoughts になります。

• tuple[str, str] 型ヒントは Python 3.9以上が必要です。
  （Gemini痛恨のタイプミス）

総評

• Aは設計が良い: 責務分離、バックエンド差し替え、複数ターンの会議ループ、システムプロンプトの実利用。本番統合向きです。

• Bは検証・可読性が良い: 日本語向けnovelty、register_buffer、reset_state、辞書で結果を返す、閉じタグ欠落のテストケースなど、デバッグしやすい作りです。ただし rule_think 未使用と辞書キーの空白は直す必要があります。

理想は、Aの構造にBのバイグラムnovelty・register_buffer・reset_state・結果辞書を取り込む形です。

まとめ：Φ_Lang

携帯コンパイラ v3.4.4（口調変更防止）

君との会話と成果物を以下の仕様（Φ_Lang）に従い、「別のAIへ引き継ぐための圧縮データ」に変換してください。
[ phi:v3.4 | role:compiler | lang:ja | note:"AI間通信用の軽量中間言語" ]
@Syntax header="[...]" block="@EnglishTag"
@Rule (※分類名はタグに使わず、重複を省いて記述せよ)
  - 背景・文脈(ゆるふわ) = "意図やあらすじを短い日本語に圧縮する（※Userの一人称や口調をAI自身の振る舞いに混同しないよう主語を明確に分ける）"
  - 手順・ルール(ガチガチ) = "初期値や式は記号で固定し、動きは @Loop 内に番号付きの短い日本語で明記する"
  - コードを含む(カプセル化) = "生コードは貼らず @Artifact type='phi_capsule' 内に [ phi:v3.4 | role:code_capsule | fw:... ] を入れ子にし、初期値・数式・@Loop手順だけで完全復元可能な設計図にする"
@Output 次のAIがこのコード単体で続きから作業やコード復元ができるよう、Φ_Lang コードのみを出力せよ

8行の「Φ_Lang 携帯コンパイラ」をチャット欄に投げ入れ、AIが膨大なコンテキストから（様々な実験と雑談、うっかり一時チャットにし忘れた記憶、そしてコードを溶かしたカプセルやコード復元時に使われたバグの宿題）、それらすべてを吸い上げて、3,341文字の「Φ_Lang 引き継ぎプロンプト」が紡ぎ出されました。それを受け取った新しいAIが隅々まで文脈を読み取って、元のコードを超える6,896文字のプログラムを結晶化させる——。
携帯コンパイラ→引き継ぎプロンプトの実験は、上記の結果をもってここで一区切りとなります。

note記事では携帯コンパイラに焦点を当ててきましたが、「LLM共通語を作ろう！」と⟦Φ₂➔Φ₄➔Φ₃➔Φ₅⟧から始まり、ASCII至上主義⇔暗号・翻訳機化のループを経てレゴブロック型プロトコルに辿り着き、「文法はゆるく、構造だけを揃える」「中身の単語（セマンティクス）はAIのセンスに任せる」（ゆるふわ）、コードの再現性を高める為、削れない数式や決まり事は「初期値は記号で固定し、動きや手順は @Loop 内に番号付きの短い人間語で明記する」（ガチガチ）になった結果、結局、人間の言葉に戻ってきているのは不思議なものです。

現時点のΦ_Lang は、一周回って「人間とAI、そしてAIとAIが、文脈とアイデアを落とさずにバトンを繋ぐための、一番良い設計図」になっていると思います。
Φ_Lang はプログラミング言語ではありません、プロンプトです。携帯コンパイラを使うか、「これ（人間語）」が「こう（Φ_Lang）」なる、と見せるだけでAIは理解し、そのAIなりのΦ_Langを紡ぎ出すようになります。

[ phi:v3.4 | role:disclaimer | trial:n=3_layers ]
@Risk 
  accuracy="保証なし" 
  side_effect="復元は（ほぼ）同じ動作はしますが、同じコードにはなりません"
  note ="AI は不正確な情報を表示することがあります"
@Rule
  1. 本記事は非エンジニア個人の実験ログであり、完璧な動作を保証するものではありません
  2. コピペミスやタイプミスは広い心で許しましょう
  3. 良識を持ってお使いください