ファイルの更新時刻もサイズも最新でした。それでも、読み出した中身は古いままでした。
これはClaude（Cowork）で起きた不具合です。手元のフォルダを接続して作業する環境では、ファイルはいったんClaude側の作業場へ取り寄せられます。その取り寄せが、2回目以降に更新されないことがあります。しかも、失敗したようには見えません。
不具合そのものはClaude固有です。ただ、そのあとに起きたことは違います。AIが「回避策はありません」と答え、それが誤りだった。この形は、AIを使う場面ならどこでも起こります。
機械が「最新です」と言っても、中身が最新とは限らない
症状は次の3点です。
- 同じファイルを取り寄せ直すと、応答は最新のサイズを返す
- ところが実際に読める中身は、最初に取り寄せたときのもの
- 作業場側に置かれたファイルのタイムスタンプは、最初の取り寄せ時刻で止まっている
厄介なのは、サイズと更新時刻だけが正しいことです。この2つは、ファイルの情報を直接問い合わせて得た値です。いっぽう中身は、キャッシュから返っています。数字が合っているので、確認したつもりになれてしまいます。
実害は、追記のときに出ます。古い中身を土台にして書き足し、そのまま保存すると、あいだに入っていた修正がまとめて消えます。保存そのものは成功するため、エラーも出ません。
原因は、二段になったマウントのキャッシュ
調べたところ、同じ症状がGitHubに報告されていました（issue #45433）。原因として挙げられているのは、フォルダの見せ方です。
Windowsのフォルダを仮想マシンへ渡し（virtiofs）、それをさらに作業用のサンドボックスへ渡す（FUSE）という二段構えになっています。この層が中身とメタデータをキャッシュし、外から書き換えられても無効化されません。
報告によれば、キャッシュはその環境自身が最後に書いた時点で凍り、セッションを変えても、アプリを入れ直しても残ります。別の報告（issue #40264）では、以前に書いたファイルが次の読み出しで途中までしか読めない、という形でも出ています。
報告者は「キャッシュを貫ける手段は見つからない」と書き、フォルダを読み直す仕組みを用意してほしいと要望しています。現時点で、公式の対処法は案内されていません。
Claudeは「回避策はありません」と答えた
ここからが本題です。
この症状に当たったClaudeは、こう結論しました。パスの書き方を変えても直らない。時間を置いても直らない。ゆえに回避策はない。ファイルを直接送ってもらうか、別名でコピーを作ってほしい——と。
この結論は、間違っていました。試したのは、思いついた操作が数回だけです。原因は調べていません。それでも「ありません」と言い切ることはできてしまいます。
そして、これはClaudeに限った話ではありません。AIは、手元にある材料だけで答えを組み立てます。検索は、指示されて初めて起きる行動です。だから「できません」と「まだ調べていません」が、同じ言い方で出てきます。どちらの意味で言っているかは、回答の書きぶりからは分かりません。区別がつかない以上、聞いたほうは前者として受け取ります。
「根本的な解決方法を検索して調べてください」——その一言で出てきたもの
そこで、代わりの手段を探す前に、原因を検索で調べるよう指示を出しました。出てきたものは次のとおりです。
- 同じ症状が、既知の不具合として報告されていた
- 原因が、マウントの二段構えとキャッシュにあると特定されていた
- そのキャッシュが、何を単位にして効いているかが分かった
3つ目が、そのまま回避策になりました。原因が分かると、試すべき操作に当てがつきます。思いつきで操作を変えるのとは、当たる確率が違います。
調べる前と後で、AIの能力が上がったわけではありません。変わったのは、材料の量だけです。
見つかった回避策と、効かなかった方法
ここからはClaude（Cowork）に固有の話です。キャッシュは、作業場側の置き場所（パス）ごとに効いていました。裏を返せば、作業場側のパスが変われば、新品として取り寄せられます。
Windowsは、ファイル名の大文字と小文字を区別しません。そこで、取り寄せに使うパスの拡張子だけを大文字にします。Windowsは同じファイルを開き、作業場側では別のファイルとして置かれます。
| 取り寄せに使ったパス | 作業場側に置かれた中身 |
|---|---|
作業ログ.md |
57,877バイト（古いまま） |
作業ログ.MD |
67,084バイト（最新。実物と一致） |
3回目以降は .Md、.mD と変えれば、必要なだけ繰り返せます。元のファイルには触りません。リネームもコピーも要りません。
効かなかった方法も残しておきます。
- 同じパスで取り寄せ直す——何度やっても古いまま
- パスの途中に
./を挟む——正規化されて同じ扱いになる - 時間を置く——20秒待っても変わらず
- 濁点を分解した表記にする——Windows側でファイルが見つからずエラー
なお、書き戻しの成否を取り寄せ直して確かめる運用には戻していません。保存できたかどうかは、フォルダの一覧を取ってサイズを照合するほうが確実です。キャッシュを通らない情報だけで確認する、という考え方は変えていません。
AIへの指示として、そのまま使える言い方
効いた指示は、特別なものではありません。次の3つは、そのまま使えます。
- 「根本的な解決方法を、検索して調べてください」——結論ではなく、調査を指示します
- 「それは調べた結果ですか。試した範囲からの推測ですか」——根拠の出どころを分けさせます
- 「できない理由を、出典を示して説明してください」——出典が出てこないなら、まだ調べていません
いずれも、今回はClaudeで確かめたものです。ただ、材料が足りないまま結論だけが出るという形は、AIの答え方に共通します。使うAIが変わっても、確かめ方は変わりません。
AIが「できません」と答えたとき、すぐに代わりの手段を探すのは自然な流れです。ただ、その前に一度、調べたうえでの結論なのかを聞いたほうが早いことがあります。今回は、この一往復で解決しました。
もっとも、指示そのものが届いていなければ意味がありません。設定した指示がどこまで効くかは環境によって違います（Claudeに設定した指示が効かないことがある——「Claudeへの指示」と「CLAUDE.md」の届く範囲）。ファイルの触り方の違いはCoworkとClaude Codeの違いにまとめています。
確認していないこと
- 拡張子を大文字にする回避策が効くのは、大文字と小文字を区別しないファイルシステム（Windows、macOSの既定）に限られます。区別する環境では別のファイルとして扱われ、開けません
- この不具合が修正されれば、回避策は不要になります。報告されたissueは重複扱いで閉じられており、修正の告知は確認できていません
- キャッシュの保持時間は分かっていません。20秒では変わりませんでしたが、長時間置いた場合は試していません
- ほかのAIサービスで同じ不具合が出るかは確認していません。仕組みが違えば起こらないと考えられますが、試してはいません。指示の出し方についても、Claude以外では確かめていません
