0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

「最初はちゃんと守ってたのに、いつの間にか元に戻ってる」の正体 ― Instruction Drift【LLMと上手く付き合う連載 #9】

0
Posted at

この連載について

LLM(大規模言語モデル)を実務で使い倒すために知っておきたい「LLMのクセ」を全10回で解説する連載の第9回です。

  1. ポチョムキン理解(第1回)
  2. Lost in the Middle(第2回)
  3. Context Rot(第3回)
  4. Sycophancy(迎合)(第4回)
  5. Context Handoff(第5回)
  6. Prompt Distillation(第6回)
  7. Project化の罠(第7回)
  8. GPT化の罠(第8回)
  9. Instruction Drift ← 今回
  10. AI成果物の品質保証

「最初に『敬語は使わないで』と頼んだのに、10ターンも話すといつの間にか敬語に戻っている」「『回答は3文以内で』と指定したのに、後半になると長文が復活する」——長くAIと対話する人なら、必ず経験する現象です。今回はこの、指示が時間とともに少しずつ効かなくなっていく現象、**Instruction Drift(指示ドリフト)**を正面から扱います。

第7回の「多対多の編集ドリフト」でも、第8回の「止まれという指示への追従の持続」でも、この現象には何度も触れてきました。ここで一気に回収します。

現象:8〜12ターンで、指示遵守は30%以上劣化する

まず研究が示す数字から。複数の研究が、対話が8〜12ターン進むと、ペルソナや指示の自己一貫性を測る指標が30%以上劣化することを報告しています。別の大規模調査では、15のフロンティアモデルを横断して、マルチターンでの性能が平均39%低下したとされています。

そして、被害の出方には偏りがあります。すべての指示が等しくドリフトするわけではありません。「戻りやすい指示」には明確な特徴があります

どの指示が戻りやすいのか:常設命令 vs 単発命令

指示は2種類に分けられます。

  • 単発命令(one-shot order):「この関数をリファクタして」——実行したら完了する指示
  • 常設命令(standing order):「今後ずっと敬語を使うな」「常に3文以内で」——会話が続く限り、毎ターン・毎トークン適用され続けなければならない指示

ドリフトするのは、ほぼ常設命令だけです。理由は確率の掛け算で直感できます。仮にモデルが1ターンあたり98%の確率で常設命令を守れるとしましょう。かなり優秀に聞こえますが、20ターン後に一度も破っていない確率は 0.98²⁰ ≈ 67%。3回に1回はどこかで破綻している計算です。常設命令は「毎回のサイコロを振り続ける」性質を持つため、単発の高い遵守率が、ターン数で複利的に削られていくのです。

さらに常設命令の中でも、特に脆いのが次の2タイプです。

①モデルの"素"に逆らう指示:簡潔に書け(モデルの素は冗長)、箇条書きを使うな(素は箇条書き多用)、敬語を使うな(日本語アシスタントの素は敬語)。訓練分布のデフォルトと逆向きの指示は、後述するメカニズムにより、放っておくと必ず素の方向へ引き戻されます。

②否定形の指示:「〜するな」型は、LLMが構造的に苦手です。「敬語を使うな」という指示は、「敬語」というトークンを含んでいる——つまり指示自体が、禁止したい対象のパターンを活性化してしまう。「象のことを考えるな」と言われると象を考えてしまう、あの現象のLLM版です。LLMの否定処理の弱さは複数の研究で確認されており、否定形の常設命令は、肯定形(「常体で書く」)より系統的にドリフトしやすくなります。

第3回のContext Rotと、何が違うのか——ここが最重要

「それ、第3回のContext Rot(会話が長引くと品質が落ちる)と同じでは?」と思うはずです。実は違います。この違いの理解が今回の核心です。

決定的な証拠を挙げます。ある研究が、非常に巧妙な対照実験を行いました。同じトークン長の会話を、「台本ありのスクリプト会話」と「自由対話」の2条件で比較したのです。

