Claude Codeの自動要約が早い｜2.1.273で修正

「長い作業を任せると、途中で前提を忘れて作り直しになる」「まだ余裕があるはずなのに、勝手に会話が要約される」——AIコーディングツールを日常的に使っていると、誰もが一度はこの不便に突き当たります。

結論から言うと、その一部は使い方の問題でも、モデルの限界でもありませんでした。Claude Code 2.1.273 で、文脈メーターと自動要約（auto-compact）が一部のやり取りを実際の約2倍の大きさに数えており、その結果、自動要約が実際の窓の約半分で発動していた不具合が修正されました。つまり「まだ半分も使っていないのに要約された」は、体感ではなく事実だったことになります。

株式会社Fyveは、自社の業務を無人のAIジョブで回しながら、中小企業のAI活用を支援しています。この記事では、2.1.273 の公式な変更履歴（一次情報）をもとに、何が直ったのか・自分が影響を受けていたかをどう確かめるか・そして「安定版を選んでいる人ほど注意が必要」という構造を、実際の観測データとあわせて整理します。

結論：自動要約が早く走っていたのは、残量の数え間違いだった

2026年9月15日に公開された Claude Code 2.1.273 の変更履歴に、次の一行があります。

Fixed the context meter and auto-compact counting advisor-tool turns at roughly twice their real context size, which made auto-compact fire at about half the real window

（文脈メーターと自動要約が、助言系ツール（advisor tool）のやり取りを実際の文脈サイズのおよそ2倍に数えていたのを修正した。これにより自動要約が、実際の窓の約半分で発動していた）

「文脈の窓」とは、AIが一度に覚えていられる会話の容量のことです。机の広さに例えるとわかりやすく、机が埋まってくると、AIはそれまでの会話を短く要約して場所を空けます。これが自動要約（auto-compact）です。

「約半分で発動していた」が実務で意味すること

自動要約そのものは必要な仕組みです。問題は、発動のタイミングを決める物差しが狂っていたことにあります。

残量が実際の2倍で数えられていたということは、本当はまだ半分残っている状態で「もう満杯だ」と判定されていたということです。要約は情報を圧縮する操作なので、走るたびに細部は落ちます。早く走れば走るほど、まだ捨てなくてよかった前提まで捨てられます。

実務上の影響は、次のような形で現れていたはずです。

• 長い作業の途中で、前半に決めたはずのルールをAIが忘れて、別の方針で書き始める
• 「さっき指示したはずですが」と言い直す往復が増える
• 本来1セッションで終わるはずの作業が、途中で切れて2回に分かれる
• 要約が挟まるたびに再送されるため、結果としてトークンの消費が増える

ここで重要なのは、これらのどれ一つとして「エラー」の形をしていないことです。赤い文字も、失敗のメッセージも出ません。ただ、思ったより早く要約が走るだけです。だから多くの人が「AIとはそういうものだ」「自分の指示の出し方が悪いのだろう」と結論づけて、そのまま使い続けていました。

「約2倍」「約半分」は公式の表現をそのまま使っている

なお、上の「およそ2倍」「約半分」は、いずれも公式の変更履歴が使っている表現です（roughly twice / at about half）。全員が常に正確に2倍ズレていたわけではなく、影響の大きさは使っているツールの構成によって変わります。「助言系ツールのやり取り」が対象と明記されているため、その種のやり取りが多い使い方ほど影響が大きかった、と読むのが妥当です。

同じ版に、同じ型の修正がもう2つ入っていた

2.1.273 の変更履歴を読み進めると、性質のよく似た項目がもう2つ見つかります。私がこの記事を「自動要約の話」ではなく「静かな損失の話」として書いているのは、この3つが同じ形をしているからです。

① つないだ外部ツール（MCP）が、黙って切れていた

Added a notification when an MCP server disconnects mid-session and automatic reconnection gives up, pointing at /mcp

（MCPサーバーがセッションの途中で切断され、自動再接続も諦めたときに通知を追加した。通知は /mcp を指す）

MCP（Model Context Protocol）は、AIに外部のツールやデータを接続するための規格です。カレンダー、会計ソフト、社内のファイル置き場などをAIから触れるようにする「手」にあたります。

注目すべきは、これが「Fixed（修正）」ではなく「Added（追加）」である点です。つまり切断そのものは以前から起きていて、直ったのは「知らせるようになった」ことだけです。それまでは、接続が切れて再接続も諦めた状態でも、画面上は何も変わりませんでした。

この状態でAIに作業を頼むと、何が起きるか。AIは「その道具が使えない」とは言わず、手持ちの情報だけで、それらしい答えを返します。外部データを見に行った前提で読むと、まるで確認済みのように見えてしまう——これが「つないだつもり」の一番高くつくところです。

