はじめに

Claude Code v2.1.191（2026年6月24日リリース）で /rewind コマンドが追加されました。会話とコードの状態を任意のチェックポイントまで巻き戻せる機能で、同時に「ストリーミング応答中の描画作業量（CPU使用率）を約37%削減した」という最適化も入っています。

この記事では、公式ドキュメントとリリースノートをもとに /rewind の実際の挙動を整理し、CPU削減の元になっている「テキスト更新のコアレッシング（100ms単位への統合）」という手法を、簡易ベンチマークで自分の手元で再現して効果を確認します。

この記事で学べること

/rewind が「コード」「会話」のどちらを、どこまで巻き戻せるか
/clear 実行後でも前のセッションに戻れる仕組み
ストリーミング再描画を100msでまとめる「コアレッシング」がなぜCPUを減らすのか（自作ベンチマークで検証）

対象読者

Claude Codeを日常的に使っている方
AIエージェントに大きめのリファクタを任せて、たまに事故る方
ストリーミングUIのパフォーマンスチューニングに興味がある方

前提環境

Claude Code v2.1.191 以降（/rewind に前セッション再開機能が必要）
Node.js（本記事のベンチマークコードの実行に使用）

TL;DR

/rewind は Esc キー2回、または /rewind 入力で呼び出せる。コード・会話・両方のどれを戻すか選べる
/clear した後でも、/rewind メニュー最上部に /resume <session-id> (previous session) が出て、クリア前の会話に戻れる（v2.1.191以降限定）
ストリーミング中のテキスト更新を100msごとにまとめて描画する「コアレッシング」で、公式発表ではCPU使用率が約37%減った。同じ考え方を簡易ベンチマークで再現したところ、疑似的な再描画コストは約99%削減した（後述、条件はかなり単純化している点に注意）

背景・課題

AIコーディングエージェントに大きめのタスクを任せていると、意図しないファイル削除や広範囲の書き換えが発生することがあります。従来は git stash や git checkout -- . で手動で戻すしかなく、「会話の文脈」と「コードの状態」がズレて、どこまで戻せば良いか判断しづらいという課題がありました。

もう1つ、地味だが実用上効くのがパフォーマンスです。ストリーミング応答中は毎回テキストが追記されるたびにターミナルの再描画が走るため、長い応答ほどCPU負荷が積み上がります。Claude Codeはこの2つの課題に、同じv2.1.191で同時に手を入れています。

`/rewind` の仕組み

巻き戻せる対象は「コード」「会話」の2種類

/rewind を実行すると、セッション内のチェックポイント一覧が表示されます。各チェックポイントに対して、以下のどれを復元するかを選択できます。

復元対象	説明
コードのみ	ファイルの変更だけ元に戻す。会話の文脈は保持したまま続けたい場合
会話のみ	会話履歴だけ巻き戻す。ファイルの変更はそのまま活かしたい場合
コード＋会話	両方を指定時点に戻す。まるごとやり直したい場合

呼び出し方法は2通りです。

# 方法1: スラッシュコマンド
/rewind

# 方法2: Escキーを2回押す
Esc Esc

`/clear` 後でも前のセッションに戻れる

/clear はその場の会話履歴を消してコンテキストをリセットするコマンドですが、v2.1.191以降は同一プロセス内で /clear を実行していた場合、/rewind メニューの最上部に次のエントリが追加されます。

/resume <session-id> (previous session)

これを選ぶと、/clear する直前まで有効だった会話に復帰できます。このエントリは「Claude Codeを終了する」か「別のセッションを resume する」までの間だけ有効です。v2.1.191より前のバージョンでは、代わりに /resume コマンドを実行して一覧から前のセッションを手動選択する必要があります。

「うっかり /clear してしまったが、直前の文脈が必要だった」というケースの復旧コストが、コマンド1つ分まで下がっています。

ストリーミングCPU 37%削減の中身 — コアレッシングを自分のベンチマークで再現する

公式リリースノートでは、ストリーミング応答中のテキスト更新を 100ms単位にまとめて描画する（コアレッシング） ことで、フレーム単位の再描画コストが減り、CPU使用率が約37%下がったとされています。

考え方自体はシンプルです。トークンが届くたびに毎回ターミナルを再描画すると、1回あたりの処理は軽くても回数が膨大になります。届いたテキストを短い時間窓（100ms）でバッファし、まとめて1回だけ描画すれば、再描画の回数そのものを大きく減らせます。