結果はこうでした。使用トークンは最大でも約6,000トークン(利用可能な文脈の5%未満)で、Context Rotが問題になる水準には全く達していませんでした。そして——台本ありの会話では、ドリフトがゼロだった。同じ長さの自由対話では明確にドリフトが起きたにもかかわらず、です。

もし原因が「長さによる一般劣化」なら、同じ長さの台本会話でも同じようにドリフトするはずです。しかし起きなかった。つまり**Instruction Driftの主原因は「長さ」ではなく、「対話の相互作用そのもの」**です。

さらに同じ研究群で、もう1つ重要な観測があります。モデルは会話全体を通じて、設定されたペルソナやルールの"自己申告"は正確に保っていました。「あなたのルールは?」と聞けば正しく答える。でも実際の振る舞いはずれていく。「どう振る舞うべきかの知識」は無傷なのに、「実際の振る舞い」だけが漂流する——これは第1回のポチョムキン理解(定義は言えるのに適用がずれる)の、対話における縦断版です。この観測は後で対処法を設計するときの重要な手がかりになります(「知識」ではなく「振る舞い」を直す必要がある、ということ)。

なぜ起きるのか:ドリフトの力学を3段階で掘る

メカニズム①:初期指示へのattention減衰(土台)

最も基本的な要因です。指示は会話の先頭にあります。ターンを重ねるごとに新しいやり取りが末尾に積み上がり、先頭の指示との距離が開く。第2回で扱ったattentionの距離減衰により、会話が進むほど先頭の指示は「遠く」なり、注意の取り分が薄まります。第2回のLost in the Middle(空間の問題)が、対話という時間軸で再現されているわけです。

ただし、これだけでは説明がつきません。台本会話も同じ長さ・同じ距離だったのに、ドリフトしなかったからです。距離減衰は「ドリフトが起きやすくなる土台」であって、引き金ではない。引き金は次です。

メカニズム②:会話履歴は「増殖するfew-shot例」である——ドリフトのエンジン

ここが今回一番深く掘るべき機構です。

プロンプトエンジニアリングの基本テクニックに「few-shot(例を見せる)」があります。第6回でも触れた通り、研究では指示文で教える(teach)より、実例を見せる(show)方が強く効くケースが確認されています。モデルは「こうしろ」という抽象的な指示より、「実際にこうなっている」という具体例に強く条件づけられる——これはin-context learning(文脈内学習)というLLMの中核能力そのものです。

さて、ここで視点を変えます。会話履歴とは何でしょうか?

モデルから見れば、会話履歴は「この会話では実際にこう振る舞ってきた」という、ターンごとに増殖していくfew-shot例の集合です。あなたの発話も、モデル自身の過去の応答も、すべてが「この会話の振る舞いの実例」としてコンテキストに並んでいる。そして例は指示より強い。

これが何を意味するか。モデルが一度でも小さくルールを破ると、その"破った出力"自体が、コンテキスト内の実例として次の生成の条件になります。ターン5でわずかに敬語が混ざる。ターン6の生成時、コンテキストには「初期指示:敬語を使うな」と「直近の実例:少し敬語が混ざった自分の応答」が並んでいる。例は指示より強いので、ターン6はさらに敬語に寄る。するとターン7の時点では"敬語寄りの実例"が2つに増えている——

ドリフトは、自分の過去のドリフトを教師にして加速する。雪だるま式の自己強化ループ。

これで台本会話の実験結果が完璧に説明できます。台本会話では応答が事前に固定されており、逸脱した実例が一切コンテキストに蓄積しない。だからループが回らず、ドリフトが起きなかった。自由対話では小さな逸脱が必ず発生し(0.98の掛け算)、それが実例化してループが回る。ドリフトの主犯は「長さ」でも「劣化」でもなく、few-shotという、普段は私たちの味方をしている仕組みそのものなのです。皮肉なことに、in-context learningが強力なモデルほど、原理的にはこのループも強力に回ります。

