見過ごされてきた中核的な矛盾

AIエンジニアリングにしばらく携わっていると、断片的な「経験則」を数多く集めているはずです。Chain of Thoughtは推論能力を高める、promptが長すぎるとモデルは重要な情報を見落とす、few-shotの例は一貫したstyleにする必要がある、長い対話ではモデルの「性格」がdriftする、モデルは時に自信を持って事実を捏造する、といったものです。これらの現象は互いに独立し、それぞれ異なる原因と対策を持つように見えます。

しかし、実際はそうではありません。この五つの現象と、実務で現れるさらに多くの変形は、同じ仕組みが異なる側面に現れたもの です。その仕組みを理解すると、ばらばらだった経験則が突然、一枚の明確な図としてつながります。この記事では、その「万能の鍵」を渡し、鍵を使って五つの扉を開きます。

鍵の中核にあるのは、私が「モデルの内面と口の非対称性」と呼ぶ現象です。まずは最小限の説明で、この概念を組み立てます。

鍵の形：Hidden StateとTokenの帯域幅の隔たり

モデルが一文を処理するとき、内部の「思考」はすべて高次元のvector空間で行われます。具体的には、Transformerの各層が各位置でhidden stateというvectorを保持します。典型的な次元数は4,096または8,192です。このvectorがモデルの「内面」を担う本体です。現在位置に対する完全な理解、つまり意味、context、考えられる選択肢、styleの傾向、確信度など、絡み合ったあらゆる情報が含まれます。

概算すると、4,096次元のhidden state vectorは、各次元を8bitだけで表現しても、32,768bitの情報容量を持ちます。64×64の小さなgray scale画像に含まれる全pixel情報に相当します。これがモデルの「内面」が持つ実際の帯域幅です。

次に、モデルの「口」を見ます。モデルが一つのtokenを出力するとき、語彙から一つを選ばなければなりません。語彙数が12万なら、この選択の情報量はlog₂(120000) ≈ 17bitです。5桁の暗証番号を当てるために必要な情報量とほぼ同じです。

二つの数値を並べると、驚くべき事実が見えます。モデルの内面の帯域幅は32,768bit規模、口の帯域幅は17bit規模で、両者には約2,000倍の差があります。 tokenを一つ生成するたび、モデルは内部の高精細な「小さな画像」を、低解像度の「5桁の暗証番号」へ圧縮して外へ送らなければなりません。

これがLLMエンジニアリングの中核的な対立です。モデルの内面は高次元で豊かですが、口は低次元で狭く、現在のアーキテクチャではすべての思考が口というbottleneckを通って伝わります。 この鍵を手にすると、LLMエンジニアリングで神秘的に見えた多くの現象が正体を現します。扉を開き始めましょう。

第1の扉：Chain of Thoughtが有効な理由

Chain of Thought（CoT）は、prompt engineeringで最も有名な技法の一つです。方法は非常に単純です。モデルに回答を直接出させず、先に推論過程を出力させてから回答させます。多くのタスクで精度が大幅に高まり、ときには20percentage pointも改善します。

しかし、この現象の奇妙さを一度考えてください。モデル自身の能力はまったく変わっていません。 parameterもアーキテクチャも訓練も同じです。promptへ「一段階ずつ考えよう」と一文追加しただけで、精度が大幅に上がります。この「追加能力」はどこから現れたのでしょうか。

直感だけで答えるなら、「推論過程を先に書くと、モデルがより明確に考えられるから」と言うでしょう。この答えは間違いではありませんが、CoTを魔法として扱い、仕組みを説明していません。私たちの鍵を使えば、より深い説明ができます。

モデルが直接回答するときは、一回の完全なforward passの中で すべての推論を終える必要があります。たとえば固定された80層のTransformerという計算予算内で、問題を理解し、計算を終え、回答を直接出力しなければなりません。問題が単純なら十分ですが、複数段階の推論が必要なら計算量が足りません。

一方、先にCoTを出力すると、興味深いことが起きます。「まず既知の条件を列挙しよう」という文を生成するために一回の完全なforward passを使い、「これらの条件から推論できる」を生成するために別の完全なforward passを使います。このように続きます。CoT全体で100tokenを出力したなら、モデルは実質的に 100回の完全なforward pass を経験し、直接回答する一回の100倍の総計算量を使います。

したがって、CoTが本当に行うのは、モデルへ「思考方法」を教えることではなく、一回のforward passを大きく超える総計算予算を与えること です。複雑な問題を複数段階へ分け、各段階を完全なforward pass一回で処理できます。各段階は依然としてtokenという17bitの狭い出口を通りますが、数十から数百段階を積み重ねれば、複雑な問題を解くために十分な総情報量になります。

