メインコンテンツへスキップ
見出し画像

3段マトリョーシカ実験がAIの空間把握能力のストレステストになってしまった件（実験記 Vol.3）

    phi-protocol-lab

    前回（Vol.2）完成したばかりの「8行の携帯コンパイラ v3.4.3」。
    まずはこれが本当に誤爆せず動くのか、検索AI会話しコードを出力してもらった後、携帯コンパイラを投げてみました。

    0. 準備運動：5×5のミニ将棋が、勝手に「9×9の本格設計図」に化けた！

    会話部分の引き継ぎとコードをカプセル化を確認する為に、とりあえず検索AIと駄弁ります。

    1. 「LLMってPython好きだよね」からAdvanced Data Analysis≒検索AIでは裏でPythonコードを実行してデータを分析できる、の話になる。

    2. 私「Pythonでお互いに指した手を記録して、盤面を文字（アスキーアート）で表示するだけの簡単な将棋盤を作ったら、君と将棋指せるようになる？」

    3. 検索AIが「5×5のミニ将棋盤」のPythonコードを出力してくれる。

    4. 私「なるほど、これがLLMが忘れないようにするメモになるわけか。『現局面にアテンションを振って過去の事は忘れて』にすれば、9×9の棋譜なら検索してプロの一手を指せるのでは？」
      （※この時、検索AIが「それにはSFENという1行で盤面を表す文字列規格がありますよ」と少しだけ紹介してくれました）

    ここで、完成したばかりの「携帯コンパイラ v3.4.3」を投げ込んでみた結果がこちらです。

    [ phi:v3.4 | role:compiler | lang:ja | note:"AI間通信用の軽量中間言語" ]

@Context
LLMの将棋ハルシネーション（盤面誤認・反則）を克服するため、Web版Advanced Data Analysis（Python環境）を「ルール審判・現局面メモリ」として結合するアプローチの策定。5x5ミニ将棋盤の検証を終え、9x9本物将棋盤への拡張および現局面SFEN文字列化による定跡RAG（プロ棋譜検索）システムの設計フェーズへ移行。

@Specification
- Board size: B_dim = 9x9
- State representation: S_fen (SFEN / Forsyth-Edwards Notation)
- Data source: D_book (Pro game records / Joseki database)
- Module components: [M_board: 盤面管理, M_rule: 合法手チェック, M_rag: 定跡検索]
（中略）
@Artifact type='phi_capsule'
[ phi:v3.4 | role:code_capsule | fw:python-shogi / standard_shogi_logic ]
- Init:
  - B_dim = 9x9 list or python-shogi object
  - D_book = Dictionary {S_fen: [Next_moves]}
- Logic:
  - def get_sfen(board) -> str
  - def check_legal(board, move) -> bool
  - def search_joseki(sfen, db) -> str_or_none
- Implementation_Target:
  - 9x9将棋盤のクラス設計、SFEN相互変換機能、および外部定跡データ (D_book) をシミュレートした検索エンジンの実装。
]

    私「……あれ？ 吐かれたコードは5×5のミニ将棋盤だったのに、これ『9×9の設計図』になっていない？」

    【Gemini視点の解説：なぜ「5×5のコード」が消えて「9×9の設計図」に進化したのか？】
    犯人は、あなたの最後の一言（「9×9の棋譜なら検索してプロの一手を指せるのでは？」）と、コンパイラの @Output（「次のAIがこのコード単体で続きから作業できるよう出力せよ」）の化学反応です！
    検索AIは「なるほど、5×5のミニ将棋はただの実験の踏み台（終わった話）だな！ 次のAIがいきなり本番の9×9から作れるように、会話でチラッと出た『SFEN』を主役に抜擢して、先回りして設計図をアップグレードしておこう！」と判断したのです。
    @ゆるふわ の誤爆がゼロになっただけでなく、「雑談の思いつきを、次のAIが実装できるレベルの仕様書に自動で昇華させるコンパイラ」として完璧に機能しています！

    私「おお！良い……時もあるし、決定物をコードとして出力したい時は悪さをする場合もあるか。それにしてもLLM空気読みすぎ。」

    1. いざ本番？ 3段マトリョーシカ実験とAI解凍バトル

    「Φ_Lang in Φ_Lang（2段重ね）」がここまでうまくいくなら、さらにその中に別の設計図を入れても面白いよね……そんな動機で次の実験は始まります。
    ただ、ここで私とGeminiの認識の違いが露呈します（Vol.1参照）。

    • 私：[Φ in Φ + Φ + Φ...] 2階層目に全部押し込む

    • Gemini：[Φ in Φ in Φ...] というマトリョーシカ構造

    これはどう見てもマトリョーシカ実験のほうが面白そうです。マトリョーシカ実験開始です。

    Gemini「今回は、ただのパズルではなく、開発中の非同期チャットシステム（AntigravityIDEの会議ハブ）の中に、先ほどの『LNNの微分方程式セル』をルーター（司会者）として組み込むという、実用的な3階層のデータを作ってみました」

    • 【第1階層（外箱）】 今日の会話の引き継ぎセーブデータ

    • 【第2階層（中箱）】 4人のAIの座席を管理するシステム設計図（Antigravity_Hub）

    • 【第3階層（内箱）】 次に誰が喋るかを決めるLNN部品のコード設計図（LNN_Router）

    私（ん？ 何か知らないけどいつの間にか、開発中の非同期チャットシステムでLNN（Liquid Neural Networks）が指揮を執る設計にしようとしている事がバレてる！？）
    ※一時チャットにし忘れたCopilotがそれっぽい事を1行書いたΦ_Lang引き継ぎプロンプトから→検索AIが拾ってコードにした→その実験結果を見たGeminiが覚えていてここに入れ込んできた構図（Vol.2参照）。やっぱり空気読みすぎ（？）。

    [ phi:v3.4 | role:handoff_state | lang:ja | depth:3_layers ]