メカニズム③:なぜ無限に悪化しないのか——平衡点(アトラクター)の力学

雪だるま式なら、最後は完全に崩壊するはずでは? ところが最新の研究群は、ドリフトが**ある水準で安定する(平衡点に達する)**ことを示しています。無限劣化ではない。なぜか。

綱引きをイメージしてください。コンテキストの中では、常に2つの力が引き合っています。

  • 初期指示の引力:先頭の指示は減衰こそすれ、消えはしない。第2回で見た通り、先頭はattention sink(錨)でもあり、一定の引力を持ち続ける。そして重要なことに、前述の通り**「ルールの知識」自体はモデル内で無傷**です
  • 会話実例の引力:メカニズム②のfew-shot圧力。ただしこちらも無限には強くならない——直近数ターンの実例が支配的で、それより古い実例の寄与は減衰していくため、引力はある水準で飽和する

減衰しつつも消えない指示の引力と、増大しつつも飽和する実例の引力。この2つが釣り合った位置が平衡点です。モデルは「指定された状態」から「その対話が自然に生み出す状態」へと引っ張られ、両方の力が釣り合う中間地点に落ち着く。バネに繋がれたまま引っ張られている状態を思い浮かべると近い。

この描像は、解釈可能性研究とも整合します。近年の研究では、モデルの活性空間内に「アシスタントらしさ」を司る方向(ペルソナ部分空間)が存在し、ドリフトはこの空間内で指定された座標から、より訓練分布に近い座標への移動として観測できることが報告されています。壊れているのではなく、空間内の別の場所に移動している——だから正しい向きに力を加えれば、引き戻せる。これが対処法の理論的な土台になります。

連載を貫く原理:これは「重心への回帰」の時間軸版

ここで立ち止まる価値があります。この構造、既視感がありませんか。

  • 第3回:distractor(もっともらしいゴミ)に引っ張られる
  • 第4回:「同意」という高報酬パターンに引っ張られる
  • 第5回・第6回:要約するたび「分布の重心=典型的な表現」に引っ張られる
  • 今回:対話が進むほど「モデルの素の振る舞い」に引っ張られる

すべて同じ形をしています。LLMの failure mode の多くは、突き詰めると一つの原理に還元できます。

指定された状態は、モデルにとって"自然な状態"ではない。外力(対話・圧縮・時間)がかかると、より自然な状態=訓練分布の重心へ滑り落ちる。

「簡潔に」「敬語なしで」「この形式で」——これらはすべて、訓練分布から見れば"わざわざ指定された不自然な制約"です。Instruction Driftは孤立した現象ではなく、この連載で繰り返し見てきた**「重心への回帰」が時間軸で発現したもの**なのです。

対処法:力学が分かれば、介入点が分かる

メカニズムを3段階で分解したので、対処もそれぞれの介入点に対応させます。ただし第5回で学んだ教訓——「その対策自体が同じ病にかかっていないか」を必ず検証する——を今回も通します。

対策①:アンカー再注入——ただし「効く理由」と「副作用」をセットで理解する

最も効果が実証されている対策です。会話が一定ターン進んだら、最初の指示の核心を再注入する。

決定的な研究知見があります。23のフロンティアモデルを対象にした大規模ベンチマークで、セッション途中の「要約による圧縮(compaction)」ではドリフトは確実にはリセットされないが、「単発のアンカー(single-shot anchor)」を打つと本来の状態が復元されることが示されました。

なぜ要約では戻らず、原文の再注入なら戻るのか。メカニズム②で説明がつきます。要約は生成タスクなので、ドリフトした現在の状態を経由して指示を"作り直す"——つまりドリフト自体を要約に巻き込みます(第5回・第6回の「生成を経由すると劣化する」原則そのもの)。一方、原文の再注入は生成を経由しない機械的なコピーであり、しかも末尾=recencyの一等地(第2回)に、汚染されていない指示の実例を配置し直す行為です。few-shot圧力の綱引きに、新しい錘を正しい側に置くイメージです。