CoTが単純な問題ではあまり役立たず、一回のforward passでは足りない複数段階の推論で大きな効果を持つ理由はここにあります。CoTには隠れたコストもあります。大量のtokenを消費し、レイテンシと費用が高くなります。CoTの本質は、token数を計算量へ交換すること です。ただし交換が暗黙的なため、無料の利益に見えます。

この点を理解すると、thinking model世代の設計も明確になります。CoTを「prompt engineeringで選べる技法」から、「モデルに組み込まれた振る舞い」へ昇格させています。モデルがthinkingの要否、量、停止時期を自動で判断します。ただし、低レベルの仕組みは同じです。複数段階のforward passを蓄積して一段階の計算量制約を突破し、その代わり各段階をtokenの狭い出口でつなぎます。

第2の扉：Promptの長さのsweet spot

Promptの書き方について、詳しく、具体的に、例を与え、roleを明示すべきだという助言を聞いたことがあるでしょう。これらは「promptを長くすべき」と示唆します。一方で、簡潔に、焦点を絞り、情報を詰めすぎないようにするという助言もあります。こちらは「promptを短くすべき」と示唆します。どちらが正しいのでしょうか。

答えは非常に具体的で、私たちの鍵を使えば明確に説明できます。

モデルへpromptを与えると、まず全体をembeddingでhidden stateの系列へ変換します。attentionの仕組みによって、すべての位置のhidden stateが互いに影響し、最後の位置にはprompt全体の情報を統合したhidden stateが形成されます。この最終hidden stateが、最初の出力tokenを生成するときのモデルの「心境」を決めます。

Promptが短いと、この最終hidden stateは「まとまりに欠ける」場合があります。情報が少なすぎるため、何をすべきか、どのstyleを使うか、どの方向へ進むかをモデルが確定できず、内部状態が複数の可能性に分散します。この状態から生成した出力は、一般的で焦点に欠ける傾向があります。

Promptが適切な長さまで増えると、具体的な指示、例、制約が、モデルの内部状態を徐々に「形作ります」。最終hidden stateは 明確で焦点の合った状態 になります。モデルは、求められるもの、求められないもの、使うtoneを理解します。この状態からの出力は目的に合い、品質が高くなります。これがprompt engineeringの実際の仕組みです。token入力を使ってモデル内部のhidden stateを彫刻し、高次元vectorを高品質な出力を生む位置へ収束させます。

しかし、promptをさらに長くすると問題が生じます。Attentionは保存される資源です。softmaxによってすべてのattention weightの合計は1になるため、contextが長いほど各tokenが得る注意の割合は薄くなります。つまり、すでに十分明確なpromptへ情報を加え続けると、内部状態をさらに絞るのではなく、各情報が最終hidden stateへ伝える強度を希釈します。 中核的な指示の「声」が副次的な情報に埋もれ、明確に説明したつもりの内容をモデルが無視し始めます。

これがpromptの長さにsweet spotがある理由です。短すぎると内部状態を十分に形作れず、分散しすぎます。長すぎると重要なsignalが副次的な情報に埋もれます。中間に最適な範囲があります。その位置はモデルとタスクごとに異なりますが、見つけることはprompt engineerの中核的な仕事の一つです。

この理解によって、promptの内容を削除すると、かえって結果が良くなることがある という一見矛盾した現象を説明できます。「モデルにその情報が不要」という意味ではなく、「その情報が、より重要な情報を希釈している」という意味です。優れたprompt engineeringは内容を追加し続けることではなく、各情報の価値と希釈コストを比較することです。

第3の扉：Few-shot例の本当の役割

同じ鍵を使い続けます。Few-shot prompting、つまりprompt内で複数の入出力例をモデルへ与える方法も広く使われています。直感的には「例を通じて、モデルに何をすべきか教える」と説明します。CoTと同じく、間違いではありませんが、仕組みを明らかにしていません。

鍵を使って見直します。Few-shot例を与えると、「入力」部分が一連のhidden stateへ変わり、「出力」部分も一連のhidden stateへ変わります。両者の対応関係 を、モデルがattentionによって内部で「感知」します。この対応は、「一つの規則を学んだ」と明示的に抽出されるのではなく、次に似た入力を処理する際のhidden stateへ直接biasを与えます。

より具体的には、複数のexampleの後で実際の入力を与えると、最終hidden stateはすでに exampleの出力styleに近い方向 へ引っ張られています。vector空間での「anchoring」です。例が多く、一貫しているほど、モデルの出力hidden stateがその方向へ強くanchoringされ、生成内容は例に近づきます。

