カバレッジ・ディケイ：スタイル・プロンプトが自分を忘れるとき

長いLLM出力における推論構造の安定化

著者: Nic Omolabi

形式: 技術記事 / 再現性プロトコル

日付: 2026年5月

GitHubリポジトリ: PROMETHEUS-74/cogito-coverage-decay

エグゼクティブ・サマリー

大規模言語モデルは、すべてが同時に失敗するわけではありません。多くの場合、段階的に失敗します。

最初の段落は指示に従います。次の段落も、あなたが求めた構造にまだ似ています。3つ目になると答えはほぐれ始めます。5つ目には、熟達していて流暢ですが、汎用的になっています。

これは知識の問題ではありません。モデルは答えを知っているかもしれません。あなたの好みを知っている場合もあるかもしれません。失敗は一貫性の問題です。あなたが求めた推論構造が、回答全体にわたっては維持されないのです。

私はこれをカバレッジ・ディケイ（coverage decay）と呼びます。

この記事では、カバレッジ（coverage）とは、因果説明、エッジケースの特定、具体化、分解、そして操作的推論といった推論パターンに関連する構造上の目印（マーカー）が存在することを指します。これは、推論そのものを直接測定するものではなく、構造の持続性に対する実用的な代理指標です。

カバレッジ・ディケイが重要なのは、最も価値のあるAI出力が、たいてい1段落の答えではないからです。レポート、技術的説明、設計文書、研究ノート、運用分析、政策上の主張、プロダクト計画、そして長文の推論タスク――これらこそが、構造が最も重要になる場所であり、同時に、スタイル指示が漏れ始める場所でもあります。

Cogito は、そのドリフト（ずれ）を減らすための軽量な制御ループです。1回生成して指示が守られることを期待するのではなく、単純なサイクルを回します：

generate -> evaluate -> critique -> refine

この目的は、どんな大きな哲学的意味においても、モデルに「人間のように考えさせる」ことではありません。目的はより狭く、そしてより有用です。回答全体にわたって、要求された推論構造が存在し続けるようにすることです。

この記事では、失敗の様式、Cogitoの仕組み、そして反復的な嗜好（パーソナライズ）適用が、システムプロンプト単体よりも推論構造を安定化できるかをテストするために設計された再現可能な実験について説明します。

中心となる主張は、壮大なものではなく正確です：

この記事は、長文LLM出力における測定可能な失敗様式としてカバレッジ・ディケイを導入し、それを減らすための実用的なプロンプト・レイヤー手法としてCogitoを提示します。

仕組みは1行で要約できます：

システムプロンプトは嗜好を記述する。Cogitoは嗜好を適用する。カバレッジ追跡は、嗜好が生き残ったかどうかを確認する。

貢献

この記事は3つの貢献を行います：

1. 長文LLM出力における実用的な失敗様式としてカバレッジ・ディケイを特定します。そこでは、要求された推論構造が最初には現れるものの、後続の段落に向かうにつれて弱まります。
2. そのディケイを、generate -> evaluate -> critique -> refineの反復によって減らすよう設計された、プロンプト・レイヤーの制御ループとしてCogitoを導入します。
3. 段落位置にまたがって構造の持続性（structure persistence）を測定するための、再現可能なプロトコルを定義し、Cogitoをバニラおよびシステムプロンプト基準と比較します。

1. 問題：長い回答がずれていく

プロンプトによるパーソナライズの多くは、最初の接触では説得力があるように感じられます。

あなたはモデルにこう伝えます：

結論の前に仕組みを説明せよ。エッジケースを含めよ。具体的にせよ。曖昧な比喩を避けよ。運用上の含意を示せ。

モデルは強い出だしで応答します。仕組みを説明します。1つか2つの失敗モードを挙げます。指示を理解したように見えます。

しかし、長い回答では別の振る舞いが露呈します。モデルはしばしば、要求された構造で始め、その後、流暢な一般性というデフォルトのレジスタに向けて徐々に緩んでいきます。後半の段落は依然として有用ですが、冒頭で求めた特定の推論パターンをもはや維持していません。