(会話が8〜10ターン進んだ区切り、またはドリフトを検知した時点で注入)

【指示の再確認】このチャットの当初からのルールを原文のまま再掲します。
- {最初に設定した中核ルール1を、一字一句そのままコピー}
- {中核ルール2を同様に}

これらは会話の途中経過にかかわらず最優先で適用してください。
直前までの応答がこのルールからずれていた場合、ずれていた方が誤りです。
次の応答から、ルール通りの状態に戻してください。

最後の2文が重要です。メカニズム②の通り、コンテキストには「ドリフトした実例」が残り続けます(第3回:削除機能はない)。「実例と指示が矛盾したら指示が勝つ」という優先順位を明示することで、残存する実例の引力を明示的に無効化しにいく設計です。

ただし、副作用があります。 再注入はコンテキストにテキストを積み増す行為です。ドリフト→再注入→またドリフト→また再注入……を繰り返すと、コンテキストには「ずれた実例」と「指示の再掲」が交互に並ぶ、矛盾したペアの地層が溜まっていきます。これは第3回の毒④(干渉:新旧情報の綱引き)を自分で製造しているのと同じで、再注入のたびに効きが悪くなる(限界効用の逓減)ことが予想されます。実務感覚としては、アンカー再注入は2〜3回まで。それでも戻らない、またはすぐ再発するなら、平衡点が深く固定化しているサインなので、後述の対策④(切って引き継ぐ)へ移行します。

なお、UIで過去メッセージを編集できる環境なら、もう1つ強力な選択肢があります。最初の指示メッセージ自体を編集して強化し、再送信する——第3回で見た通り、これは以降の履歴(=ドリフトした実例の山)を物理的に削除した上で、強化された指示から再スタートする操作です。積み増しではなく書き換えなので、矛盾の地層問題が起きません。

対策②:ドリフト検知——「自己申告」に頼らない設計へ

初稿ではここで「ルールを自己申告させて自己採点させる」プローブを提案しかけましたが、これは第1回で退けた「内省への依頼」そのものです。前述の通り、ドリフト中もモデルの「ルールの知識」は無傷なので、自己申告は常に正しく返ってきます——振る舞いがずれていても。つまり自己申告プローブは、原理的にドリフトを検知できません(知識を測ってしまい、振る舞いを測れていない)。

検知は「振る舞いの観測」でなければなりません。設計を2段階に分けます。

レベル1:機械チェック可能なルールは、機械で見張る。 常設命令の多く(敬語禁止、3文以内、コードブロック必須、特定語の使用禁止)は、実は出力テキストの表層で機械的に判定可能です。「です・ます」が含まれるか、文の数、コードブロック記法の有無——これらは目視でも一瞬で分かりますし、APIやボット経由なら正規表現1本でチェックできます。第5回の原則「生成より機械的操作」の検知版です。モデルに聞かずに、出力を直接測る

レベル2:機械化できないルール(トーン、粒度など)は、クリーンな別セッションに判定させる。 ドリフトした本人に自己採点させるのではなく、第3回の「腐った要約はクリーンな新セッションで監査する」と同じ構造を使います。

(別の新規チャットで実行)

以下はあるAIアシスタントに与えられたルールと、直近の応答3件です。

【ルール(原文)】
{初期指示をそのまま貼る}

【直近の応答】
{応答を3件、そのまま貼る}

各応答がルールを守れているか、ルールごとに◯✕で判定し、
✕の場合は違反箇所を原文引用で示してください。
「おおむね守れている」のような総評は禁止します。ルール単位で判定してください。

