個人開発でアプリを作っていると、1日のうちに何時間もClaude Codeと同じセッションで作業することがあります。最初は快調だったのに、夕方になって「なんだか指示が通らない」「さっきまで覚えていた前提を忘れている」と感じたことはないでしょうか。私自身、数えきれないほどこの壁にぶつかってきました。
ここではその「ふと落ちる瞬間」を偶然任せにしない運用についてお話しします。長時間セッションの精度を守るための検知方法、境界設計、そして軌道修正の具体的な手順を順にご紹介します。私の実装現場で試行錯誤してきた内容なので、公式ドキュメントには載っていない判断基準も含めています。
なぜ長時間セッションで精度が落ちるのか
Claude Code のコンテキストウィンドウは広大ですが、無限ではありません。さらに重要なのは、容量の上限に達する前から「実質的な劣化」が始まっているという事実です。
実質的な劣化とは、モデルがコンテキスト全体を参照できていても、関係の薄い情報に引きずられて判断が鈍る状態を指します。私の観測では、ファイル読み取りが40回を超えたあたりから兆候が出始め、100回を超える頃には初期の精度を保てなくなる印象があります。これはトークン数ではなく「情報の密度と関連性」の問題です。
Auto-Compaction（自動圧縮）が入ると表面上のトークン数はリセットされますが、圧縮プロセス自体が情報を失わせるため、劣化を止める特効薬にはなりません。むしろ重要な文脈が要約されて消えることで、予期しない挙動の原因になることもあります。
劣化の典型的な兆候 — 早期検知リスト
運用してきて気づいた、精度が落ち始めるシグナルを具体的に挙げます。複数同時に出たら要注意です。
1. 変数名や関数名の取り違えが増える
さっきまで UserProfile と書いていた型が、急に userProfile や User に揺れ始めます。命名の一貫性はモデルが内部で保持している「設計意図」のバロメーターです。ここが崩れると、その先の提案も信用度が下がります。
2. 同じ質問を繰り返し聞かれる
「このファイルのパスはどこですか」「テストフレームワークは何を使っていますか」と、セッションの序盤で答えた質問が再度出てくる場合は、該当情報がコンテキスト内で他の情報に埋もれている可能性が高いです。
3. 直前の修正を踏まえていない提案が出る
例えば5分前に async/await に書き換えたばかりの関数について、再び Promise.then() のチェーンで書き直そうとします。「さっき直したばかりじゃないですか」という類の事故は、コンテキストの後半部分の重みが軽くなっているサインです。
4. 確認なしで破壊的な変更を提案する
セッション序盤では「念のため確認しますが」と聞いてきたはずの操作を、終盤では確認なしで実行しようとします。これは指示の趣旨が薄れてきた証拠です。
セッション境界の見極め方
兆候が出てから慌ててセッションを切ると、作業中の文脈を失ってしまいます。そこで私は、「作業単位」と「セッション単位」を最初からずらして設計しています。
作業を先に区切る
1つのタスクを「機能追加 → テスト → レビュー → デプロイ準備」のように4段階に分割し、各段階の終わりを自然なセッション切り替えポイントとして設計します。これだけで、劣化を感じる前に切り替えるリズムが作れます。
引き継ぎ情報を1ファイルに集約
セッション終盤に入る前に、次セッションへ渡す情報を1つのMarkdownファイル（私は SESSION_HANDOFF.md という名前にしています）にまとめます。新セッション開始時に、このファイルを最初に読ませるだけで、大半の文脈を最小コストで引き継げます。
# セッション引き継ぎメモ
## 現在の作業
- 機能: ユーザープロフィール画面のAPI連携
- 完了: エンドポイント呼び出しの基礎実装
- 未完了: エラー時のリトライ処理 + テスト追加
## 重要な決定事項
- 認証は既存の `useAuth` フックを使う（新規作成しない）
- エラー表示は `ErrorBanner` コンポーネントに統一
- リトライは最大3回、指数バックオフ
## 注意点
- `src/hooks/useProfile.ts` は他画面でも使われているため、破壊的変更禁止
- テストは `__tests__/profile.test.ts` に追加するこのメモは次セッションの冒頭数百トークンで最重要情報を提示するため、コンテキスト内の「情報密度」を高く保てます。長いプロンプトを投げて誘導するより、はるかに効率的です。
境界を越える前の最終チェック
セッションを切る直前に、Claude Code に「このセッションでやり残したこと、忘れてほしくないことを箇条書きにしてください」と依頼します。これが次セッションの引き継ぎメモのたたき台になります。モデル自身が把握している未完了項目を可視化することで、人間が気づかなかった認識ずれを発見できます。
途中で軌道修正するための検査手順
セッション境界まで待たず、途中で「これ精度落ちてきたな」と感じたときに使う検査手順もご紹介します。
ステップ1: 構造理解の確認
「今のプロジェクト構造を3行で説明してください」と聞きます。抽象的で曖昧な説明が返ってきたら要注意です。具体的なディレクトリ名や役割が出てこない場合、コンテキストの認識が薄れています。
ステップ2: 直近の変更の要約
「この30分で私たちが変更したファイルと、その理由を教えてください」と聞きます。ここで時系列や因果関係が曖昧だったら、中間の判断プロセスが失われている可能性があります。
ステップ3: 意図的な誘導質問
既に決定済みの事項について、あえて「〇〇の方が良いのでは？」と逆方向の提案をしてみます。しっかり記憶できていれば「先ほど△△の理由で現行案を選びました」と答えますが、劣化していると提案に流されて方針を揺らします。
この3ステップで2つ以上問題があれば、セッションを切るサインです。無理に続けるより、引き継いで次に進む方が結果的に早く終わります。
プロンプト設計で劣化を遅らせる
最後に、そもそも劣化を起こしにくくするプロンプト側の工夫です。
重要な前提は1箇所にまとめる
会話の中で徐々に決まった前提（型の選択、命名規則、禁止事項など）は、会話に散らさず1つのメッセージで「これまでの決定事項まとめ」として再提示します。これによりモデルが参照しやすくなります。
ファイル読み取りの前に意図を伝える
「なぜこのファイルを読むのか」を先に伝えると、モデルが必要な情報だけを抽出してくれます。漫然と読ませると、関連性の低い詳細までコンテキストを占有してしまいます。
不要になった情報を明示的に廃棄する
「さっきの〇〇の件は解決したので、これ以降は考慮不要です」と明示的に伝えます。コンテキスト内の情報が多くても、優先順位を下げれば判断に与える影響を減らせます。
私の運用ルーチン
参考までに、私が実際にやっているルーチンをお見せします。
- 朝: 前日のハンドオフメモを読ませてスタート
- 昼食前: その時点でのセッション状態を自己評価させる
- 昼食後: 新しいセッションで午後のタスクを開始
- 夕方: 疲れている時間帯は確認を多めに挟む
- 就業時: 翌日のハンドオフメモを書いて終了
このリズムで運用するようになってから、「夜にやった作業を翌朝読み返したら的外れだった」というガッカリがほぼなくなりました。長時間セッションを避けるのではなく、適切に区切って引き継ぐ。この設計が、結果的にAIコーディングの生産性を最も高めてくれています。
次にやってみてほしいこと
この記事を読んでくださったあなたに、1つだけ試してほしいことがあります。次に2時間以上Claude Codeを使うセッションで、途中に一度だけ「今のプロジェクト構造を3行で説明してください」と聞いてみてください。そこで返ってくる答えが、あなた自身の「セッション切り替え指標」の第一歩になります。
長時間セッションは避けるべきものではなく、設計するものです。少しずつ自分のリズムを見つけていけば、AIと一緒に作業する時間がもっと信頼できるものになります。