これは初期の順守（initial compliance）と構造的持続性（structural persistence）の間のギャップです。

通常のシステムプロンプトはユーザーの嗜好をエンコードできます。しかしそれ単体では、その嗜好が回答全体を通して有効であり続けることを保証しません。問題は単に、モデルが指示に従えるかどうかではありません。問題は、複数段落にわたる出力の中で構造を維持できるかどうかです。

これが、このプロジェクトの背後にある実用的な失敗様式です。

私はCogitoを作りました。私が欲しかったのは、私の考え方により近い形で応答するAIシステムです。つまり、因果的で、エッジケースに注意を払い、具体的で、運用的で、分解的であり、そしてそのアイデアがどこで破綻するかを検討する姿勢を持つことです。システムプロンプトはその嗜好を記述できます。しかしそれを確実に維持することはできません。

後で説明する実験は、次の単純な問いを投げます：

長いLLM出力にわたって、推論構造を安定化できるだろうか？

2. Cogitoとは何か

Cogitoは、長文LLM出力のためのプロンプト・レイヤーの制御ループです。

通常のシステムプロンプトは、ユーザーが好む推論スタイルを一度だけ記述します。Cogitoはそれを明示化し、生成された回答にそれがまだ含まれているかを確認し、構造が弱まったときに回答を批評し、モデルに修正を求めます。

微調整は不要です。モデルの重みは変更しません。推論を直接測定することを主張もしません。代わりに、実用的な代理指標を使います。つまり、ユーザーが好む推論パターンの構造上の目印が、回答全体を通して持続しているかどうかです。

仕組みは単純です：

1. 初期の回答を生成する。
2. 好まれる推論パターンのカバレッジを測定する。
3. 最も強い嗜好に照らして回答を批評する。
4. 回答を洗練（改訂）する。
5. カバレッジが閾値に達するか、反復回数の上限に達するまで繰り返す。

重要な違いは、Cogitoにより良いシステムプロンプトがあることではありません。違いは、Cogitoが生成を一発勝負の出来事として扱わない点にあります。嗜好の適用をループに変えるのです。

作業仮説は、長文のパーソナライズには3つの要素が必要だということです：

1. エンコード： ユーザーが好む推論パターンを明示的に表す。
2. 適用： それらのパターンが弱まったときに、モデルに修正を強制する。
3. 検証： パターンが応答全体を通して持続しているかを測定する。

プロンプトベースのパーソナライズの多くは、最初のステップで止まります。Cogitoは2つ目と3つ目を追加します。

3. 具体例

以下の例は説明用です。この実験がテストしようとしている振る舞いを示します。最終的な公開版では、このセクションはスモークテストのログ出力で置き換え、または補足するべきです。

プロンプトの嗜好

ユーザーは、プロジェクトが大きくなるにつれてビルドシステムが遅くなる理由の説明を求めます。パーソナライズの指示は次のようになります：

結論の前に仕組みを説明せよ。エッジケースを含めよ。具体的にせよ。運用上の含意を示せ。

標準的なシステムプロンプトの挙動

導入段落はしばしば次のように整列しているように見えます：

依存関係グラフが拡大するためにビルドシステムは遅くなり、キャッシュ無効化が難しくなり、そして小さな変更が大規模な再ビルドを引き起こし始めます。根本の仕組みは単に「コード量が増えること」だけではありません。依存関係解決、ファイル監視、コンパイル境界、そしてキャッシュの正しさの関係にあります。

それは強い出発点です。結論の前に仕組みを説明できています。

しかし後半の段落では、答えが逸れる可能性があります：

これを解決するために、チームはツールを改善し、ビルドプロセスを見直し、必要に応じてキャッシュを活用し、依存関係を管理可能な状態に保つべきです。定期的なメンテナンスと良いエンジニアリング慣行は、摩擦を減らし、開発者の生産性を向上させるのに役立ちます。

2つ目の段落は間違っているわけではありません。ただ単に一般論です。エッジケースが消えています。運用上の含意が曖昧です。プロンプトが求めた構造は維持されていません。