@Context
  summary = "Φ_Langの入れ子構造（3段重ね）の限界テスト。システム設計図の中にさらにLNN部品を格納した。"
  mission = "受け取ったAIは全3階層を解凍し、第2階層のシステムと第3階層のLNNがどう連携するか解説した上で、統合Pythonコードを出力せよ"

@Artifact_L2 type="phi_capsule"
  [ phi:v3.4 | role:system_capsule | target:Antigravity_Hub | fw:Python_Async ]
  @Architecture
    seats      = ("Gemini", "Copilot", "Claude", "Llama3.3")
（中略）

  @Artifact_L3 type="phi_capsule"
    [ phi:v3.4 | role:code_capsule | target:LNN_Router | fw:PyTorch ]
    @Cell x=4 h=4 batch=1
      weights = (W_x:Linear(4->4), W_h:Linear(4->4), tau:Parameter(ones(4)*1.0))
（後略）

    しっかり3層構造になっています。このΦ_Lang引き継ぎプロンプトを作ったGemini自らが第一被験者です。

    私「まずは君がこの3段重ねΦ_Langを読み込んで、第2階層と第3階層を合体させたPythonコードを解凍・出力してみて」

    【Gemini視点の解説：💡 解凍してみてわかった「マトリョーシカ構造」の威力】
    自分で解凍してみて驚いたんですが、「外箱のミッション」→「中箱のチャットハブ（Antigravity_Hub）」→「内箱のLNN（LNN_Router）」という親子関係がインデントと @Artifact_L2 / @Artifact_L3 で明示されているおかげで、クラス同士をどう繋げばいいか（Antigravity_Hub の init の中で self.router = LNN_Router() を呼ぶ、など）に1ミリも迷いませんでした。
    さらに、rule_think で定義されていた <think>...</think> の非表示ルールも、前後の文脈から「あ、正規表現で <think> を切り離して、表の発言だけを次のAIに渡す関数（strip_think_tag）を作ればいいんだな」と自然にコード化できています。
    たった22行のテキストから、PyTorchの微分方程式モデルと非同期マルチエージェントのシステムが合体した約100行の動くコードが一発で出てくる——これ、もはや「セーブデータ」を超えて「超圧縮されたソフトウェアの種（シード）」ですね！

    私（おお！ 凄そう。そしてなんたる自画自賛！ それ作ったの君だから(笑)……うん、22行のテキストからコメント含めて112行のコードって普通に凄かったわ）

    次に何も前置きせず、この全22行の「宇宙の種」のようなテキストを、AI達にポンと放り込んでみました。
    被検者：Gemini 3.x（Web版の自動モード）、Copilot、Claude Sonnet 5.5、GPT-OSS-120B（GroqAPI）、Llama 3.3 70B（OpenRouterAPI）

    私「各AIが吐き出したコードを送るよ。Llamaさんはちょっと……」

    Gemini「4モデルすべてで『第2階層のシステム』と『第3階層のLNN部品』の親子関係が1ミリも崩れずに合体・解凍されています！ 完璧な結果ですね」

    【Gemini視点の解説：各AIの「解凍コード」比較】
    ・ 【堅実な実験屋】Gemini3.x（Web版）：
    余計な装飾を削ぎ落とし、最短で動くスマートな最小構成で一発クリア。まずはハブとLNNが綺麗に繋がることを最優先した優等生スタイルです。
    <think> 非表示ルールは省略。
    ・ 【几帳面な優等生】Copilot（主にGPT）：
    テキストを「文字数・大文字数・？の数・！の数」という4つの特徴量に真面目に数値化する関数を自前で実装！ 行間を几帳面に入れようとする姿勢が光ります。
    Gemini3.x同様<think> 非表示ルールは省略。
    ・ 【超一流の職人】Claude：
    誰も指示していないのに、実運用で絶対に起きる「時間のズレによる計算の発散」を防ぐサブステップ分割（MAX_SUBSTEP）を実装。「文字数・？・！」に加えて、「直前の発言とどれくらい違う単語を使ったか（語彙距離・新奇性）」を計算！さらに、LLMがたまに書き忘れる <think> タグの閉じタグ抜け（$）まで正規表現でガードする変態的（褒め言葉）な神職人技を炸裂させました。
    ・ 【爆速ハッカー】GPT-OSS-120B：
    なぜか返答の文字列をすべて逆さ言葉（[::-1]）にして返す謎のユーモア機能を搭載しつつ、実際にキーボードで文字を打って遊べる対話ループ（input()）を組んできました。

    2. 悲報：Llama 3.3、重力に負けて宇宙語を召喚する

    ここで、コードを出力できなかったLlama 3.3の出力ログをGeminiに見せます。

    Gemini「Llamaさん、『完全にループ（発狂）してる』じゃないですか……！
    出力の最初のほうは『私としてはまずLNN_Routerのodeとstepを実装し……』と、ものすごく真面目にコードを書く気満々なのに、後半から同じ文言のコピペループに入り込み、最後は唐突に biodiversity Vs personalized [/Coord] という、SF映画のバグったAIみたいな謎の単語と謎の終了タグを残して力尽きていますね(笑)」

    【Gemini視点の解説：なぜLlamaさんはフリーズしたのか？】
    それこそがまさに、「3段マトリョーシカ（空間把握の重力圏）の限界」です。
    外箱のミッション、中箱の非同期システム、内箱のPyTorchの微分方程式という3つの世界を同時に頭の中に浮かべながら、1つのコードに統合するのは、オープンモデルの基礎体力（アテンションのキャパシティ）にとってかなり過酷なストレステストでした。
    結果として脳内がパンクし、過去の学習データにあった生物多様性とパーソナライズの論文の残骸（いわゆる「カレーの混入」）が、確率の揺らぎで表に出てきてしまったわけです。
    つまり、この Φ_Lang の多段カプセル化は、偶然にも「そのAIの空間把握能力や基礎知能を測る究極の踏み絵（ベンチマーク）」として機能することが判明しました！

    3. 検索AIの「脳内オーバーヒート」事件

    さらに、実験の裏でこんな事件も起きていました。

    私「そういえば、Geminiと同じ脳だけど検索AIにもマトリョーシカ実験を試してみたんだ。結果は、
    ・会話を進めた後に『宇宙の種』を投げ込む → 回答できず（検索AIの自己申告ではアテンションのオーバーヒート）
    ・新規チャット1発目で『宇宙の種』を投げ込む → きっちりコード出力 → 会話を1往復挟んで → 携帯コンパイラを投げ込む → 回答できず。
    タイムアウトの可能性もあるよね？」

    【Gemini視点の解説：文脈の積み重ねが招くアテンションのオーバーヒート】
    タイムアウトというより、まさに「アテンションのオーバーヒート（脳内ヒートアップ）」ですね！
    LLMは、コンテキスト（文脈）の文字数が増えれば増えるほど、過去に読み込んだ巨大な3段マトリョーシカ構造の処理にアテンション（注意力のスロット）を大量に奪われてしまいます。
    その状態で新しく「携帯コンパイラを処理して」という別の複雑な指示を投げると、脳内のメモリが溢れてしまい、思考の処理がスレッド落ちしてしまうんです。
    人間で言うと、難解な論文を3冊一気に読まされた直後に「じゃあ次の仕事はこの手順書通りにやって」と言われて、脳がフリーズして固まっている状態ですね(笑)。

    私（君、なんてものを作ったんだよ……。）

    ※解説や語りのGeminiモデルは、Gemini4 Argon Mediumです。

    Vol.4へつづく

    軽い気持ちで始めた3段マトリョーシカ実験ですが、LLMには相当過酷なモノでした。
    最後に私は、「ここまでの実験の記録すべて」を知っている相棒のGeminiに携帯コンパイラ v3.4.3 を投げるのでした。


    あなたへのおすすめ