0｜#23の結論（前提）
AIが急に重たくなる主因は、ほぼこれです。
計算負荷の増大 ＋ ブラウザ側メモリ圧迫
モデル側（構造）
会話履歴が伸びるほど、Self-Attentionの参照範囲が増えます。
さらに巨大contextではKV cacheが肥大化し、データ転送が律速になる局面も出ます。
ブラウザ側（物理）
Chromeはタブを長時間保持すると、履歴・キャッシュ・拡張機能の影響が積み上がります。
その結果、タブ自体が“物理的に”重くなります。
※このページは「原因説明」ではなく、「壊れない運用の置き方」を目的にしています。
1｜最短で効く：5つの運用ルール
時間がない人はここだけ実装してください。これが“運用設計の最小セット”です。
- 1スレッド＝1目的。 戦略・コード・UI・画像を同居させない。
- 固定したら分岐。 形が見えたら保存し、新スレッドで続ける（Freeze → Fork）。
- 履歴を捨て、差分で渡す。 「現状＋diff」だけをAIに渡す。
- ブラウザ再起動は“予定”で行う。 重くなってからでは遅い。
- 復旧はフローで行う。 リロード連打ではなく、最短手順で戻す。
2｜“重くなる”典型パターン
重くなるのは「運が悪い」からではありません。
だいたい、同じパターンで起きます。
パターンA｜ソースコード応酬（Ping-Pong）
- 長いHTML/JS/CSSを貼って、微修正を何度も繰り返す
- 履歴が“差分ログ”として肥大化し、参照負荷が増える
対策：diff運用（必要な差分だけ渡す）＋ スレッド分岐（一定量で切り替える）
パターンB｜UI開発応酬（見た目調整の連鎖）
- フォント、余白、色、配置を“その場で”詰め続ける
- 結果、会話が長期化し、ブラウザもAIも同時に重くなる
対策：一旦固定→チェックリスト確認→次スレッドで微調整
パターンC｜戦略＋実装＋画像を同一セッションに詰め込む
- 戦略議論しながらコードも触り、画像も作る
- 制約が増え続け、AIが“保持すべき前提”を抱え込みすぎる
対策：役割で分割（Plan / Build / Verify / Publish）
3｜セッション設計（分割の型）
ここが本質です。
「切る」のではなく「構造を置く」。
Type 1｜PLAN（整理）
目的、制約、完成条件だけ。
コードは貼らない。スレッドを短く保つ。
Type 2｜BUILD（実装）
実装だけ。
ベースファイル＋差分要求で動かす。
Type 3｜VERIFY（検証）
動作確認、コンソール、チェック項目。
“証拠”を残す。
Type 4｜PUBLISH（公開）
OGP、リンク、SNS文、更新履歴。
出す作業だけに閉じる。
合図：
「説明が長くなってきた」「過去の前提を何度も参照している」
これが出たら、Freeze → Fork のタイミングです。
4｜引き継ぎ（新チャット移行）
スレッドが重くなったと感じたら、それは「思考の分岐点」です。
迷わず現在の状態を凍結（Freeze）し、新しいスレッドへ移行（Fork）します。
移行のトリガー
- 出力の物理的な遅延：プレビュー生成が30秒を超えた、明らかに重たいと感じる。
- 直前のやり取りの無視：さっき合意したはずの「CSS変数」や「構造上の制約」を無視した回答が返り始めた。
- 修正ループの発生：同じエラーを指摘しても、古いコードを使い回して改善が見られない。
新スレッドに持っていくもの
- 最新の全文コード：「diff運用」を適用した後の最終結果。
- 現在の到達点：「何が実装済み」で「何が未完了」か。
- 構造上の制約：デザイン規約や、絶対に崩してはいけないロジックの前提。
運用設計の要諦：
新スレッドの冒頭で「これまでの経緯を要約して」と頼むのは禁止。自身が「ここからこれをやる」と定義した、最もクリーンなコードだけを渡すのが最短ルート。
4.1｜実践：移行フロー
「重さ」を感じてから、新スレッドで開発を再開するまでの最短3ステップ。
今のスレッドで「最新の全文コード」を出力させ、手元に保存。これが唯一の正解（Source of Truth）となる。
「次に着手する1点」と、それを実現するために「崩してはいけない制約」だけを箇条書きで抜き出す。
新しいチャットを立ち上げ、STEP1のコードとSTEP2の要件だけを投入。「ここから再開」と宣言する。
5｜プロンプト設計（diff運用）
“全文貼り直し”は、重くなる最短ルートです。
AIには「現状＋差分（diff）」だけを渡すのが鉄則です。
｜差分運用のメリット
- 履歴の肥大化防止：AIが保持するコンテキスト（KV cache）を節約し、回答速度を維持します。
- 精度の向上：修正範囲を限定することで、意図しない場所の勝手な書き換えやデグレードを防ぎます。
｜コード応酬の引き際
- 修正が3往復を超えたら、一旦固定（Freeze）します。
- 全文を保存し、新スレッドへ移行（4.1のフローへ）してください。
5.1｜実践：diff指示テンプレ
AIに「どこを、どう変えるか」だけを出力させるための、最小限の入力セットです。
｜運用設計のコツ：
「全部書き直して」ではなく「このブロックだけ置換して」とターゲットを絞り込むことが、ブラウザのフリッカーを防ぐ最大の防御策になります。
5.2｜ブラウザ設計（Chromeメモリ）
AI側だけを疑うと、復旧が遅れます。
ブラウザ側の“物理限界”を運用設計に入れてください。
｜実戦：描画トラブル・フリッカー対策
画面の点滅や操作不能は、GPUプロセスの限界サインです。以下の物理リセットを試してください。
1. Shift + Esc で「GPUプロセス」を強制終了する。
2. Chrome設定 で「ハードウェアアクセラレーション」をオフにする。
3. 改善しない場合は、OSを再起動してください。
｜症状：ブラウザ全体が重い
これはメモリ・GPU側の疑いが濃厚です。
GPUリセット → Chrome再起動 → それでもダメならMac再起動。
｜症状：AIタブだけ重い
これはセッション（KV cache）肥大の疑いが濃厚です。
「4.1｜実践フロー」に従い、スレッドを即座に分岐（Fork）してください。
6｜復旧フロー（重くなった後）
リロード連打は、状況を悪化させることがあります。
“最短で戻す手順”を決めておく。
- Freeze： 直近の成果物（コード／決定事項）をローカルに保存
- Fork： 新スレッドを起こし、現状＋diffだけ渡す
- Reset： タブ整理、必要ならChrome再起動
- Verify： 受け入れ条件を1つだけ確認（コンソールも1回だけ）
- Resume： 小さな単位で進行し、早めに分岐する
やらないこと
- 全文貼り直しを繰り返さない
- 目的を増やして“混ぜない”
- 重いまま引っ張って完走しようとしない