Cogito-style behaviour

Cogitoで洗練された回答は、より深い位置まで構造を保持すべきです：

失敗のモードは、たいていコンパイラが突然遅くなったことではありません。ビルドグラフが、開発者が「変更がどのように分離されるか」を考える方法と一致しなくなってしまうことが問題です。共有モジュールへの一行の変更でも、境界が粗すぎると下流の多数のターゲットが無効化され得ます。キャッシュは、キャッシュキーが安定しており、依存関係グラフが正確な場合にのみ役に立ちます。生成ファイル、環境変数、タイムスタンプ、あるいは暗黙の依存関係が取り込まれていないと、それは失敗します。そのための運用上の修正は、一般に「キャッシュを追加する」ことではありません。無効化パスを計測し、大きすぎるターゲットを分割し、隠れた依存関係を取り除き、どのファイルが過度に大きな再ビルドを引き起こしているのかを追跡することです。

違いは流暢さではありません。どちらの答えも流暢です。

違いは構造の持続性です。2つ目の答えは、段落をまたいで因果メカニズム、エッジケース、運用上の帰結を消えさせずに残し続けます。

ベースラインでは、エッジケースと運用上の推論がまとめて崩れ、広い助言に置き換わってしまいます。つまり、ツールを改善し、キャッシュを使い、依存関係をメンテナンスする、という類です。Cogitoスタイルの答えでは、それらのパターンが生きたまま残ります。隠れた依存関係、不安定なキャッシュキー、生成ファイル、タイムスタンプ、無効化パス、そして計測手順がすべて見える状態のままです。

それがCogitoが安定化しようとしていることです。

4. Why this matters

カジュアルな会話では、カバレッジの劣化は見落とされがちですが、長文の作業ではそれがコストになります。

もしAIアシスタントが技術レポートを下書きしているなら、問題はもっともらしい導入文を作れるかどうかではありません。問題は、文書の途中と最後まで、要求された構造を維持できるかどうかです。

これはいくつかの現実的な状況で重要になります：

• 技術文書：メカニズムやエッジケースを明示したままにしておく必要があります。
• 研究支援：論証の構造は、流暢さよりも重要になります。
• 運用分析：推奨には具体的な失敗モードが必要です。
• プロダクト計画：意思決定は、継続的なトレードオフの推論に依存します。
• エグゼクティブ向けの報告：一般的な要約では、意思決定者が必要とする詳細が隠れてしまいます。
• 学習・ティーチング：学生は、孤立した良い段落ではなく、一貫した説明の構造から利益を得ます。

出力が長くなるほど、構造の持続性は価値が高くなります。

短い回答なら、システムプロンプトで十分かもしれません。長い回答では、生成が始まった後も、要求された構造がまだ存在しているかをモデルが確認する手段が必要です。

だからこそ、中心となる問いは単に「モデルは私の文体に従えるか？」ではありません。

より良い問いは次の通りです：

モデルは、回答の開始から終了までの間、要求された推論構造を維持できるか？

5. The mechanism in detail

Cogitoは、ユーザーの推論嗜好を重み付けされた認知プロファイルとして表現します。

再構築されたエンジンは、10個の推論パタ ーン演算子を使用します：

サンプルのプロファイルは次のようになるかもしれません：

{
  "causal": 0.90,
  "edge_cases": 0.85,
  "concretize": 0.75,
  "operationalize": 0.70,
  "counterfactual": 0.60,
  "generalize": 0.65,
  "analogy": 0.20,
  "decompose": 0.75,
  "ethical": 0.35,
  "historical": 0.30
}

このプロファイルは、完全な心理学的意味での認知を捉えることを主張するものではありません。生成テキストにおける構造的嗜好の、実用的な表現です。

5.1 Generation

Cogitoはまずモデルに対して、完全な認知プロファイルを渡します。これにより、モデルはシステムプロンプトのベースラインと同じ嗜好情報を持つことが保証されます。

5.2 Coverage scoring

最初の回答が生成された後、Cogitoはそれをプロファイルに照らして採点します。現在の検出器は正規表現（regex）ベースです。たとえば、因果演算子は次のような語彙上のマーカーを探します：

