Claude_Code_セッション品質の差
なぜセッションによって「超優秀」と「めっちゃ無能」が分かれるのか
大串の実感「最近、動きが超良い優秀なセッションと、めっちゃ無能なセッションが分かれてる気がする」への答え。気のせいではなく構造的な差がある（2026-07-14 整理）。
30秒サマリ
「無能セッション」の正体 = コンテキストが重い/汚染された状態。
長い ＋ 巨大ログを読んだ ＋ 高速モード ＋ エラー繰り返し
↓
指示を外す・固まる・英語混入 ＝「無能」に見える
「優秀」＝まだ身軽（短い・読んだ量が少ない）。「無能」＝重い。
差を生む主因（大きい順）
① コンテキストの重さ（最大要因）
会話が長い・大量のファイル/ログを読むほど劣化する:
- 最新の指示より過去の文脈に引っ張られる（例: 「github読み込んで」→勝手に着手）
- 細かい指示の追従が落ちる
- 英語が混ざる・固まる
→ 特に 巨大ファイル/ログの全読みは一気に重くする（だから引き継ぎは --handoff で機械抽出し、モデルに全読みさせない設計にした → 22_AI運用ルール/セッション引き継ぎ体制）。
最大の主犯＝画像/スクショ（2026-07-15 実測で確定）: 画像1枚 ≒ テキスト数千文字分のトークン。今日の重かったmikkeセッションは 画像365枚（表示確認の computer-use 129回＋大串のスクショ）でコンテキストを食い尽くしていた。対比: CLAUDE.md 19KB + memory索引 26KB = 45KB（＝画像数枚分）。「いらない情報の保存(memory)」は主因ではない——整理しても桁違いに効果が小さい。画像を減らすのが肥大対策の本丸。
設計＝情報を3層で読む（大串案 2026-07-15）: 情報は蓄積してよい・でも状況に応じて読む場所を絞る。【土台】CLAUDE.md=常時（全作業の前提・薄く固定）／【スコープ】スタートカード・関連ノート=その作業の時だけ（site_snapshot が該当リポだけ読む）／【詳細】個別memory・Vaultファイル=必要になった時だけ（オンデマンド）。状況に関係ない情報を読ませない。
② reasoning effort「高」＋高速モード（固まりの主因）※2026-07-14 実証・最重要
reasoning effort「高」でツール実行(Bash/Read)が絡むと固まりやすい（8分・17分ハングの実例）。大串が effort「高」→「低」 に切り替えたら一発で解決し、サクサク動いた。
- システム作業（git操作・ファイル編集・デプロイなど"手を動かす"作業）は effort「低」推奨 — 複雑な推論が不要なので、低で速く・正確・固まらない
- 深い設計・分析・戦略相談は「高」でよい（じっくり考える価値がある作業）
- 高速モード(Fast)も同様にツール実行と相性が悪いことがある。まず effort「低」を試す
③ モデルの違い
セッションで Opus（賢い）か他かが違うと、地力の差が出る。
④ スタート地点の良し悪し
最初に現在地・ルールをちゃんと把握したセッションは終始優秀。曖昧・情報過多スタートは迷走。
⑤ 一度崩れると戻らない（汚染）
英語混入・誤動作が一度出ると、その悪い状態がコンテキストに residue として残り、以降ずっと調子が悪い。粘っても回復しない。
優秀に保つコツ（実用）
| コツ | 理由 |
|---|---|
| 表示確認のスクショを最小限に（肥大対策の本丸） | 画像1枚=テキスト数千字分。365枚で肥大した実例。数値/ファイル検証を優先し、スクショは要所だけ・毎回撮らない |
| 1セッション=1テーマ、こまめに区切る | 長くしない＝身軽を保つ（特にデザイン調整など画像多用作業） |
| おかしくなったら粘らず新セッション | 汚染は回復しない |
| 巨大ファイルの全読みを避ける | 一気に重くなる |
| システム作業は reasoning effort「低」にする（最重要） | 高だとツール実行で固まる（8分/17分ハングの実例）。低で速く・正確・固まらない。深い相談だけ「高」 |
不安定なら高速モードを切る（/fast） |
ツール実行が安定する |
| 1システム=1セッション | 文脈の混線を防ぐ（既存ルール） |
関連
- Claude_Code_容量不足対策（容量・画像リサイズ）
- 22_AI運用ルール/セッション引き継ぎ体制（壊れたセッションの引き継ぎ2ルート）
- Claude_Code_handoff_コマンド仕様（区切りの引き継ぎ）