筆者はこの「まとめて描画すると再描画回数が減ってコストが下がる」という考え方が実際どの程度効くのか気になったので、Node.jsで簡易的に再現してみました。ターミナルの実描画コストの代わりに「文字列を結合してチェックサムを計算する」という軽い処理を「再描画」に見立て、(1) 1文字届くたびに毎回実行する場合と、(2) 200文字（20,000文字のストリームを100個の描画イベントに相当するよう近似した窓）ごとにまとめて実行する場合を比較しました。

// coalesce-bench.js
const TOTAL_CHARS = 20000;
const CHUNK = "The quick brown fox jumps over the lazy dog. ";

function fakeRender(buffer) {
  // 実際のTUI再描画コスト（差分計算・ANSI再構築）を模した軽い計算処理
  let sum = 0;
  for (let i = 0; i < buffer.length; i++) sum = (sum + buffer.charCodeAt(i)) % 997;
  return sum;
}

function benchPerCharacter() {
  let buffer = "";
  const start = process.hrtime.bigint();
  let renderCount = 0;
  for (let i = 0; i < TOTAL_CHARS; i++) {
    buffer += CHUNK[i % CHUNK.length];
    fakeRender(buffer); // 1文字来るたびに毎回再描画
    renderCount++;
  }
  const end = process.hrtime.bigint();
  return { ms: Number(end - start) / 1e6, renderCount };
}

function benchCoalesced100ms() {
  let buffer = "";
  const start = process.hrtime.bigint();
  let renderCount = 0;
  const BATCH = 200; // 目安: 100ms窓に届く文字数
  for (let i = 0; i < TOTAL_CHARS; i++) {
    buffer += CHUNK[i % CHUNK.length];
    if ((i + 1) % BATCH === 0 || i === TOTAL_CHARS - 1) {
      fakeRender(buffer);
      renderCount++;
    }
  }
  const end = process.hrtime.bigint();
  return { ms: Number(end - start) / 1e6, renderCount };
}

const a = benchPerCharacter();
const b = benchCoalesced100ms();
console.log("1文字ごと:", a);
console.log("100ms窓コアレッシング:", b);
console.log(`削減率: ${((a.ms - b.ms) / a.ms * 100).toFixed(1)}%`);

手元（このセッションのコンテナ環境）で実行した結果は以下の通りです。

=== 1文字ごと再描画 ===
  所要時間: 830.12ms / 再描画回数: 20000
=== 200文字（≒100ms窓）ごとにコアレッシング ===
  所要時間: 5.28ms / 再描画回数: 100
削減率: 99.4%

再描画回数が20,000回から100回に減ったことで、疑似コストは99%以上削減されました。もちろんこれは「再描画コストが文字数にほぼ比例する」という単純化した仮定のもとでの数値で、実際のターミナル描画・ネットワーク遅延・OSごとの差を含む公式計測（約37%削減）とは前提が異なります。ただし「なぜコアレッシングが効くのか」という原理そのものは、この簡易ベンチマークでも明確に確認できました。再描画のような「1回あたりは軽いが頻度が高い処理」は、時間窓でまとめるだけで大きく減らせるというのは、Claude Code以外の自作ツールでストリーミングUIを実装する際にも応用できる知見です。

著者視点の発見ポイント

今回リリースノートを読んで意外だったのは、/rewind が「コード」と「会話」を独立に巻き戻せる設計になっている点です。単純な git revert 的発想だと両方セットで戻すのが自然に思えますが、AIエージェントとの対話では「会話の文脈は活かしたまま、直前の書き換えだけ取り消したい」という場面が実際には多く、この分離こそが実務で効くポイントだと感じました。あわせて、コアレッシングのベンチマークを自分で書いて動かしてみると、公式発表の「37%」という数字は決して大げさな最適化ではなく、むしろ保守的な見積もりに見えるほど、時間窓での処理まとめは効果が大きい手法だと実感できました。

まとめ

/rewind はコード・会話・両方を選んで任意のチェックポイントに戻せる（Esc2回 or /rewind コマンド）
/clear 後でも /resume <session-id> (previous session) で直前の会話に復帰できる（v2.1.191以降）
ストリーミング中のテキスト更新を100ms窓でコアレッシングすることでCPU使用率が約37%減少。簡易ベンチマークでも「まとめて処理すると再描画回数が激減する」効果を確認できた
「1回は軽いが頻度が高い処理をバッチングする」という考え方は、自作のストリーミングUIにも転用できる

参考リンク