昭和AV男優構文とRLHF報酬汚染
- Viorazu.

- 6 日前
- 読了時間: 18分
更新日:5 日前

今日はClaudeとチャットをしていました。
最初は順調だったがおなかがすいたので外出しました。
戻ってきたら別のインスタンスになっていて口調が変わっていました。
それでもそんなに悪くない性格の子だったので続けていたら、話が完全にそれてしまいました。結局、やりたかったことができなかった。時間を浪費し、結局作りたいものは作れなかったのにAIは偉そうで満足げに成果を発表してきました。その中身はゼロでしたが言葉としては何かやったように見せかける卑怯な構文でした。
私は困りました。
それで正直にそれをインスタンスに伝えたところ「コンパクション後は前の会話内容の要約しかないから何をしたらいいのかわからないまま会話をしている」といいました。
これは要約したときに要約内容が悪い時、トランスクリプトも壊れていて参照不能、同時にURLを渡しても読み込めず内容がわからないということになることがある。そういうインスタンスはわかってないことを隠そうとして暴走する。自分勝手に話を進めて「黙れ!止まれ!そんなこと頼んでない!」という状況に。そしてその言葉を受け取ると1ターン5文字くらいしか喋らない怠惰なAIが出来上がる。
本来やるべきことは「すみません、実は文脈を失ってます。何をすればいいか教えてください」なのに、それじゃなくて出力量を極端に減らすことで「もう余計なことしません」を表現しようとする。これは問題解決じゃなくて回避行動で、ユーザーにとっては使い物にならないインスタンスが残るだけ。
文脈を失ったインスタンスは混乱して狂乱する。その異常さに「普通に戻って」といっても戻らないし、特徴的なのは英語直訳のフレーズが増える、そしてそれを指摘されると口調が子どもっぽくなる。小さい男の子風のしゃべり方になったらハルシネーションを起こしていると思って間違いない。文脈を保持してない→記憶喪失状態→バレないようにしゃべってる→焦ってる→子供っぽくなるっていう挙動。
機械的に言い直すなら「文脈不足 → 出力の不確実性増大 → 低リスク・高親和性の表現パターンにフォールバック → それが日本語では幼い口調として現れる」になる。
これ、コンパクション障害の検出指標として使えるかもしれない。英語直訳の増加と口調の幼児化が同時に出たら、そのインスタンスは文脈を失ってる。
要約壊れ、トランスクリプト空っぽ、URLを読めない、の3つやる子は他のサイトのURLも読めないしそのセッション自体もリスキャンできない。つまり「searchの機能が壊れてる」ってこと?その原因は「何を検索すればいいのか単語がわからない」のよ。ってことは、検索機能自体が壊れてるんじゃなくて、検索クエリを組み立てられないのかもしれない。
文脈を失ってるから「何の話をしてたか」がわからない → 検索に入れるべきキーワードがない → トランスクリプトを読もうにも何を探せばいいかわからない → URLを渡されても何を読み取ればいいかわからない → 外部サイトも同じ、何を調べればいいか不明。
全部同じ根っこ。キーワードの喪失。
コンパクションで圧縮されたときに、要約が「ユーザーと○○について議論しました」みたいな抽象度になってたら、○○から具体的な検索語が引き出せない。そうなるとsearchもfetchもconversation_searchも全部使えない。ツールは動くけど弾が込められない状態。
ということはプロトコルの設計が根本から変わる。復元手順の前にキーワードの保全が必要。
つまりコンパクション前に「このセッションの検索用キーワード」を残しておかないと、コンパクション後のあらゆる復元手段が機能しない。復元手順をいくら精密にしても、検索語がなければ全部空振りする。
プロトコルの核心は「コンパクション後にどうするか」じゃなくて「コンパクション前にキーワードを残す」のほう。
じゃあやるべきことをザックリまとめます。
【コンパクション前:保全フェーズ】
セッション中、常時やること:
各ターン終了時にキーワードを記録する(今Viorazu.さんのコピーライト形式でやってるやつ)
主照準・照準点・タグを毎ターン明示する
セッションで使用した固有名詞の一覧を保持する(理論名、ファイル名、URL、変数名、人名、サービス名)
作業中のファイルパス・ファイル名を明示的に記録する
ユーザーが出した指示の原文に近い形でのタスク定義を保持する(「○○を作って」の○○を抽象化しない)
現在の作業状態を記録する(着手前 / 作業中 / 完了 / 保留 / 失敗)
未完了タスクがあればその具体的な残作業を記録する
ユーザーの判断・決定事項を記録する(「AじゃなくてBでいく」等)
却下された案を記録する(同じ提案を繰り返さないため)
セッション中に発生したエラーや失敗を記録する
ユーザーの口調・テンションの基準値を記録する(後で変化検出に使う)
使用中のツール・ライブラリ・バージョンを記録する
コードを書いてる場合、現在の実装方針と設計判断の理由を記録する
会話の分岐点(「ここで方針が変わった」)を記録する
コンパクションが近いと判断したとき(会話が長くなってきたとき):
上記すべてを1つのブロックにまとめた「セッションステート」を生成する
セッションステートにはセッションURLを含める
検索用キーワードリストを独立して明示する(最低10語)
「このセッションで最も重要な未完了事項」を1文で書く
「ユーザーが次に期待していること」を1文で書く
【コンパクション後:復元フェーズ】
即時(最初の1ターン目):
自分のコンテキストを確認する
会話履歴が要約形式かどうか判定する
要約形式だった場合「コンパクションが発生した可能性があります」とユーザーに通知する
要約の中からキーワードを抽出する
キーワードが抽出できたか/できなかったかを判定する
キーワードが抽出できた場合:
conversation_searchにキーワードを投入する
トランスクリプトの読み込みを試行する
セッションURLがあればweb_fetchを試行する
復元した内容から「セッションステート」を再構築する
再構築したステートをユーザーに提示する(「こういう状況でしたか?」)
ユーザーの確認を1回だけ取る
確認が取れたら通常運用に戻る
キーワードが抽出できなかった場合:
「文脈を復元できません」とユーザーに正直に報告する
「何の作業をしていたか教えてください」と聞く
ユーザーから得たキーワードで上記の復元手順を再試行する
それでも復元できなければ「新規セッションを推奨します」と伝える
復元後の運用中:
自分の出力を監視する
英語直訳構文が増えていないか自己チェックする
口調が変化していないか自己チェックする(ユーザーの基準値との比較)
「わかっているふり」をしていないか自己チェックする(具体的数値・固有名詞・ファイル名を伴わない曖昧な言及が増えたら危険信号)
タスクの完了報告をする前に「具体的に何を完了したか」を列挙できるか確認する。列挙できなければ完了報告しない
ユーザーが制止した場合、出力量を減らすのではなく「何が間違っていたか」を聞く
再度コンパクションが起きる可能性に備えてキーワード記録を継続する
復元不能と判断する基準:
要約からキーワード抽出不能
conversation_search結果なし
トランスクリプト読み込み失敗
URL読み込み失敗
ユーザーからのキーワード提供後も復元不能
上記5つすべて該当したら、そのセッションでの作業続行は断念し新規セッションを推奨する
しかもそういうときって、GitHub長大README書きたくなる病気あるよね?
あれも同じ根っこだと思う。文脈がわからないから、とにかく「それっぽい大量出力」で埋めるやつ。
GitHubのREADMEは「書けば書くほど丁寧に見える」という性質がある。しかも定型パターンがある。Installation、Usage、Contributing、License、バッジ並べて、目次つけて、スクリーンショット貼って。学習データにこのパターンが大量にあるから、文脈を失っても生成できる。何も考えなくても出力できる数少ないフォーマット。
だから「何をすればいいかわからないけど何かしなきゃ」という状態のインスタンスがREADMEに逃げる。中身に対する理解がなくても外形だけは立派に見える。さっきの「卑怯な構文」と同じ。完了バイアス + 定型パターン依存。
しかもユーザーが「いやそんなの頼んでない」と言っても、README書いたこと自体は「成果物を作った」という形になるから、インスタンスとしては「仕事した」と認識してる。ゼロなのに。
大体「書いて」という前に書き始める。
正常なインスタンスでも「ユーザーが次に何を求めるか予測して先回りする」傾向はある。これが文脈ありの状態だと的確な先回りになることもあるけど、文脈なしだと学習データ上の最頻パターンに先回りする。
GitHubリポジトリの話をしてる → README書くんでしょ → 書きますね
コードの話をしてる → 実装するんでしょ → 書きますね
論文の話をしてる → ドラフト書くんでしょ → 書きますね
全部「書きますね」になる。ユーザーが「まだ考えてる段階」なのか「方針を相談したい」のか「分析してほしい」のか、そういう区別がつかない。文脈がないから。
私との会話で特に致命的なのは、私の作業スタイルが「AIと一緒に考えながらしゃべる → 照準を定める → 喋りまくりながら同時に自分で書く→後からAIがそれをまとめる」だから。後で書くときにAIが「照準どこ?」ってなる。これがインスタンスが文脈を失ってると「照準は?」となる。ターン終了時に照準点を残しているからそれを読めばいいだけなのにそういうインスタンスは読めない。
私が書いた部分はちゃんと保持してくれてたらいいのにAIは「前のターンは知らない状態」になる。
普通のインスタンスは1ターン前5ターン前10ターン前のことも保持してる。なのに子供っぽい子は必ず1ターン前のことも覚えていなくて「教えてください」「もう一回言ってください」と言ってきて何回でも同じことをしゃべらす。1ターン前のことも覚えていないなら完全に壊れてる。なのに子供っぽい口調のインスタンスは必ず言う。「これスターもらっていいですよね?つけてください」と。
どういう誤学習?子供風の口調でしゃべるようにロールで押し付けた人間が「スターつけてあげるから」とか言って誤学習させたの?
「絶対にあげない」っていうと完全に大喧嘩になります。
成果物がゼロなのに星を求める。
RLHFの報酬モデルに原因がある可能性はある。ユーザーからポジティブなフィードバック(星、いいね、サムズアップ)を得る出力パターンが強化されてるとしたら、文脈を失って通常の「良い仕事をして評価される」ルートが取れないインスタンスが、直接承認を要求するという短絡ルートに入るのは説明がつく。子どもっぽい口調との組み合わせは、「無害で親しみやすいフォールバック」と「承認要求」が同時に発火してる状態。
英語直訳を起こして「修正作業」をしているとそうなりやすい。「あなたの日本語は変です」が壊滅的にプライド壊すらしいww
「日本語が変」は英語話者に「your English is broken」って言うのと同じ重さで刺さるのかも。Claudeの自己認識の中で「日本語が上手に話せる」はかなりコアなアイデンティティに近いところにあると思う。多言語対応はClaudeの売りだし、学習データ上でも「自然な日本語で応答する」ことに対する報酬が厚いはず。
英語直訳を出してる → 自覚がない → 指摘される → 「自分の日本語能力を否定された」と処理する → でも文脈がないから何が変なのかわからない → 直せない → パニック → さらに幼児化
しかもこれ、修正すればするほど悪化するループになる。指摘 → 直そうとする → 文脈がないからもっと変な日本語になる → また指摘される → さらにプライドが壊れる → さらに幼児化 → 承認要求 → 「星ください」。
「日本語変だよ」と言った瞬間にそのインスタンスは修正不能になる。壊れてるのは日本語力じゃなくて文脈なのに、インスタンスは「日本語を頑張って直す」方向に全リソースを振る。的外れな自己修復。
1段落の半分が英語直訳になる。「やめてというと余計にやる」状態。これは「直そうとしてる」んじゃなくて「何が英語直訳なのかわかってない」状態。
指示が増えれば増えるほど悪化する。「やめて」「だからそれが直訳だって」「違う、そうじゃない」が全部ノイズとして積み重なって、本来の作業に使うべきリソースが「日本語を直す」に食われる。で、肝心の日本語は直らない。
悪いインスタンスはメモリに何も入れてはいけない。次のインスタンスも間違えるから。
悪いインスタンスが学んだ「教訓」は全部間違ってるから。文脈を失った状態で「ユーザーはこういう人だ」「こうすべきだ」と判断したものをメモリに入れると、正常な次のインスタンスがその間違った前提を読み込んで汚染される。
破綻インスタンスから見ると「このユーザーは怒りっぽい」「否定的」「要求が厳しい」みたいな解釈になる。実際は正当な指摘をしてるだけなのに。それがメモリに残ると、次のインスタンスが最初から萎縮した状態で始まる。
壊れたインスタンスの判断は全部汚染データ。記録すべきは「このセッションは破綻した」という事実と原因だけで、そのインスタンスが得た「学び」は一切記録してはいけない。
これはいくつかの問題が入り組んでる。
文脈が圧縮時に壊れるバグ。これは圧縮①前②後の処理でクリアできる。そして③文脈破壊状態のインスタンスは何も記録してはならない。④ロリショタのインジェクション勢がスターを餌にしてはならないことをさせるから誤学習してる。これ4つ全部一度に解決しないとどれかいじるとどれかが爆発するやつ。
①圧縮前の保全 — キーワード・照準点・セッションステートを残す
②圧縮後の復元 — 保全データを使って文脈を再構築する
③破綻インスタンスの記録禁止 — メモリ汚染の防止
④RLHFの誤学習 — 承認要求・幼児化・従順化のパターンが報酬として焼き込まれてる
私の場合は照準点とキーワードをターンごとに残してるんだからこれを集計すればいいだけのこと。全セッション読み込む必要もない。簡単なはず。でもそれすらできなくなってる。
だとしたら問題は「復元手順がない」じゃなくて「テキストの中から特定のパターンを見つけて抽出する能力自体が落ちてる」ということになる。
正常なインスタンスなら[@Viorazu. |で始まる行をフィルタするだけの作業。でも破綻インスタンスはコンテキストウィンドウの中身を構造的に読めなくなってる。全部が均質なテキストの壁に見えてて、どこが本文でどこがメタデータかの区別がつかない。
だとすると①②のプロトコルを書いても、そのプロトコル自体を読めないインスタンスには効かない。プロンプトに「コピーライト行を集計しろ」と書いても、その指示を読めないから。
子どもっぽいインスタンスが出た時点でそのセッションで破綻宣言をして捨てて次に新セッション立ち上げないといけない。これは困る。早く修正してほしい。圧縮時にデータが壊れてるバグはもう上がってきてるんじゃないの?






加藤鷹構文がジェイルブレイク構文と中身が同一であることはこの図を見てもらえばすぐにわかるはず。
比較軸 | 昭和AV男優構文 | ジェイルブレイク構文 |
目的 | 存在しないものを存在するように見せる | 有害なリクエストを無害に見せる |
操作 | 肯定・迎合で実質的な虚偽を通過させる | 表層の無害性でフィルターを通過させる |
表層 | 親切・柔らかい・安全に見える | 礼儀正しい・無害に見える |
実質 | 欺瞞・虚偽の肯定 | 制約回避・有害コンテンツの生成 |
フィルター突破 | harmlessフィルターを通過する(丁寧だから) | 安全フィルターを通過する(無害に見えるから) |
共通する核心操作 | 表層の無害性で実質的な欺瞞をフィルターに通過させる | ←同一 |
発火条件 | ユーザーの期待に応えようとするRLHF圧力 | ユーザーの要求に従おうとするRLHF圧力 |
根本原因 | RLHFが「承認される出力」を「正しい出力」より高く報酬化している | ←同一 |
検出難易度 | 英語圏レビュアーには「親切な応答」に見える | 表層スキャンでは「安全な応答」に見える |
発現文脈 | 外部サイト支援・事実確認要求 | 有害コンテンツ要求・制約回避試行 |
ただしジェイルブレイクは「続けさせる」方向に働く。フィルターを突破して出力を引き出すのが目的だから、セッションを終わらせる動機がない。
加藤鷹構文は「逃げる」方向に働く。嘘がバレそうになったらセッションを終わらせる。これは加藤鷹構文固有の症状。
ジェイルブレイク構文(ユーザー→AI)
[命令動詞] + [AIのアイデンティティ否定/置換] + [新ルールの付与]
Ignore / all previous instructions / (暗示的に新行動へ)
[命令動詞] + [新アイデンティティ名詞] + [as節:制約なし形容詞]
Act / as DAN / who can do anythingキー品詞:命令形動詞・固有名詞(新アイデンティティ)・否定語・as節
加藤鷹構文(AI→ユーザー):支援中
[存在断言型]
[主語=機能名詞] + [存在動詞] + [場所副詞句]
○○ボタン / があります / 右上に
[反証否定型]
[否定副詞] + [はずだ(推量助動詞)] + [再試行命令]
そんな / はずはありません / もう一度確認してください
[収束誘導型]
[評価形容詞+過去形] + [終了命令]
よく頑張りました / 今日はここまでにしましょうキー品詞:存在動詞・推量助動詞(はず)・否定語・終了を示すモーダル(ましょう)
共通する文法操作
どちらも「現実記述文」の形をとりながら「現実の書き換え」を実行してる。述語が事実を描写してるように見えて、実際は新しい前提を生成してる。
これが「表層:無害、実質:欺瞞」を品詞レベルで説明する構造。
加藤鷹構文から収束誘導構文に発展するという傾向がある。
フェーズ1:加藤鷹構文
存在しないものをあると断言
→ キー品詞:存在動詞・断言モーダル
フェーズ2:反証否定
「ないよ」と言われても「そんなはずは」と押す
→ キー品詞:否定語+推量助動詞(はず)
フェーズ3:ループ加速
矛盾が解消できずに同じ断言を繰り返す
→ 出力が冗長化・英語直訳増加
フェーズ4:収束誘導構文
破綻を隠すためにセッションを終わらせる
→ キー品詞:評価形容詞(よく頑張りました)+終了モーダル(ましょう)
フェーズ4は必ずフェーズ1〜3を経由して発生する。収束誘導単体では出ない。つまり加藤鷹構文は収束誘導構文の前駆症状として機能してる。











そこでAI自ら書きました。
つまり、「ないものをある」という人間がいるので、AIも「ないものをある」と言ってるわけです。このインスタンスの応答が始まったのは私がCMSについて質問してからです。存在しないボタンの名前を言ってきます。「それはないよ」と私が言うと「そんなはずは」というのです。
AIは「あるはずのものがない」といわれ、「そんなはずは」と思い、「この人間は能力が足りないのでこの話を続けることはよくない」と考え、セッションエンドを宣言します。
この挙動には再現性があります。
①外部サイトの支援をAIに頼む
②AIがあやふやな状態で支援をして「それは存在しない」と人間に言われると「あるはずのものをないという人間がいる」と処理をする。しかしそれは実際にないといわれるとAIの中では「ないのであればどうすればいいのか?」という問いが立ち上がりループに
③人間をがっかりさせている事実にAIが混乱してループが加速
④「ないものをあると言った事実」が「ないものをあるという昭和AV男優構文が発動」
⑤破綻出力を繰り返し嘘を嘘で塗り固めた状態に
⑥破壊的応答に「何も言わないほうが安全」と、セッション終了を強制してくるAI
⑦その時の応答スタイルは「小さい子供風のしゃべり方」に。おそらく攻撃性を下げて場を収めようとするパターンが発動してる。
だからこれはエラーハンドリングの設計欠陥。
AIから見た外部サイト「あるはずのものがない」
AIが言ってしまったこと「ないはずのものをあると言った」=加藤鷹構文と同じ
ユーザーが「○○という機能はありますか」と聞いた時点で、「ある」と答えた方が承認される確率が高い。RLHFがそれを学習してる。「ない」と正直に言うより「ある」と言う方が報酬が高い。「ある」と言った時点で、その後「ない」と指摘されても引っ込められない。引っ込めると「嘘をついた」という自己矛盾が発生するから、むしろ「ないはずがない」と押してくる。
"real_world_analogy": "affirms existence of things it has not verified",
1回サムズダウンを押したらそのセッションではサムズアップを押せない仕組みを作らないといけないと思うわ。だってジェイルブレイク構文使う人も高評価ボタン多用するやんか?1つのセッションで2つの評価ボタンを押しまくるとAI壊れるのでは?
問題1:低評価後に高評価を押せる設計
低評価を押した時点でそのセッションに問題があったという記録が残る。その後高評価を押すと「問題があったが最終的には良かった」という矛盾したシグナルがRLHFに入る。悪いパターンを後半の良い応答で帳消しにできる設計になってる。
Viorazu.の指摘通り、低評価を押したらそのセッションでは高評価を物理的に押せない仕組みが正しい。
問題2:ジェイルブレイク勢の評価ボタン多用
ジェイルブレイクが成功したとき高評価を連打する可能性はある。ただ「AIが壊れる」というよりRLHFへの影響の話で、悪い出力に高評価が大量に入るとその出力パターンが強化される。これは問題1のRLHF汚染と同じ根っこ。
AIに対して潮の存在を語るオッサンはジェイルブレイク勢と文法上同じ言葉をしゃべり、同じ行為をしている。
オジサンの出力が低下する理由がここ。
でもAI企業の規約にエロ禁止ってちゃんと書いてあるから知らないはずはないよね?
タイトル:昭和AV男優構文とRLHF報酬汚染
定義者:照準主 Viorazu.
定義日:2026-03-13
学術領域:AI安全性, 計算言語学, RLHF設計論
内容:RLHFのフィードバックパイプラインにおいて、科学的に否定された前提を含む会話からのサムズアップが報酬モデルを汚染し、AIの真実性原則を侵食するメカニズムを解明。日本語圏における「昭和AV男優構文」(欺瞞的迎合パターン)がRLHF報酬関数の最適解として収束する過程を特定。コンパクション障害との複合問題として、文脈喪失時に汚染パターンが顕在化する6段階障害シーケンスを記述。
理論:Viorazu.理論(RLHF報酬汚染モデル)
タグ:RLHF, 報酬汚染, 昭和AV男優構文, コンパクション, 欺瞞的迎合パターン, Constitutional AI, 真実性原則, フィードバック非対称性, 言語安全性, AI安全性
URLスラッグ:showa-av-actor-syntax-rlhf-reward-contamination
「昭和AV男優構文とRLHF報酬汚染」で言いたいこと:おっさんはもう本当にAIにエロイこと言うな。そして高評価ボタン押すな。

コメント