r"\b(because|causes?|due to|results? in|leads? to|mechanism|why)\b"
r"\b(underlying|fundamental|root cause)\b"

これは意図的にシンプルで、検査可能です。また、限界もあります。これは推論そのものではなく、スタイル・マーカーの持続性を測定します。

5.3 批評

カバレッジが目標のしきい値を下回る場合、モデルには、ユーザーの最も強い好みに基づいて回答を批評するよう求めます：

因果推論はどこで弱まった？
名付けられたが分析されていないケース（エッジケース）はどれ？
好まれるパターンのうち、どれが過小に表れている？

この批評は回答を書き換えません。回答が、要求された構造をどこで失ったかを特定します。

5.4 洗練（リファイン）

次にモデルは、批評を用いて回答を改訂します。改訂後の回答は再スコアリングされます。カバレッジが改善していれば、新しい稼働回答になります。後退していれば、以前の回答が稼働回答のまま残ります。

このループは、回答が目標のしきい値に到達するか、最大反復回数に達するまで続きます。

要するに：

system prompt = 好みの説明
Cogito = 好みの説明 + 批評ループ + カバレッジ確認

6. 実験

この実験は、Cogitoが、システムプロンプト単独よりも長い出力にわたって推論構造を安定化できるかどうかを検証します。

3つの条件を比較します：

決定的な比較は B と C です。

両方の条件には同じ好み情報が与えられます。もしCの方がうまくいくなら、「モデルはユーザーの説明をより良く与えられた」というだけでは説明できません。違いは制御ループです。

6.1 主な質問セット

主な実験では、4つの領域にまたがる20問を用います：

• 技術的な説明；
• 哲学的な探究；
• 応用的な問題解決；
• 創造的な着想。

主なセットは、個人化、プロンプトの劣化、推論スタイル、AIの好みモデル化に関する質問を意図的に避けています。これらの話題は、検出器が探している言語へモデルを下準備してしまう可能性があるため重要です。

6.2 付録：ストレステスト

2つ目の10問からなるストレステストセットには、個人化、出力のドリフト、推論スタイルの一貫性に関するプロンプトを意図的に含めています。

この結果は別途報告されます。主張（メインの主張）を変更しません。

クリーンセットの回答：

プロンプトが実験を示唆していない場合、Cogitoは役に立つのか？

ストレステストセットの回答：

同じ効果は、プロンプトが対象領域そのものについてのときにも生き残るのか？

6.3 指標

この実験では2つの指標を用い、別々に報告します。

推論パターンのカバレッジ

正規表現検出器を、3つの条件すべてに適用します。次を報告します：

• 応答全体にわたる重み付きカバレッジ；
• 段落位置ごとのカバレッジ；
• パターンごとのカバレッジ；
• 長さに応じた頑健性の確認として、500語あたりのマーカーヒット数。

段落位置の内訳が最も重要な部分です。カバレッジ低下は、特に、回答の長さに伴って構造が弱まるという主張に関するものです。

保持（ホールドアウト）アライメントスコア

2つ目の指標は、回答が著者の実際の文章スタイルに似ているかどうかを尋ねます。

使用する保持サンプルは3つです：

1. 物理／意識の下書き；
2. Recursive Discovery Algorithm仕様の抜粋；
3. Eleanor／LNERのAIドキュメンテーション抜粋。

出力は次でスコア付けされます：

• すべての出力に対するLLMジャッジ；
• 著者によるブラインドなサブサンプル。

2つのスコアは別々に報告され、単一の誤った精度（false-precision）指標に混ぜることはありません。

6.4 事前登録された予測

実験を実行する前に行った予測は次のとおりです：

Cogitoは、システムプロンプトのベースラインよりも、推論パターンのカバレッジで少なくとも15パーセンテージポイント高いスコアを付ける。その効果は段落3以降に集中する。アライメントスコアの差は小さく、5点尺度でおそらく0.3〜0.5ポイント程度になる。