この視点は、few-shotに関するいくつかの奇妙な現象を説明します。第1に、例の多様性はanchorを弱めます。 styleの異なる三つの例を与えると、hidden stateは三方向へ引かれ、平均的な位置へ落ちるため、anchorの効果が弱まります。そのためfew-shotでは通常、例のstyleをそろえる必要があります。第2に、exampleの「format」は「内容」より重要です。 研究では、few-shot例の入出力labelを無作為に入れ替えても、たとえば「肯定的な感情」と「否定的な感情」のlabelを交換しても、性能低下は小さいことが分かっています。モデルがexampleから主に学ぶのは、「どの入力がどのlabelに対応するか」ではなく、「入力はどの形か、出力はどの形か、両者をどのように変換するか」です。これらはhidden state層の構造情報であり、具体的な意味の対応に依存しません。第3に、例を増やしすぎると効果が逓減し、逆転さえします。 これもattentionの希釈です。例が多すぎると、各例が与えるanchoringの強度が下がります。

したがって、few-shotの本質は「教育」ではなく「anchoring」です。token系列でhidden state空間に軌跡を描き、その延長線上へモデルの出力を着地させます。この点を理解すると、few-shotの設計は「どの規則をモデルへ教えるか」から、「モデルの出力をどの位置へanchoringするか」へ変わります。まったく異なり、より正確な操作の枠組みです。

第4の扉：モデルの「性格」の一貫性を保つことが難しい理由

さらに進むと、より深い現象である「モデルの性格の一貫性」に行き着きます。

Claudeと長時間対話すると、比較的安定した人格があるように感じます。表現方法、価値観、応答のrhythmに、一定の一貫性があります。しかし、その一貫性が「破れる」ときもあります。ある回答が普段より急に冷たくなったり、逆に過度に熱心になったり、特定の話題で別のClaudeになったように見えたりします。多くのユーザーが、この「性格drift」を経験しています。

なぜ起きるのでしょうか。私たちの鍵を使うと、答えが明確になります。Claudeの「性格」は、どこかに明示的に保存されたentityではなく、vector空間におけるhidden stateの安定したattractor basinです。 対話が進むと、各turnのhidden stateは、それまでのすべてのtokenによって共同で形作られます。対話内容、ユーザーのtone、話題が「Claudeの典型的な性格領域」と一致していれば、hidden stateはその領域に安定してとどまり、Claudeの応答も一貫して感じられます。

しかし、あるtokenがhidden stateを通常とは異なる方向へ押す場合があります。ユーザーが極端なtoneを使う、モデルの珍しい関連付けを活性化する話題に触れる、long contextの初期tokenがattentionを通じて後続へ繰り返し影響する、といった場合です。hidden stateは安定したattractor basinから外れます。外れるとClaudeの応答の「tone」も変わり、小さい変化にとどまる場合もあれば、ユーザーがすぐに「これはClaudeらしくない」と感じるほど大きく変わる場合もあります。

Jailbreak、つまりモデルに通常は言わないことを言わせる手法の中核的な仕組みは、慎重にtoken系列を作り、モデルのhidden stateを、訓練時のhuman feedbackが網羅しなかった領域へ押すこと です。その領域でもモデルは正常に動き続けますが、出力の特徴はhuman feedbackが形作った「性格」の制約を受けなくなります。Jailbreakの防御が非常に難しい理由もここにあります。hidden stateを異常な領域へ押すtoken系列を、すべて列挙することはできません。

この視点はAgent engineerに具体的な示唆を与えます。Agent systemを設計するとき、SOUL.mdやAGENTS.mdなどのpromptは、Agentのhidden stateを安定した人格/能力領域へanchoringする 役割を果たします。promptが良いほどanchorが強く、長い対話でAgentがdriftする確率は下がります。ただし、後続tokenが状態を押し出す可能性は常にあるため、100%確実ではありません。robustなAgent設計では、driftが起きると仮定し、monitoringとregressionの仕組みを設計すべきです。たとえば定期的に「振り返り指示」を注入してhidden stateを再調整する、重要な判断点で完全なsystem promptを読み直す、といった方法です。

第5の扉：モデルが幻覚を起こす理由

最後の扉は、LLM engineerを最も悩ませる現象、幻覚へつながります。

幻覚とは、存在しない本を捏造する、架空の経歴を作る、誤った歴史上の日付を示すなど、事実として誤った内容をモデルが自信を持って述べることです。直感的には、「モデルは自分が知らないことを知らず、作り話をする」と説明されます。この説明は半分正しいものの、仕組みの最重要部分を見落としています。

鍵を使って見ます。「『XXX』という本の著者は誰ですか」と尋ねると、モデルはforward passを行い、最終層でhidden stateを生成し、そこから出力tokenをdecodeします。重要なのは、hidden state空間の構造が、どの出力を「もっともらしく見せるか」を決めることです。 この高次元空間では、「著者はA」と「著者はB」に対応するhidden stateは通常、非常に近い位置にあります。いずれも「人名である」、「この本に関連するcontextに現れた」、「文学作品の著者という意味clusterにある」といった制約を満たすからです。