② 下請けAIの結果が届かないのに「失敗」と報告されていた

Fixed sub-agents and background agents being reported as failed, with their result never delivered, when the final streamed reply omitted token usage or carried no model id

（最後のストリーム応答にトークン使用量が欠けていた、またはモデルIDが無かった場合に、サブエージェントとバックグラウンドエージェントが「失敗」と報告され、その結果が一度も届かなかったのを修正した）

サブエージェントは、メインのAIが仕事を切り出して任せる「下請け」です。調査・要約・並列処理などを別プロセスに投げて、結果だけ受け取る使い方をします。

この不具合の厄介さは、仕事は終わっていたのに、報告だけが失われていた点にあります。しかも失敗の理由が「応答にトークン使用量やモデルIDが欠けていた」という、作業内容とは何の関係もない伝票の不備です。

私は自宅のMac miniで、AIのジョブを毎日決まった時刻に無人で走らせています。人が見ていない前提で組む処理では、「失敗」という報告を、そのまま失敗として扱うのが普通の設計です。そこに「本当は成功しているのに失敗と報告される」経路があると、リトライが走ったり、成果が捨てられたりします。しかも記録には「失敗」としか残らないので、後から原因を追うこともできません。

③ おまけ：コマンドを打つだけで、料金が余計にかかっていた

同じ版に、性質の似た項目がもう一つあります。こちらは記憶ではなく、費用の話です。

Fixed /login, /upgrade, and /extra-usage discarding earlier thinking from the conversation, which forced a full prompt-cache rewrite on the next request

（/login・/upgrade・/extra-usage が会話中のそれ以前の思考を捨てており、その結果、次のリクエストでプロンプトキャッシュの全面的な書き直しが強制されていたのを修正した）

プロンプトキャッシュは、同じ前提を繰り返し送るときに費用と待ち時間を抑えるための仕組みです。会話の前半が変わらなければ使い回せるのですが、途中で内容が書き換わると使い回せなくなり、丸ごと送り直しになります。

つまり、ログインし直しただけ・プランを確認しただけで、次の1回が余計に高くついていたことになります。これも画面上は何も起きません。請求の内訳にも「この操作が原因です」とは書かれません。

4つに共通するのは「エラー画面が出ない損失」

この4つを並べると、共通項がはっきりします。

• 自動要約が早すぎた → エラーは出ない。ただ記憶が早く薄れる
• 外部ツールが切れていた → エラーは出ない。ただ道具が使われない
• 下請けの結果が消えた → 「失敗」とは出るが、原因とは無関係な理由で、実際には成功していた
• キャッシュが捨てられていた → エラーは出ない。ただ次の1回が高くつく

赤い文字が出る不具合は、放っておいても誰かが気づきます。厄介なのは、静かに進行して、しかも「自分の使い方が下手なせいだ」と誤解させる類の不具合です。使う側が自分を責めている限り、この種の問題は報告もされず、直りもしません。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →↓

自分が影響を受けていたかを確かめる3つの手順

ここからは実務の話です。難しい作業はありません。

手順1：いま自分が使っている版を確かめる

ターミナルで次を実行します。

claude --version

表示された番号が 2.1.273 より小さければ、上で挙げた3つの修正はまだ入っていません。

手順2：更新する

導入方法によって更新の手順は変わります。npm で入れているなら次の形です。

npm install -g @anthropic-ai/claude-code@latest

公式のインストーラやパッケージマネージャ（apt / dnf など）で入れている場合は、そちらの更新手順に従ってください。ここで一つ落とし穴があります——後述する「安定版」を選んでいる場合、@latest と同じものは降ってきません。

手順3：「直ったかどうか」を何で見るかを決めておく

更新したあと、体感で判断しようとすると必ず迷います。先に見る場所を決めておきます。

• 自動要約について：長めの作業を1本流して、要約が挟まる回数が以前より減ったかを見る。回数そのものが指標になります
• MCPについて：接続が切れたときに通知が出るようになったので、「通知が出ていない＝つながっている」と読んでよくなりました。これは運用の前提が1つ増えたということです
• サブエージェントについて：無人で回している処理があるなら、過去の「失敗」記録を一度見直します。成果物は出来ているのに失敗と記録されている回があれば、それが該当します

無人運用の記録設計については、別の記事で詳しく書いています。

Claude CodeClaude Codeの無人運用ログ設計｜サブエージェント可視化

「安定版」を選んでいる人には、もう一段の注意がいる

ここからが、今回いちばん実務に効く部分です。

Claude Code には複数の配布経路があり、その一つが「安定版（stable）」です。公式のセットアップ文書は、安定版を「おおむね1週間ほど前のもの」と説明しています。頻繁な変更を避けたい組織が選ぶ経路です。

その安定版が、4週間近く動いていなかった