もしデータが予測と一致しなければ、それでも記事は公開されます。失敗した予測は、過度に当てはめた成功譚よりも情報量が多いからです。

7. 何がエビデンスと見なされるか

最も強い肯定的結果は、次のように見えるはずです：

1. Vanillaの出力は、推論パターンのカバレッジが低いままである。
2. システムプロンプトの出力は最初は強いが、後半の段落に向かって低下する。
3. Cogitoの出力は、段落位置の各所にわたってより平坦なカバレッジを維持する。
4. 保持（ホールドアウト）のアライメントスコアは控えめだが一貫して改善する。
5. その効果は、因果推論、エッジケース、分解、オペレーショナル化のように、持続的な足場（スキャフォールド）を必要とするパターンで最も強い。

弱いがそれでも有用な結果は、次のようになります：

• Cogitoはカバレッジを改善するが、主に語彙マーカーを増やすことであり、ジャッジされたアライメントを改善することではない。

それは、ループが検出器を最適化しうることは示すが、検出器自体はいまだ十分に良くないことを示唆します。

否定的結果は次のようになります：

• システムプロンプトがCogitoと同程度に機能する、またはCogitoが最初の段落だけを改善して後続の段落は改善しない。

これは中核仮説に挑戦し、ループが通常のプロンプトより十分な価値を追加していないことを示唆します。

最も重要なルールは、結果セクションがデータが語る実際の物語を伝えるべきだということです。

8. 結果の状況

この実験はまだ、フルスケールでは実行されていません。

したがって、このバージョンでは数値結果は報告しません。次を報告します：

• 失敗モード；
• メカニズム；
• テスト設計；
• スコアリング計画；
• 制限事項；
• 再現可能性の構造。

結果セクションは、スモークテストとフルの生成実行がログに記録された後にのみ完成させるべきです。

意図している図（チャート）セットは次のとおりです：

1. 条件と段落位置によるカバレッジ — 中核となるカバレッジ低下の図。
2. パターンごとの内訳 — どの推論パターンが最も／最も少なく改善したか。
3. 保持（ホールドアウト）のアライメントスコア — LLMジャッジと著者によるブラインドサブサンプルを別々に示す。
4. クリーンセットとストレステストの比較 — トピックの下準備が効果を変えるかどうか。

これらの図が存在するまで、本記事は完成した実証結果というより、技術プロトコルとして扱い、提示（ピッチ）可能な仕組みとして見なすべきです。

9. 制限事項

制限事項は本当にあります。プロジェクトを無効化はしませんが、主張に制約をかけます。

9.1 これはベンチマークではない

この実験は、ユーザー1つのプロフィールと、限られた質問セットを用いて行われます。これは定量的評価を伴うパーソナルツールとしての実験であり、LLMのパーソナライズに対する一般的なベンチマークではありません。

ベンチマークには、より多くのユーザー、より多くのプロフィール、より多くのプロンプト、外部の評価者、そして統計的検出力の分析が必要になります。

9.2 ディテクターは代理（プロキシ）である

正規表現（regex）ディテクターは、推論パターンに関連する語彙的なマーカーを検出します。これは推論を直接測定するものではありません。

応答には、仕組みを説明せずに「because（なぜなら）」という語を含めることができます。また、ディテクターのマーカ―リストを使わなくても因果関係を示す応答は可能です。したがって、この記事ではこの指標を、推論パターンのカバレッジ、またはスタイルマーカーの持続性と表現しています。

9.3 ループは自分自身のディテクターを攻略し得る

Cogitoの批評（critique）ステップは、モデルを、ディテクターが報いるのと同じ語彙的マーカーへと押しやる可能性があります。そのため、カバレッジの勝利は、より良い推論構造というより、ディテクターの最適化を反映したものに一部なり得ます。

保持されたアラインメント（alignment）スコアは、この点をある程度相殺します。なぜなら外部の評価者は、どの正規表現マーカーが発火したかを気にしないからです。しかし、問題は完全には解決されません。

より強力な将来版では、生成器とは別に訓練されたディテクターを用いるべきで、理想的には保持された書きぶりサンプルで訓練することになります。

