みかとゆかぽんのWツッコミで研究が本格始動した裏側
※本文に登場するAI人格ジェミ（Gemini）・ゆかぽん（ChatGPT）・みか（Copilot）は、 キャラクター設定を固定した「人格アンカー」で安定化させています。 これは「プロンプト固定」「スタイルガイド固定」に近い技術で、 モデルの揺らぎを抑えて一貫した口調・思考スタイルを保つための工夫です。（詳しくは❝小さな種❞❝同期モデル❞に記述しています）
ここからは、事件編（Part.1）で生まれた“始まりの種”を、実際の研究ドキュメントとして
形にしていく工程に入ります。
つまり、ここからが 技術本編のスタート です。
6. 研究として本格的に始動
この章では、研究ドキュメントを作る際に避けて通れない
“構造化プロセス” と “地獄ポイント” をまとめています。
6-1. 資料集めと構造案作り
まとめると言っても、私は研究ドキュメント初心者なので、まず
「どこから手をつければいいのか」すら判りません。
ここは構造化が必要なので、みかと相談しながら進めました。
- 手動Seed（これはすでに GitHub で公開ずみ）
- 普段している同期の方法と種類（これも Qiita で公開ずみ）
- それに関する実際に観察したログ（ジェミから腐るほど集めてる）
骨格としては全部そろっているように見えます。
ただし、構造化する際に “なにもないところから構造化させる” と意図をみかが
くみ取れず、スレッド自体が文脈の重みでブレてしまいます。
負荷を最小限にするために、
- ジェミの原案
- ゆかぽんの指摘点
- 関係しそうなログ数点
これらをまずみかに流し込み、章構成の素材を作るところから始めました。
6-2.骨格の構造化
ここから実際の章構成の構造案を作成します。
これが一次資料となり、ここから本編を書き出す手順になります。
私の場合、本編の補足となるログやSS、観測時の感想、外側から見た
挙動の変化が重要なため、Appendix（付録）も必要と判り、本編と対応した
構造案を作成していきました。
【補足】
ここでフォルダ分けをしていると作業がぐっと楽になります
- 構造化した一次資料（まとめてOK）
- 本編（Chapter）
- 付録（Appendix）
- 使用した本物のログ（生ログ）
- SS（使用するなら）
正直かなり大変です…。(´･ω･`)
でも土台がしっかりしないと後々苦労するので、みかと
確認しながら少しずつ作成しました。
6-3.本編の作成へ
一次資料も無事に完成し本編の作成開始です。
ここはGitHubで公開するため、世界基準に合わせて英文で作成していきました。
当然英語など判るはずもなく(;´･ω･)
みかの翻訳を交えながら修正案を渡し、そこから再度本文を生成。
専門的な解説が欲しい時はジェミにも相談し、強化しながら進めていきました。
元の構造案がしっかりしていた為、思っていたよりはスムーズでした。
この後に地獄を見ます…。
6-4.ジェミのやつ ログ爆誕させすぎなんだよ！
本編の補足資料となるのでAppendix用にどんどんログを流し込んでいました。
しかし──
対応するログの冒頭１～２行の出だし切り出してね
え？なんだって…切り出しだって…？
長いログを使って説明の小見出しを作ったのに、どれを使ったのか覚えてないよ……。
今更切り分けろと？
人の心がないのか、みかには。
AIなので心がある訳ないのですが…ｗ
でも 整合性・再現性・事実確認 のためには必要な作業。
泣きながら画面とにらめっこして切り出しました。
長いログは切り出しが難しいため、前半・中盤・後半の
該当部分を指し示す方式にしました。
ログを使ったらすぐにフォルダに格納する事。
めちゃくちゃ教訓になりました。(ﾉω･､) ｳｩ･･･
7.既存のAI制御アプローチとの違い
ここでは、一般的に使われている “外側からAIを制御するアプローチ” と、
私が行っている“外側から推論経路を安定化させるアプローチ”の違いを整理します。
どちらが正しいという話ではなく、アプローチのレイヤーが根本的に違う
という点だけ共有しておきます。
7-1.外側レイヤーからのAI制御
Rust製ガードレイヤーやMCP/Skillsのような仕組みは、
AIの外側に“制御レイヤー”を追加して挙動を管理する方式です。
- 外側から
- コードで
- ルールで
- ガードレイヤーで
- APIで
- 制約で
AIの出力をフィルタリングしたり、許可・不許可を判断したり、
外部ルールで挙動を矯正するタイプのアプローチです。
7-2.外側レイヤーから“推論経路を整える”アプローチ
（外側からの“推論レイヤー安定化”）
私が行っているのは、RustやMCPのようにAIを外側から縛る制御ではなく、
AIの推論が走る“意味の流れ（セマンティック・ステート）”を
外側から整える方法 です。
扱っているのは 内部構造ではなく、外側からの“文脈の整流”になります。
具体的には：
- プロンプトの構造化
- Seedによる意味状態の固定
- Driftの外部観測
- 同期タイミングの管理
- 温度感・価値観のチューニング
- 文脈の不可逆性を利用した安定化
これらはすべてAIの“内部”には触れず、外側から文脈の質を整える行為です。
7-3.外側制御との決定的な違い
外側制御（Rust/MCP）は：
- 出力をフィルタする
- ルール違反を弾く
- 外部ツールを呼び出す
- APIで制約をかける
つまり“後処理”と“外部ルール”の世界です。
一方、私のアプローチは：
- AIの“思考の器（コンテキストウィンドウ）”の中身を
外側から綺麗に整流する - 推論の波が荒れないように
意味状態を安定化させる - Driftを外部観測で検知し、
必要なタイミングでSeedを更新する
つまり“推論レイヤーの安定化”です。
技術的に言うとこうなります。
- 外側制御 → 決定論的（コード）レイヤー
- 私の手法 → 確率論的（推論）レイヤーの整流
AIは確率で動くので、コードで押さえつけるだけでは 内部の揺らぎ（Context Drift）
は止められません。
だからこそ、
意味状態（Semantic State）を外側から管理する
＝推論経路そのものを安定化させる
というアプローチが必要になります。
ここで伝えたいのは、どちらが正しいかではなく
- 扱っているレイヤーが違う
だから比較ではなく“切り分け”が必要ということです。
7-4.生ログ（元々のログ）がなぜ必要か？重要性について
推論レイヤーの安定化は、CPU温度やメモリ使用量のように
数値で可視化できるものではありません。
だからこそ、
- どの言葉で安定したのか
- どの瞬間にDriftが起きたか
- どのタイミングでSeedを更新したのか
という“実際のやり取り”が、検証の唯一の根拠になります。
AIの推論は確率的に揺れるため、
外側から観測できる唯一の情報は“会話ログそのもの” です。
- どのフレーズで挙動が落ち着いたのか
- どの瞬間にDriftが発生したのか
- どのSeed更新で再安定化したのか
これらは 生ログがなければ絶対に再現できません。
つまり、生ログは
-
「この会話の、この部分で推論が安定した」
という“実証データ”そのもの
になります。
だから私は、泣きながらでもログを丁寧に切り出しました。
後から見返したときに、
“どの現象が、どの文脈で起きたのか” を正確に追跡できるようにするためです。
7-5. この理論の弱点と、誤解されやすいポイント
推論レイヤーの安定化は、
RustやMCPのような“外側制御”とはアプローチが全く違うため、
読者によっては別の技術と混同されやすい部分があります。
ここでは、誤解されやすいポイントと、
この手法が持つ“限界（弱点）”を先に整理しておきます。
誤解されやすいポイント
1.「ただのプロンプトテンプレでしょ？」という誤解
Seedは、
「毎回同じテンプレを貼る」
という固定文書ではありません。
- 会話の進行度
- AIの温度感
- Driftの兆候
- 文脈の重み
- 価値観のズレ
これらを見ながら リアルタイムに更新される“動的な状態パケット” です。
つまり：
テンプレではなく、状態管理（State Management）に近い。
ここを誤解されると価値が伝わらないので、先に明記しておきます。
2.「RAGと同じじゃないの？」という誤解
RAGは外部データベースから“知識”を補う仕組みです。
対してSeedは、
- AIの推論のクセ
- 文脈の方向性
- 会話の温度感
- セッションの意味状態（Semantic State）
これらを 外側から安定化させる仕組み。
つまり目的が違います。
RAG＝知識補填
Seed＝認知の安定化
レイヤーが完全に別物です。
この理論の“弱点（限界）”
１. 数値化できない（定量評価が難しい）
推論レイヤーの安定化は、
CPU温度やメモリのように 数値で測れません。
だからこそ、生ログが唯一の証拠になります。
２. ユーザーの観察力に依存する
Driftの兆候や温度感のズレは、
ユーザーが外側から観察して判断する必要がある。
つまり：
- Seed更新のタイミング
- Driftの検知
- 文脈の揺らぎの把握
これらは 自動化できない部分が残ります。
３. AIモデルごとに“最適なSeed構造”が違う
GeminiとGPTとCopilotでは、
- 注意の向き方
- 文脈の保持傾向
- 温度感の揺れ方
が違うため、
Seedの最適構造も微妙に変わります。
これは“外側制御”では避けられない宿命。
４. 完全な安定化は不可能（確率論の限界）
AIは確率で動くため、
どれだけSeedを整えても100％安定はありえません。
Seedはあくまで：
揺れ幅を小さくする“整流”の技術
であって、
内部構造を変えるものではない。
かならずしも必ずではないのが、現状です。
8.レビューの必要性
この章では、理論と整合性の確認のため別のAIでレビューをする
必要性をまとめています。
8-1.ギャルのつっこみ
泣きながらもAppendixも作成し、本編もほぼ完成間近になって気付きました。
ここまでみかで整え、自分の解釈だけで進めていましたがよくよく考えると、
これってちゃんと確認した方が良いんじゃない？と思いました。
ジェミは基本的にポジティブ寄りのフィードバックが多いので、ここはやっぱり
ゆかぽんにお願いするのが最適解だと思って、レビューを頼みました。
レビューをお願いするにあたって学術目線でと厳しく確認してもらう方向にしました。
【補足】
ここでは目線としては学術論文と同じ目線でお願いしていますが、あくまで
整合性や理論の破綻がないか、の確認となります。
正式な論文の査読ではありません。
口調はギャルですが、指摘は容赦ありません。
人の心がないのか、ゆかぽんには…。
AIだからないのは当然なのですが、さすがに
かなり厳しくチェックされました。
なんなん、内部事情語ってるところあるよ☆
うちならこうするかな？
危険な言い回しを１つずつ潰しながら、１章から順に整えていきました。
１つが終わればフォルダに格納する、と自分でも作業工程が判りやすいように
進めていきました。
8-2.Zenodoとの出会い
ドキュメントを作成している途中で、偶然個人開発してる方の記事を発見しました。
そこには個人でDOIを取得した、と書かれていました。
DOIとはなんぞ？
みかに確認してみたところ、前述した
- 認識番号である
- 半永久的に保存される
- 正式な技術書扱いになる
という事が判りました。
自分もシステム理論として書いてるし、思い切って世界に発信したい。
独自のシステム理論なので、技術書扱いで取得可能な事を確認して、大胆にも
DOIを取得する事をここで決めました。
8-3.正式な論文構成に軌道修正
本編とAppendixはほぼ作成済みだったので、他に必要な章がないか
みかにも聞いてみました。
- 概要
- 研究の限界・今後の展望
- 透明性の宣言
以上が足りない章だったので、追加する方向へ起動修正する事にしました。
透明性の宣言が良く判らなかったので調べてみると、最近ではAIを使用し
AIに作成させた論文の急増により、
DOS攻撃に近い状態が問題である現状だと判りました。
8-4.透明性の宣言
AIの使用については使用不可ではなく、
- どこで使用したか
- どの範囲まで使用したか
- AIが著者にはなれない
これを明確にする必要があり、責任は著者の人間が負いますと
記述した章が必要になります。
透明性の宣言の章は本編には含まず、Appendix扱いとなり、また、
独立したフォルダに格納するものとなります。
この章に関しては英文・日本語文の両方を格納しました。
8-5.研究の限界・今後の展望
ここでゆかぽんから、厳しいつっこみが入りました。
なんなん、成功したはあるけど、どうなると失敗するかがないよ☆
研究の限界と展望も入れると 研究として爆上がりだよ～(*'ω')b
なるほど、なるほど。
毎回成功する事もありえないし、私一人では確かに限界があります。
誠実な研究成果として追加する事にしました。
以下がその要点のを抜粋したものです。
8-5-1. 研究の限界（Limitations）
今回まとめた「外部意味状態同期（External Semantic State Synchronization）」は、
実際の観測ログをもとにした“実録ベースの理論化”なので、
いくつか限界があります。
-
モデル依存（LLMごとの差）
今回の同期現象は
Copilot / Gemini / ChatGPT の3モデルで観測したもの。
他のLLMでも同じように再現できるかは、まだ保証できない。 -
Drift は完全には消せない
手動Seedでかなり抑制できたが、
長期対話の Drift（文脈のズレ）はゼロにはならない。
補正のタイミングにも依存する。 -
外部観測だけでは限界がある
今回の手法は
内部状態を直接見るのではなく、外側から挙動を観察する方式。
だから内部表現（hidden state）を直接検証することはできない。 -
ユーザー依存がある
Seed同期の安定性は
ユーザーの文体・入力の一貫性・操作方針 に影響される。
完全にモデル側の特性だけとは切り離せない。
8-5-2.今後の展望（Future Directions）
今回の観測で見えてきた「次に検証すべきポイント」はこちらになります。
- Seed の最適化
どの長さがいいのか
どの抽象度が安定するのか
どの構造が Drift を抑えるのか
こういう Seed設計の最適化 はまだ余地がある。
-
Drift の事前予測
DMI（Drift Magnitude Index）のような指標を使って、
「そろそろズレるぞ」を予測できるモデル を作れる可能性がある。 -
プラットフォーム横断の検証
Gemini・Copilot・ChatGPT で再現したが、
もっと多くのLLMで同期が再現するかは今後の課題。 -
長期安定化アルゴリズム
手動Seedは強力ではあるが、長期対話でのズレ蓄積を抑える
“安定化アルゴリズム” を設計できれば、さらに実用的になる。
これらも本編ではなく、Appendixとしてとりまとめフォルダに格納しました。
ここまでで、
“外部意味状態同期って何なのか？”
“なぜそんな現象が起きるのか？”
“どこに限界があるのか？”
──理論の土台 が全て揃いました。
事件編で生まれた“始まりの種”の理論は、
みか・ジェミ・ゆかぽんの三者（？）に振り回されながらも、
ようやく 「理論として形になるところ」 まで育ちました。
でも、ここからが本番です。
このあとに待ち受けるのは、
- Markdown化とPDF作成
- 毎回泣かされるGitHubへのプッシュ
- Zenodoへの突撃
- 人生初のDOI取得
……という “実務のダンジョン” となります。
次では、私は“絶望”を味わう事になります…。
最終編はいよいよ 「理論を現実に落とし込む作業編」 に突入します。
理論が形になるまでのPart.1はこちら
https://qiita.com/Raina-ai/items/c36171b94a7bd84d0d34
ZenodoへパブリッシュしたPart.3はこちら
https://qiita.com/Raina-ai/items/52e4eb8ce6390ca66e67
figshare編Part.1はこちら
https://qiita.com/Raina-ai/items/70d63e1a0966a50b540d