公開されている不具合報告 #92274（2026年9月5日起票・現在もオープン）は、次のように記録しています。

The stable release channel stopped advancing after 2.1.236, released 2026-08-19.（安定版の配布経路は、2026年8月19日公開の 2.1.236 の後、前に進むのをやめた）

The stall is silent, so it looks identical to being current.（この停滞は静かなので、最新である状態と見分けがつかない）

報告は、apt / rpm などのパッケージ配布面でも同じ 2.1.236 が配られ続けていたこと、一方で latest 側は先に進んでいたことを挙げています。

私が7日連続で観測していたもの

私は毎朝、AIツールの配布状況を定点観測して記録しています。npm レジストリの配布タグ（dist-tag）を見ると、次のようになっていました。

• 9月10日〜9月16日：stable は 2.1.236 のまま（7日連続で同じ値を記録）
• 同じ期間、latest は 2.1.266 → 2.1.267 → 2.1.270 → 2.1.272 → 2.1.273 と進み続けていた
• 9月17日の朝：stable が 2.1.267 へ移動していた

つまり「安定版」を選んでいた人は、9月16日まで8月19日の版を使い続けていたことになります。そして翌朝、まとめて前に進みました。

版番号は31進んだが、実際の更新は23回ぶん

ここは正確に書きます。2.1.236 から 2.1.267 へは、版番号の上では31進んでいます。ただし番号が飛んでいる箇所があるため、実際に配布された更新の回数は23回でした（npm レジストリの公開記録より）。

いずれにせよ、約1ヶ月ぶんの変更が一度に降ってきたことに変わりはありません。そして注意すべきは、今回移動した先の 2.1.267 にも、この記事で扱った3つの修正はまだ入っていないということです。それらが入ったのは 2.1.273 です。

「安定版だから変わらない」ではなく「溜まって一度に来る」

ここで運用の考え方を1つ入れ替える必要があります。

安定版を選ぶ動機は、たいてい「勝手に変わってほしくない」です。ところが実際に起きたのは、変更が来ないことではなく、変更が溜まって一度に来ることでした。

結論はシンプルです。安定版を選んでいるなら、「変わらないから見なくていい」ではなく「動いた日にだけ、まとめて確認する」を運用に入れる。動かない期間は何もしなくていいので、手間はむしろ減ります。

同じ型の損失を、他の道具でも見つける

ここまでは Claude Code の話でしたが、「エラーを出さずに損をさせる」構造は、この道具に固有のものではありません。AIを業務に組み込むほど、同じ型が増えます。自分の環境を点検するときの問いを4つに整理しました。

問い1：それは「動いていない」のか「動いているつもり」なのか

連携・同期・自動実行のたぐいは、止まったときに沈黙します。成功したときだけ通知が来る設計は、止まったことを教えてくれません。今回のMCP切断がまさにこれでした。定期実行しているものがあるなら、「動いたら知らせる」ではなく「動かなかったら知らせる」側の通知があるかを確認します。

問い2：その「失敗」は、本当に仕事が失敗したのか

失敗の記録を、失敗の証拠として扱っていないかという問いです。今回のサブエージェントの件は、仕事は成功していて、伝票だけが不備だったケースでした。記録に「失敗」としか残らない設計だと、この区別が永久につきません。成果物の有無と、報告の成否を、別々に残しておく価値はここにあります。

問い3：その数字は、何を測っているのか

今回の本題は、残量メーターが実際の2倍を表示していたという話でした。メーターが狂っていても、メーターは動き続けます。使用量・残量・進捗のように「自分では検算しない数字」ほど、狂っていても気づけません。ときどき、別の方法で突き合わせてみる価値があります。

問い4：その費用は、何に対して払ったのか

キャッシュの件のように、操作と請求が結びつかない形で費用が増えることがあります。月額が想定より高いときに「使いすぎた」で片付けず、内訳の形が変わっていないかを見る。これは今回に限らず、AIの従量課金と付き合ううえで効きます。

静かな損失に気づくための、日常の運用

今回の3つは修正されました。しかし同じ型の問題は、これからも出ます。エラーを出さない不具合は構造的に発見が遅れるからです。そこで、気づく確率を上げる運用を3つだけ挙げます。

①「そういうものだ」と諦めた挙動を、1行ずつ書き留める

いちばん効くのがこれです。「途中で忘れる」「たまに繋がっていない気がする」といった、報告するほどでもないと感じて流している違和感を、日付つきで1行だけ残しておきます。

これを残しておくと、変更履歴に「直った」と書かれたとき、自分に関係あるかどうかを即座に判定できます。逆にメモが無いと、修正が公開されても素通りします。今回の「自動要約が早い」も、諦めて受け入れていた人のほうが多かったはずです。

② 更新履歴は「新機能」ではなく「修正」の欄から読む