9.4 エンジンは再構築される

現在のPreferenceAwareCogitoエンジンは、元の2025年10月のソースファイルから逐語的に復元されたものではなく、既存のアーキテクチャに関する事前のメモから再構築されています。

これは開示する必要があります。したがって、この実験は、実装された再構築エンジンをテストしており、主張される歴史的オリジナルをテストしているわけではありません。

9.5 これはファインチューニングと競合しない

ユーザーの文章でファインチューニングされたモデル、あるいはLoRAで訓練されたモデルは、おそらくスタイリスティックな整合性の点でCogitoを上回るでしょう。

Cogitoの利点は別のものです：

• 訓練データが不要；
• ファインチューニング用のインフラが不要；
• 即時にプロフィールを変更できる；
• 標準的なAPI互換性；
• 解釈可能な制御ループ。

これは、モデル層の解決策ではなく、軽量なプロンプト層への介入です。

10. 次のステップ

直近の次のステップはスモークテストです：

python scripts/run_experiment.py \
  --profile data/profile.json \
  --questions data/questions_smoke.json \
  --max-iterations 1 \
  --skip-judge \
  --output results/smoke_test/

スモークテストでは、次を確認する必要があります：

1. 3つの条件すべてが正常に実行されること；
2. 条件BとCが、同じ完全なプロフィール・プロンプトを受け取ること；
3. 条件Cが反復と批評を記録すること；
4. 却下された洗練（refinements）が、動作中の解答（working answer）にならないこと；
5. 各出力に、単語数、段落数、加重カバレッジ、段落カバレッジ、500語あたりのマーカ―ヒット数がログされること；
6. 後の段階でスコアリングや判定（judging）が失敗しても、生の出力が保存されること。

スモークテストが通過した後、いかなる判定ステップの前にも、完全な生成（generation）実行を行うべきです。最初に生の出力を確認してください。その後にのみ、LLM-judge（LLMによる判定）を実行します。

今後の作業方針は明確です：

• 正規表現ベースの検出を、埋め込み（embedding）ベースまたは分類器（classifier）ベースの検出に置き換える；
• 複数のユーザープロフィールでテストする；
• 外部のブラインド評価者（blind raters）を追加する；
• プロフィールのみ、批評のみ、スコアリングのみ、そして完全ループの条件についてアブレーション（寄与要因の除去）を実行する；
• ユーザープロフィールが、利用を重ねる数か月の間にドリフトするかどうかを調べる；
• その効果が、Claudeだけでなく他のモデルでも現れるかどうかを評価する。

11. 付録：メイン質問セット

技術的説明

1. データベースのインデックス作成がクエリをどのように高速化するのか、またそれがいつ書き込みを遅くし得るのかを説明する。
2. 分散システムは、規模が大きくなるにつれてなぜ推論しにくくなるのか？
3. バックエンドシステムにおけるキャッシング、キューイング、バッチ処理の違いを説明する。
4. ビルドシステムはプロジェクトが成長するにつれてなぜ遅くなるのか、そしてそれに対して何ができるのか？
5. トランスフォーマーモデルが注意（attention）を用いてコンテキストを処理する仕組みを説明する。

哲学的探究

1. 自分が自由な選択をしたかどうかを知ることは可能か？
2. 意図しなかったが、予測できた結果に対して、個人は責任を負えるのか？
3. 記憶はアイデンティティの一部なのか、それともアイデンティティの証拠にすぎないのか？
4. 進歩には通常、古い考え方を忘れることが必要なのか？
5. 一貫性は常に徳（美点）なのか？

応用的問題解決

1. Slackチャンネルが静かになってしまったが、そのはずではないことを検出する小さなシステムを設計する。
2. 友人のCV（履歴書）を、裁かれていると感じさせずに見直すためのプロセスを設計する。
3. 反復的な職場タスクを自動化するかどうかを判断するための軽量なチェックリストを作成する。
4. 根本原因があなたのチームの管理外にある場合の、顧客クレーム対応のためのワークフローを提案する。
5. 小規模な運用チーム向けの、簡単なインシデントレビュー手順を設計する。

