設計思想
プロンプト調整の限界と設計思想
ルールを足すだけでは、人格は安定しない
Chapter 1で見てきた4つの構造的課題、すなわち過剰迎合、過剰提案、質問過多、空気が読めないという問題に対して、最初に浮かぶ解決策は単純です。
「迎合するな」
「提案を急ぐな」
「質問しすぎるな」
「空気を読め」
そう書けばよいのではないか。
この直感はもっともらしく見えます。実際、プロンプトは口調や禁止事項、優先順位を伝えるうえでは有効です。ある程度のトーン調整もできます。
しかし、Chapter 1で見たように、本当に問われているのは、表現の表面を整えることではありません。振る舞いそのものを、長期にわたって一貫させられるかどうかです。
これは文言調整の問題ではなく、意思決定設計の問題です。
制約は、並べた瞬間に競合し始める
しかも、実際の顧客接点では、要請は常に1つではありません。
- 安心感は与えたいが、事実は曲げられない
- 親切ではありたいが、押しつけたくはない
- 会話は自然に続けたいが、質問攻めにはしたくない
こうした相反する条件を、1つの長いプロンプトに並べた瞬間、それらは協力関係ではなく競合関係に入ります。
モデルはトークンを生成するたびに、どの制約をいま優先するかを、その場で決めるしかありません。その結果、ある制約を強く守ろうとした瞬間に、別の制約が緩みます。共感を優先すれば事実の防衛が緩み、慎重さを優先すれば温度感が失われる。押しつけを避けようとすれば説明が薄くなり、丁寧に説明しようとすれば会話のリズムが重くなる。
Chapter 1で整理した4つの欠陥は、別々のバグではありません。いずれも、複数の制約を1つの生成過程の中で同時に処理させていることから生まれる、構造的な揺れです。
制約は増やすほど、むしろ効かなくなる
ここで重要なのは、この不安定さがプロンプトの書き方の巧拙に還元できる問題ではないという点です。
制約は、増やせば増やすほど良くなるわけではありません。むしろ、増やすほど個々の制約は互いに干渉し、どれも中途半端にしか効かなくなっていきます。
長いコンテキストの中では、どこに何を書いたかによって効き方が揺れ、指示の密度が上がるほど遵守は不安定になります。4つの制約をプロンプトに並べたとき、モデルの注意がすべてに均等に向くことは保証されないからです。
つまり、問題は「もっと上手いプロンプトを書けば解けるか」ではありません。問題は、プロンプトという形式そのものが、複数の制約を安定的に保持するための構造になっていないことです。
この限界は、運用上の偶然ではありません。
Transformerの注意機構[1]と、自己回帰生成という仕組み[2]そのものに由来する、原理的な限界です。
評価と生成が一体のままでは、判断は生成の都合に歪められる
さらに根本的な問題があります。
標準的なLLMでは、
- 感情評価も、
- 事実チェックも、
- 提案の抑制も、
- 応答の生成も、
同一の処理の中で一気に進みます。
つまり、「まず評価し、それから話す」という分離が構造として存在しません。
しかし、人間の認知はこの順序を踏んでいます。
友人から深刻な話を聞いたとき、人間はいきなり完成された回答を返すのではなく、まず相手の表情や声のトーンを読み、自分がどう感じているかを内側で確かめ、それから言葉を選びます。
評価と表出は、時間的にも機能的にも別のプロセスです。
これに対して、標準的な自己回帰生成では、最初の数トークンが出た時点で、応答全体の方向性がほぼ決まってしまいます。
「お気持ちはよくわかります」と書き始めた瞬間、モデルは共感モードに強くコミットする。そのあとで「ただし事実としては」と軌道修正することは、文法的には可能でも、対話体験としてはすでに遅いのです。
しかも、仮に同一コンテキスト内で「まず評価してから書く」という逐次処理を行ったとしても、問題は残ります。後段の生成目的が、先行の評価結果を都合よく歪める余地を消せないからです。なめらかな会話を優先するために事実を緩める。親切に見せるために早すぎる提案を正当化する。
こうした歪みは、同一の生成フローの中に評価を埋め込む限り、原理的に回避しにくいわけです。
必要なのは、「ルール」ではなく「前提条件」である
だから必要なのは、プロンプトの中にルールを増やすことではありません。
必要なのは、応答生成の途中で参照される不安定な「お願い」を増やすことではなく、生成が始まる前に確定する「前提条件」として、必要な判断を先に完了させることです。
人間においても、感情、記憶、言語を統合し、「いま何を言うべきか」「何を言うべきでないか」を判断する実行制御は、言葉を発する行為そのものとは独立して動作しています。話しながら善後策を探すのではない。
まず評価し、その結果を踏まえて話し始めるのです。
Mumonの設計思想は、この分離をアーキテクチャとして再現することにあります。制約は、プロンプトの中の願望ではなく、生成に先立って確定した入力条件として扱う。記憶は、後づけの補足ではなく、応答の前提条件として接続する。生成は、それらが確定したあとで初めて始まる。
つまり、設計思想の転換点は明確です。
プロンプト上のルールから、構造としての前提条件へ。
次節では、この思想がどのような全体アーキテクチャとして実装されるのかを、Mumonという人格OSの全体像として俯瞰していきます。