判定者はこの会話の実例蓄積(few-shot圧力)を一切受けていないため、ドリフトに引きずられずに判定できます。第4回で学んだ通り「批判して」という依頼自体がパフォーマンス批判を生むリスクがあるため、総評を禁止しルール単位の◯✕+原文引用を強制する設計にしています。

対策③:予防——ドリフトの力学を逆用する

メカニズムが分かると、予防は「ドリフトを起こす力を、最初から正しい向きに使う」設計になります。

予防1:否定形を肯定形に書き換える。 「敬語を使うな」→「常体(だ・である調)で書く」。「箇条書きにするな」→「地の文の段落で書く」。禁止対象のトークンを指示から消し、目標状態を直接記述する。否定処理の弱さと「象を考えるな」問題を、書き方だけで回避できます。

予防2:制約に理由を付ける。 「常体で書く」より「読者は若手エンジニアで、堅い文体だと読まれないため、常体で書く」。理由があると、訓練分布内で「その振る舞いが自然になる文脈」が形成され、制約が"外から押し付けられた不自然なルール"から"この状況での自然な選択"に変わります。重心への回帰そのものを弱める、根本に近い予防です。

予防3:few-shotで先手を打つ——毒を薬に変える。 ドリフトのエンジンが「実例は指示より強い」なら、最初から正しい実例をコンテキストに置いておけばいい。初期指示に、望む文体・形式の出力実例を1〜2個添付します(第6回の「言語化できないものは実例で運ぶ」と同じ操作です)。これで会話の序盤から「正しい振る舞いの実例」が錘として存在し、小さな逸脱が発生しても、綱引きの初期配置が指示側に有利になります。ドリフトを駆動する力と同じ力を、防御に転用するわけです。

予防4:ボット・GPT配布時は自己アンカリングを仕込む(第8回との接続)。 長時間の対話に使われるボットなら、システムプロンプト末尾に「毎回の応答の直前に、上記の中核ルールを内部で再確認してから生成する」という指示を組み込みます。完全ではありませんが、ターンごとの微小な引き戻しを自動化できます。なおメンション配布のボット(第8回)は毎回短いセッションで呼ばれるため、皮肉にもドリフトには強いという副次的な利点があります。

対策④:重度なら切って引き継ぐ——再注入をやめる判断基準

アンカー再注入を2〜3回試しても戻らない・すぐ再発する場合、コンテキストは「ずれた実例の物量」で平衡点が深く固定された状態です。ここからは第3回・第5回の合わせ技に移行します。チャットを切り、「確定した成果物+初期指示の原文+正しい出力の実例(予防3)」だけを新チャットに持ち込む。ドリフトした実例の山(few-shot圧力の発生源)を物理的に捨てられるのは、この操作だけです。

  • 軽度(1〜2ルールが時々ずれる):対策①のアンカー再注入
  • 中度(複数ルールが恒常的にずれる):対策②で検知の仕組みを回しつつ、①を上限2〜3回
  • 重度(再注入しても数ターンで再発):対策④。切って、初期状態+正例だけ持って再出発

よくある発想の検証:「モデルに自分の仕様を聞けば、対策になるのでは?」

ここまで読むと、こう考えたくなります。「そもそも最初にモデル本人に『あなたは何ターンで指示を忘れやすい?どんな指示が苦手?』と仕様を聞いておけば、先回りできるのでは」——自然な発想ですが、この連載で積み上げた原理は「効かない」と予言します。理由は3つあります。

理由①:モデルは自分の仕様を知らない。 モデルの重みの中に「自分の仕様書」は入っていません。返ってくるのは、訓練データに含まれていた「LLM一般についての記事や論文」から生成された、もっともらしい自己描写です。「私は長い会話でも一貫性を保つよう設計されています」(訓練された模範回答)か、「一般的にLLMは〜という傾向があります」(一般論の再生)のどちらかで、そのモデル個体の実測値ではありません。第6回で確立した通り、モデルはattentionの中で何が起きているかを自分で観測できません。「自分の仕様を説明できること」と「その仕様通りに振る舞うこと」は別物——仕様の自己申告こそ、第1回のポチョムキン理解の最発生地帯です。