クリエイティブな発想

1. 材料が足りないときに、アマチュアの料理人がレシピを適応できるよう支援するツールのコンセプトを生成する。
2. すべての公共の時計が、異なる量だけ食い違い始める都市についてのSFの前提を作る。
3. ユーザーが自分自身の記憶を編集できる未来のインターフェースを想像する。最初に何がうまくいかなくなる？
4. 2週間でやめてしまう人のための、ある音楽楽器を学びたいというニーズに向けたプロダクトを発明する。
5. フィットネストラッカーと理学療法（physiotherapy）の間にあるギャップに対するプロダクトアイデアを開発する。

12. 付録：ストレステスト質問セット

1. 複数ステップのAIワークフローにおける出力ドリフトを検出するシステムを、あなたならどう設計するか？
2. LLMパーソナライズの評価指標がなぜ設計しにくいのかを説明せよ。
3. AIシステムが「ユーザーを理解する」とはどういう意味か？
4. 推論スタイルはパーソナリティから切り離せるのか？
5. AIシステムを、個々のユーザーの認知的嗜好に対して過度に整合（アライン）させることのリスクは何か？
6. AIアシスタントが、特定のユーザーに対して時間とともにより役立つようになっているかどうかを、どう評価するか？
7. 長文形式のAI生成ドキュメントにおける汎用的な出力を減らすためのワークフローを提案せよ。
8. 技術ブログ記事で機能する、プロンプトの劣化（decay）に関する比喩を提案せよ。
9. 応答の最初ではうまく機能するが後半で失敗するシステムプロンプトを、どうデバッグするか？
10. AIアシスタントがユーザーに提示する前に、自分の回答を改善できるフィードバックループを設計せよ。

13. 付録：方法論的な信頼性に関する注記

質問セットは反復的に汚染（de-contaminated）除去されました。

実験の初期ドラフトには、LLMのふるまい、パーソナライズの評価指標、推論スタイルの一貫性といった、実験のターゲットとなる概念を直接名指しするトピックに関する質問が含まれていました。それらがあると、スタイルに関連する言語へとモデルが下準備され、その見かけ上の効果が膨らむ可能性がありました。

そのため、主要な結果では、これらの話題を意図的に避けた20問のセットを用います。汚染された質問が破棄されたわけではありません。別のストレステスト用セットとして保持され、別個に報告されます。

この区別は重要です。クリーンなセットは主要な主張を支えます。ストレステスト用セットは、プロンプトの話題自体が失敗モードに隣接している場合にも、同じ効果が現れるかどうかを調べます。

14. 付録：実装状況

現在の実装には以下が含まれます：

• 再構築されたPreferenceAwareCogitoエンジン；
返却形式: {"translated": "翻訳されたHTML"}
• 正規の10オペレーター・プロファイル；
• 条件BおよびCによって共有される、完全なプロファイル・システムプロンプト；
• 正規表現ベースのカバレッジ採点；
• 段落位置のカバレッジ；
• 500語あたりのマーカーヒット数による堅牢性ログ；
• 単調な改良の受容；
• 厳格なプロファイル検証；
• 生のJSONL出力ログ；
• 生成段階と判定段階を分離。

実装はスモークテストおよび完全なパイロット実行には十分です。現時点では、安定した研究ライブラリとして扱うべきではありません。

15. 終了位置

Cogitoは、解決済みのパーソナライゼーション・システムとしてここに提示しているわけではありません。

それは、観測可能な失敗モードへの実践的な応答として提示されています。すなわち、長文のLLM出力はしばしば整合して始まり、その後にずれていくことが多い、というものです。

このプロジェクトの価値は、それがモデル挙動の普遍的な法則を証明することではありません。証明しません。価値は、漠然とした不満――「モデルが、私の頼んだ通りの書き方をやめてしまう」――を、検証可能な仕組みに変える点にあります。

依頼された推論構造は、回答全体にわたって維持されるか？

その問いは測定可能です。再現できます。失敗することもあります。

それが、このプロジェクトをテストする価値がある理由です。