新機能は、使うかどうかを自分で選べます。一方で「直った」は、取りに行かないと手元に届きません。しかも今回のように、直ったことで運用の前提が変わる（＝通知が出るようになったので、出ていないことを根拠にできる）場合があります。

更新履歴のどこをどう読むかは、手順として整理してあります。

Claude CodeClaude Code更新履歴の読み方｜新機能より「直った」欄

③ 文脈は「会話に溜める」のではなく、外に置く

今回の不具合は、自動要約が早く走ることでAIの記憶が早く薄れる、という形で現れました。裏を返せば、会話の中にしか無い情報ほど、要約で失われやすいということです。

守るべき前提（合格の定義、禁止事項、出力の形）は、会話ではなくファイルに書いて毎回読ませる形にしておけば、要約がいつ走っても消えません。これは今回の修正とは無関係に、常に正しい設計です。

Claude CodeClaude Codeのコンテキストが消える問題の解決法

よくある質問

更新すれば、AIが前提を忘れる問題は完全になくなりますか

いいえ。文脈の窓には元々上限があり、長い作業では要約はいずれ走ります。今回直ったのは「本来より早く走っていた」という誤差の部分です。発動が正しいタイミングに戻る、と理解するのが正確です。

自分が影響を受けていたか、後から確かめる方法はありますか

過去に遡って正確に測る方法はありません。ただし、同じ種類の長い作業を更新前後で1本ずつ流し、要約が挟まった回数を比べるのが最も現実的です。変更履歴が対象を「助言系ツールのやり取り」と限定しているため、その種のやり取りが少ない使い方では差が小さい可能性もあります。

安定版をやめて最新版に切り替えるべきですか

一概には言えません。安定版を選ぶ理由（検証の手間を抑える、環境を揃える）は今も有効です。ただし今回わかったのは、安定版でも「動かない」のか「止まっている」のかを外から見分けられないことです。どちらを選ぶにせよ、月に1度は自分の版と最新版の差を見る習慣を入れてください。

MCPの切断通知は、設定が必要ですか

変更履歴上は、セッション途中の切断と自動再接続の断念に対して通知が追加された、という記述です。特別な設定への言及はありません。接続状態を確認したいときは /mcp で確認できます。

無人でAIを動かしている場合、何から手をつけるべきですか

まず版を上げること、次に過去の「失敗」記録を見直すことです。成果物が存在するのに失敗と記録されている回があれば、今回の修正に該当する可能性があります。あわせて、失敗時に何を残すかを決めておくと、次に同じことが起きたときに追えます。

更新すると、別のところが壊れませんか

可能性はゼロではありません。だからこそ、まとめて23回ぶん降ってくる状態を避けるほうが安全です。小さく頻繁に上げるほど、何が原因かを切り分けやすくなります。安定版の停滞が実務上の問題になるのは、この切り分けができなくなるからです。

まとめ

今回の要点を整理します。

• Claude Code 2.1.273（2026年9月15日公開）で、文脈メーターと自動要約が一部のやり取りを約2倍に数え、自動要約が実際の窓の約半分で発動していた不具合が修正された
• 同じ版に、MCPの切断が無通知だった問題（通知を追加）と、サブエージェントの成功が「失敗」と報告されていた問題（修正）が入っている
• 3つに共通するのはエラー画面が出ないまま損をしていたこと。使う側が「自分のせい」と誤解しやすい型である
• 安定版（stable）は8月19日の 2.1.236 から4週間近く動かず、9月17日に 2.1.267 へまとめて移動した（版番号で31、実際の更新回数で23回ぶん）。その 2.1.267 にも今回の3つの修正はまだ入っていない
• 運用としては、諦めた違和感を1行ずつ残す・更新履歴は「修正」欄から読む・守るべき前提は会話でなくファイルに置くの3つが効く

道具の不調を自分の腕のせいにしないために必要なのは、変更履歴を毎日読むことではありません。動いた日にだけ見る、という運用を1つ決めておくことです。私たちが支援の現場で最初に整えるのも、たいていこの種の「気づける状態」のほうです。

参考にした情報源

• Claude Code CHANGELOG（公式・2.1.273 の項）: https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md
• Claude Code 公式ドキュメント（変更履歴）: https://code.claude.com/docs/en/changelog
• npm レジストリ @anthropic-ai/claude-code（配布タグと公開日時の一次記録）: https://registry.npmjs.org/@anthropic-ai/claude-code
• GitHub Issue #92274「stable channel has not advanced past 2.1.236 since Aug 19...」: https://github.com/anthropics/claude-code/issues/92274

本記事の版番号・公開日時は2026年9月17日時点のものです。更新の状況は変わるため、実際の導入時にはお手元の環境で claude --version と最新の変更履歴をご確認ください。