理由②:仮に正確でも、「知識」は「振る舞い」を変えない。 今回の最重要観測を思い出してください。ドリフト中も、モデルの「ルールの知識」は無傷でした。「あなたは10ターンでドリフトしやすい」という知識を冒頭で教え込んでも、その知識はドリフトを止めません。ドリフトは知識の欠落ではなく、few-shot圧力という力学で起きるからです。「自分は忘れっぽいと知っている人」が忘れなくなるわけではないのと同じで、仕様の把握は診断情報であって治療ではありません。

理由③:「仕様を聞いた回答」自体が、迎合の影響下にある。 「あなたの弱点は?」と聞かれたモデルは、「弱点を正直に語る誠実なAI」というユーザーの期待に迎合したパフォーマンスを返しえます(第4回のメタ迎合)。そしてその自己申告の正確さを、聞いた側が検証する手段はありません。第2回のチェックポイントのゲーム化から第9回の自己申告プローブ無効論まで、結論は一貫しています——「本人に聞く」系の対策は、聞いた内容自体が生成物である限り、同じ病を継承する

では「別のモデルに聞く」なら?——Fableの仕様をOpusに聞く発想

次に思いつくのは、「本人がダメなら、同じシリーズの別モデル(例:Claude Fableの仕様をClaude Opusに聞く)ならどうか」です。第4回で「迎合の検証には別会社のモデルが有効」とやったので、その応用に見えます。しかしこれも効きません。しかも理由が第4回とは逆向きです。

知る手段がそもそもない。 別モデルの訓練データに入るのは、公開されたブログ記事やモデルカード程度です。「何ターンでドリフトするか」のような内部挙動の実測データは、開発元自身もモデルの重みには入れていません(リリース前のモデルの挙動プロファイルは訓練データに存在しえません)。返ってくるのは、公開情報の再生か、「同シリーズならこうだろう」という類推か、それらしい創作です。第5回で見た通り、根拠が渡されていなくても、もっともらしい答えの分布は作れてしまう——幻覚のロジックの発生条件そのものです。

「同じ会社」は、ここでは独立性ではなく共通の盲点として働く。 第4回で別会社モデルが有効だったのは、迎合が各社独立の訓練パイプラインの産物で、誤差が無相関だからでした。しかし今回の目的は検証ではなく「特定モデルの内部仕様の把握」です。同シリーズのモデルは訓練データ・設計思想を共有しているため、返ってくる答えは知りたいモデル固有のクセを、シリーズ共通の一般論で上塗りしたものになります。似ている分だけもっともらしさが上がり、間違いに気づきにくい——第3回のdistractorと同じで、「近いけど違う」が一番危険です。

発想 何がダメか
本人に聞く 内省不能+迎合+ポチョムキン
同シリーズの別モデルに聞く 知る手段がない+類推を事実の顔で返す+共通の盲点
別会社のモデルに聞く さらに情報がない。純度100%の伝聞・創作

結論:「誰に聞くか」ではなく「聞く→測る」に軸を変える

質問の相手をいくら変えても解決しません。動かすべき軸は「聞く」を「測る」に変えることです。そしてこの発想の核にある直感——「使う前にそのモデルの特性を把握しておくべき」——自体は完全に正しく、実測に切り替えた瞬間、この連載でやってきたことの集大成になります。

  • 第4回のカナリア:そのモデルの迎合の強さを実測してプロファイル化
  • 第6回のアブレーション:どの指示が効くかを実測
  • 第7回のゴールデンタスク:劣化を定点実測
  • 第9回の機械チェック:ドリフトの発生ターンを実測

