Claude Codeのtool結果保存が切れた時に確認する

結論：1GB capはtool結果をディスクへ保存する上限で、プレビューの切断と処理失敗を分ける

一次情報はClaude Code公式changelogの2.1.265、および公式monitoring usage、公式settingsです。公開直前readbackで確認できる正式な制限は「tool結果をdiskへ保存する1GB cap」と「プレビューが切れたことを知らせる表示」です。モデルのcontext、API料金、契約の保存期間へ数字を横滑りさせないようにします。

何が切れたのかを比較して判断する

確認対象	見える症状	次の判断
会話内preview	保存ファイルが切り詰められた旨が表示される	全量が必要か、範囲指定で再取得するか決める
disk上のtool結果	サイズ、更新時刻、内容の末尾を確認できる	hashと実行条件を記録し、共有可否を確認する
toolの終了状態	成功、失敗、途中停止などが残る	再実行前に重複処理と副作用を確認する
contextへの投入	結果の一部だけを読ませている	必要な範囲、要約、原本の保管場所を分ける

特に危険なのは、プレビューの見た目だけで原本の完全性を判断することです。プレビューが読みやすくても、途中で切れているかもしれません。逆にプレビューが切れていても、必要な行を別の条件で取得できることがあります。表示面と処理面を別の証跡にします。

1GBという数値は大きく見えますが、ログ、バイナリ、生成物、巨大な検索結果を一つのtool呼び出しで扱う設計は、確認者の負荷と情報漏えいの範囲を広げます。上限に届くまで使うのではなく、業務の目的に必要な最小範囲を先に決めます。

トラブル時の手順：再実行前に7項目を確認する

1. claude --versionを実行して2.1.265以降か、実行者、時刻、対象workspaceを記録します。
2. 会話内previewの表示を保存し、切断・失敗・中断のどれが明示されているかを分けます。
3. diskへ保存されたtool結果のパス、サイズ、更新時刻を確認し、秘密情報を含む場合は画面共有を止めます。
4. toolの終了状態と、データ取得・書き込み・送信などの副作用が発生したかを確認します。
5. 全量が不要なら、日付、ID、行範囲、対象ファイルを指定し、分割したread-only取得を試します。
6. 全量が必要なら、原本を承認済みの保管場所へ移し、hash、生成条件、分割単位、保存期限を記録します。
7. 再実行・削除・共有の承認者を決め、同じ副作用を二重に起こさないことを確認してから続行します。

再実行では、同じcommandをそのまま繰り返さないでください。外部システムへの更新、課金が発生する処理、ファイル生成、メール送信を含むtoolなら、まずidempotency keyやdry-runの有無を確認します。read-onlyへ分解できるなら、それを先に行います。

結果を要約する場合も、要約だけを原本の代わりにしません。要約者、対象範囲、除外した範囲、作成時刻、原本パスを記録し、後から同じ条件で再現できるようにします。個人情報や認証情報を含む結果は、必要な担当者だけに限定し、ログへ値そのものを書かない設計にします。原本を保存できない場合は、保存できなかった事実と欠落範囲を明示し、完全な証跡があるように見せないことが大切です。

企業運用の判断：上限対応をデータ分類へつなげる

チームでは、tool結果のサイズを単なる技術制限として扱わず、データ分類とレビューの入口にします。小さな結果でも機密なら承認が必要ですし、大きな結果でも公開データなら分割処理で安全に扱えます。分類、保存先、共有者、削除期限を一つのrunbookへ固定します。

既存のClaude Codeのコスト管理は契約経路と利用量、監査ログは判断記録、credential maskingは秘密情報の露出防止を扱います。このガイドは、それらの前段にある「tool結果がどこまで保存・表示されたか」を確定する検索意図です。

運用を始めるなら、まず巨大な本番ログではなく、再現可能なテストデータでpreviewの表示、diskファイル、hash、分割取得の四点を確認します。1GB capがあることを理由に、保存できる全量を会話へ投入する運用へ移行しないでください。必要な文脈だけを渡す方が、レビューも費用も管理しやすくなります。

サイズの確認は性能だけでなく、責任の境界も明らかにします。どの範囲を見て判断したかを残せば、後からpreviewだけを見た人が全量を確認したと誤解することを防げます。

チームの確認欄には「見えた範囲」と「見えていない範囲」を分けて記載します。これだけでも、previewの短い抜粋を原本全体と取り違える事故を減らせます。

チェックリスト：切断を成功と誤認しないために

Claude Codeのversionを記録したか／previewと原本を区別したか／1GB capをcontextや料金上限と混同していないか／保存ファイルのpath・size・hashを確認したか／toolの終了状態を見たか／副作用の有無を確認したか／範囲指定や分割を試せるか／機密データの共有範囲を決めたか／原本と要約の関係を残したか／rollbackまたは再取得方法を説明できるか、を確認します。

調査中に「切れた」と感じた場合は、まず結果の末尾、previewの警告、toolの終了状態を順に読みます。エラーがなければ成功と決めつけず、期待件数や対象期間と照合します。失敗なら、同じ処理を繰り返す前に小さなfixtureで再現し、上限・timeout・権限・対象データのどこで起きたかを分けます。担当者が交代しても再現できるよう、入力条件と取得範囲をチケットへ残してください。

よくある質問

1GB capはClaude APIの料金上限ですか？

違います。公式changelogが示すのは、Claude Codeがtool結果をdiskへ保存する際のcapです。APIのcontext、token料金、契約上限はそれぞれの公式情報で別に確認します。

プレビューが切れたら原本も壊れますか？

プレビューの表示と保存ファイルの状態は分けて確認します。path、size、更新時刻、hash、tool終了状態を読み、必要な範囲を再取得してください。

大きなログは分割すればよいですか？

目的と機密性を確認した上で、日付・ID・行範囲などで分割するのが基本です。外部更新や送信を伴う処理は、分割前に副作用と重複実行を確認します。

公式情報と無料診断

1GB capとプレビュー表示は公式changelog、利用量の観測はmonitoring usage、運用設定はsettingsで公開直前に確認します。Miraigentの無料診断では、tool結果の分類、保存、共有、監査、復旧を業務に合わせて整理できます。