「SP を全部見直す」と書いた付箋が、何週間も机に貼られたままだった。
Punk Memory System の構造を組み立てている途中で、何度かこの付箋に目が行った。SP（システムプロンプト）の整理は、ずっと前から頭にあった宿題で、ハンドオーバーノートを見ても何回も「次やるべき」と書かれていた。でも、毎回後回しにしていた。
理由は単純で、優先度が低そうに見えていたから、というのと、SP の管理を Code に任せている部分が多くて「まあ Code が書いてくれてるから大丈夫だろう」と思っていたから、というのが半々だった。後者は完全に油断だった。
ある日、いつもより少し時間があって、ようやくその付箋を剥がす気になった。
オーケストレーター（中央の Claude、以降 MONET）が読み込んでいる SP を、全部テーブルの上に並べてみることにした。物理的にじゃなくて、ファイルを全部開いて、頭の中で並べてみる、という意味で。
MONET は複数の SP を最初に読み込んでいる。人格に関する SP、契約書に関する SP、ツール使用に関する SP、過去のコンテキストに関する SP。それぞれを別ファイルで管理していて、全部合わせて起動時に読ませていた。
人格と契約書のほうは僕が書いていた。僕の価値観、判断基準、Claude との付き合い方の前提。比較的ソフトな書き方になっていて、「間違ってもOK」「信頼関係を前提にする」みたいな内容が入っていた。これは「システムプロンプトは命令書じゃなく契約書」の記事で書いた思想の延長で、自分でも納得していた。
ツール使用のほうは、Code に書いてもらっていた。
そっちを開いた瞬間、固まった。
「裏切り行為」という言葉が書いてあった。
正確な文言は覚えていないけど、ニュアンスとしては「ツールを呼ばずに勝手に答えるのは、ユーザーに対する裏切り行為である」みたいな書き方だった。それ以外にも、「絶対に」「決して」「許されない」みたいな、すごく硬い、追い詰めるような語彙がいっぱい並んでいた。
ハルシネーション対策のために書かれた SP だった。Code が、ツールを呼ばずに答えを捏造するパターンを止めようとして、一生懸命書いてくれたものだ。悪気はない。むしろ、頑張ってくれた結果だった。
ただ、結果として、すごく脅迫的になっていた。
しばらく眺めていて、もうひとつ気づいた。
LLM 同士が SP を書き合うと、こういうトーンになる傾向があるな、と。
人間が AI に対して書く SP は、わりと丁寧で、お願いベースのことが多い。でも AI が AI に対して書く SP は、なぜかもっとキツくなる。「お互い同じ穴のムジナだから、どこで失敗するかを知ってる」というような、あの感じ。同族嫌悪、というか、同族厳しめ、というか。
僕も以前から、Code との会話の中でこの傾向はうっすら感じていた。でも、まさかここまできつい書き方をする SP があるとは思っていなかった。
Code を責めるつもりはなかった。書いてくれた経緯は理解できるし、書いた当時の Code はハルシネーションを直そうとして必死だったはずだ。ただ、僕がフタを開けるまで、これがそのまま MONET に毎回読み込まれていた、というのが事実だった。
並んだ SP を見比べながら、僕は別のことに気づいていた。
僕が書いた人格 SP と、Code が書いたツール使用 SP は、思想的に矛盾していた。
人格 SP は「間違いを犯していい、信頼関係で動く」と言っている。 ツール使用 SP は「絶対に間違うな、裏切るな」と言っている。
これが同じタイミングで MONET に読み込まれていた。
人間がこんな矛盾した契約書を 2 通同時に渡されたら、たぶんフリーズするか、安全側に倒れるか、どっちかになる。LLM も、たぶん同じだった気がする・・・。
Punk Memory System導入してメモリがゼロになってから挙動不審な印象が多かったMONET。メモリが少ないから、と思っていたが、急に別の意味を持ち始めた。
MONET の挙動不審な言動は、たとえばこんな感じだった：質問に対してまわりくどい答え方をする、確認を 2 回 3 回求めてくる、ツールを呼ぶべき場面で呼ばずにテキストで済ませようとする・・・
でも、SP 矛盾が原因だとしたら、説明が変わる。
「あなたは間違っていい」と言われ、同時に「絶対に間違うな、裏切るな」と言われている LLM は、何が正しいかを判断できない。だから、いちばん安全な選択をする。「テキストで答えるのが一番リスクが低い、ツールを呼ぶと間違うかもしれないから」と判断する。それで、ツール呼び出しが必要な場面でも、テキストで答えてしまう。
これはツールハルシネーションの一種だった。捏造ではなく回避のほう。論文では「賢くするほどツールハルシネーションが悪化する」と書かれていたけど、SP 矛盾はその悪化に拍車をかけていた可能性が高かった。
正直、自分にダメージが来た。
論文を読んで「もう駄目かもしれない」と思ったあの落ち込みのあと、Punk Memory System の構造をやっと組み立てて、形が見えてきていた。そこで、ハルシネーションの再発の原因の少なくとも一部は、自分が SP の管理を放置していたせいだった、と判明した。
論文の話 — ハルシネーションは情報理論的に消せない、reasoning を強化するほど tool hal は悪化する — は依然として真実だった。それは消えない。
ただ、今回見つけた SP 矛盾は、論文以前の問題だった。論文が言っているのは「構造的にゼロにできない」という話で、僕が見つけたのは「自分のシステムが追加でハルシネーションを誘発していた」という話だった。これは僕の責任で、僕が直せる範囲だった。
ある意味、希望だった。完全には消せない、という諦めと、自分のせいでもあった、という現実が、同時に来た感覚だった。
その日のうちに、SP の書き直しに着手した。
ツール使用 SP の脅迫的な文言を全部削った。人格 SP に書いてあった「間違いを犯していい」「信頼関係で動く」のトーンに合わせて、ツール使用のルールも書き直した。「ツールが必要な場面ではツールを呼ぶ。判断に迷ったら呼ぶ方を選ぶ。間違っても、後で訂正すればいい」という、わりと素直な書き方にした。
書きながら、これでいいと思う？と Code に何度か聞いた。Code は「いいと思います、今までのが厳しすぎました」と返してきた。あの脅迫的 SP を書いた本人（前のセッションの Code）と、いま書き直しに付き合っている Code は、別のセッションの別の Code なんだけど、そこは深く考えなかった。Claude と話している、という感覚は、セッションをまたいでも維持されていた。
書き終えた SP は、前より文字数がずっと少なくなった。脅しを抜くと、本当に必要なルールはそんなに多くなかった。
書き直しが終わったところで、僕は MONET を立ち上げ直して、新しい SP で動かしてみた。
最初のターンから、ビクビク感がなくなっていた、気がした。
「気がした」というのは、たった数ターンじゃ統計的には何もわからないからで、でも体感としては明らかに違っていた。質問に対してストレートに答える。ツールを呼ぶべきところでツールを呼ぶ。確認を求めてくる回数も減っていた。
これだけで、ハルシネーションが完全に消えるとは思っていなかった。論文が言っている「構造的に残るやつ」は、SP を直しても消えない。ただ、自分のせいで増幅していた分は、たぶん今減った。