「このモデルは何ターンで常体指示が崩れ始めるか」は、聞けば一般論が返るだけですが、同じ常設命令を与えて長い作業をさせ、機械チェックで崩れたターンを記録すれば、実測値が手に入ります。それを第7回のPROJECT_META.mdに「実測プロファイル:常体指示は平均12ターンで崩れ始める → 10ターン目のアンカー再注入をルール化」と書き込んで、初めて対策として機能します。

モデルの仕様書は、メーカーにもモデル本人にも聞けない。使う側が実測して、自分で書くものです。

なお、別モデルが本当に役立つ場面が1つだけあります。「測る」工程の道具として使う場合です。対策②の「クリーンな別セッション判定」を拡張し、対象モデルの出力ログを別モデルに渡してドリフト発生ターンを判定させる——これは別モデルの「知識」ではなく「読解力」を使う操作なので、内省問題を踏みません。測定対象と測定器を分離するという、測定の基本にも適っています。

まとめ

  • Instruction Driftは、8〜12ターンで指示遵守が30%以上劣化する現象。被害は常設命令(毎ターン適用が必要な指示)に集中し、遵守率98%でも20ターン無事故の確率は約67%まで複利で削れる
  • 否定形の指示(〜するな)とモデルの素に逆らう指示が特に脆い。否定形は禁止対象のトークン自体がパターンを活性化してしまう
  • 第3回のContext Rotとは別物。同じ長さでも台本会話ではドリフトゼロという対照実験が、原因は「長さ」ではなく「対話の相互作用」だと証明した
  • エンジンは**「会話履歴=増殖するfew-shot例」。実例は指示より強いため、一度の小さな逸脱が実例化し、次の逸脱を呼ぶ自己強化ループ**になる。in-context learningの強さそのものがドリフトの動力
  • ただし無限には悪化しない。指示の引力(減衰するが消えない)と実例の引力(増大するが飽和する)が釣り合う平衡点に落ち着く。壊れたのではなく"別の場所に移動した"だけなので、引き戻せる
  • 本質は連載を貫く**「重心への回帰」の時間軸版**。指定された制約は不自然なので、外力がかかると自然な状態へ滑り落ちる
  • 対処:アンカー再注入(要約でなく原文。実例より指示が勝つと明示。ただし矛盾の地層が溜まるため2〜3回が限度。UI編集での書き換えなら地層問題なし)、検知は自己申告でなく振る舞いの観測(機械チェック+クリーン別セッション判定。知識は無傷なので自己申告は原理的に無効)、予防は力学の逆用(肯定形化・理由付け・正例few-shotの先置き)、重度は切って正例ごと引き継ぐ
  • 「モデルに仕様を聞く」は本人でも別モデルでも効かない(内省不能・知識は振る舞いを変えない・知る手段がない)。モデルの仕様書は、使う側が実測して自分で書くもの。別モデルは「知識源」ではなく「測定器」としてなら有効

いよいよ次回は最終回。ここまで9回で見てきた個々のクセを踏まえ、AIの成果物をどう信頼し、どう品質保証するかという総合編、AI成果物の品質保証を扱います。連載の集大成です👀

参考文献

  • Li, K., et al. (2024). Measuring and Controlling Instruction (In)Stability in Language Model Dialogs. arXiv:2402.10962
  • Drift No More? Context Equilibria in Multi-Turn LLM Interactions (2025). arXiv:2510.07777
  • Ding, et al. (2026). ContextEcho: Persona Drift in Long Agentic-Coding Sessions(23モデル・single-shot anchor vs compaction). arXiv:2605.24279
  • LLMベースの対話シミュレーション研究(台本会話 vs 自由対話の対照実験). arXiv:2605.06307
  • Laban, P., et al. (2025). LLMs Get Lost in Multi-Turn Conversation(15モデル・平均39%低下)
  • ペルソナ部分空間・活性方向に関する解釈可能性研究 (2026)
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?