モデルが訓練時に本当の著者を見ていれば、その著者に対応するhidden stateが強化され、正しい著者を生成します。一方、その本を見ていない、または強いsignalを形成できないほどしか見ていない場合、「著者はX」という出力が、形はもっともらしいものの、内容はその場で合成されたhidden state からdecodeされます。モデルは無作為に「でっち上げている」のではなく、空間構造の制約に従う、もっともらしい出力 を生成しています。ただし、事実という面では根拠がありません。

さらに深い問題として、出力を生成するとき、今生成した名前が実際の記憶なのか、合成なのかをモデルへ伝える仕組みがありません。 hidden stateには「事実/合成」という独立した次元が存在しないためです。これは現在のTransformerアーキテクチャが持つ根本的なblind spotです。内部状態では「事実の記憶」と「もっともらしい推測」を区別せず、hidden state空間では同じように見えます。モデルが出力に持つ「自信」はhidden stateの明確さに基づき、その出力に対応する事実が訓練データに本当にあったかには基づきません。

この点を理解すると、「不確かな場合は分からないと答えさせる」という単純な方法が不十分な理由も分かります。hidden stateの層には、「不確かである」というsignal自体がない場合がある からです。RAG、tool use、groundingは、本質的に、モデル自身に真偽を判定させるという不可能なタスクを避け、外部から事実上の制約を与えます。 現在、幻覚へ対抗する最も実用的な方法であり、幻覚の実際の仕組みを正しく診断しているからこそ有効です。

五つの扉をつなぐ

ここで立ち止まり、開いてきた五つの扉を振り返ります。CoTが有効な理由、promptの長さのsweet spot、few-shotの本当の役割、モデルの性格の安定性、幻覚の根源です。表面的にはLLMエンジニアリングの別々の話題ですが、同じ仕組みが異なる側面に現れたものだと感じられるはずです。

その仕組みは、最初に構築した中核的な矛盾です。モデルの内面はhidden state空間の高次元で豊かな認識であり、モデルの口はtokenという17bitの低次元で狭い出口です。すべてのLLMエンジニアリング実践は、本質的に「内面と口の変換」という中核bottleneckを管理しています。

CoTは複数段階のtoken relayで総計算量を蓄積し、一回のforward passの制約を回避します。Promptの長さのsweet spotは、「hidden stateを十分に形作ること」と「重要なsignalを希釈しないこと」の均衡です。Few-shotはhidden state空間に軌跡を描いてanchoringします。Modelの性格は、hidden stateがvector空間に持つ安定したattractor basinです。幻覚はhidden state空間の構造が生む副産物であり、その空間が「真実」と「もっともらしさ」を区別しないために起きます。

この中核的な矛盾を理解すれば、万能の鍵を手にしたと言える理由はここにあります。今後、LLMエンジニアリングの問題に出会ったら、最初に次のように問うべきです。hidden stateの層で何が起きているか。tokenの層で何が起きているか。両者の変換のどこで問題が生じたか。 この思考frameworkは、多くのprompt engineerより一段深く問題を見る助けになります。多くの人はtokenの層でtrial and errorを繰り返しますが、hidden stateの層で考えられるようになります。

Frameworkを身につけるための練習

最後に、このframeworkを自分のエンジニアリング直感へ変えるための思考練習を示します。

最近行ったLLM関連の作業を振り返ってください。AgentのSkill設計、promptのdebug、system promptの変更かもしれません。具体的な設計判断または問題を一つ選び、この記事で作った「hidden state対token」のframeworkで分析し直します。その判断はhidden stateの層へ、実際にどのような影響を与えたでしょうか。tokenの層の振る舞いと、どのような関係があるでしょうか。設計し直すなら、hidden stateの視点から、より良い方法を見つけられるでしょうか。

練習の目的は、すぐに新しい結論を出すことではなく、このframeworkで考える習慣を作ることです。何度か繰り返すと、LLMエンジニアリングの問題を見る視点が永続的に変わったと感じるでしょう。この視点の変化は、現在のAI engineerにとって最も競争力のある差別化要素の一つかもしれません。技術skillが十分な実務者でも、LLMの振る舞いをmechanism levelで説明できる人はほとんどいません。それができれば、同程度の経験を持つ人より技術的な深さで明確に先行できます。

この鍵は時代遅れになりません。将来Transformerアーキテクチャがさらに高度なモデルに置き換えられても、AI systemに「内部表現」と「外部interface」の区別がある限り、「内面と口の非対称性」があり、この中核的な矛盾の何らかの変形が残ります。この思考frameworkを身につければ、現在のLLMを説明する道具だけでなく、内部状態と外部interfaceが分離するあらゆるsystemに向き合うための、AI engineer向けの汎用的なmental modelを得られます。