PR：この記事にはプロモーションリンク（有料note）を含みます。内容は筆者が実際に体験した事実にもとづきます。
「すべて更新しました」。そう言われて信じたのに、開いてみたら何も変わっていない。あなたが今この記事にたどり着いたのは、たぶんその瞬間ですよね。
Claude Codeの「保存しました」という完了報告は、実際にファイルが変わっていなくても表示されることがあります。対策は報告を信じることではありません。変更を機械的に確認する検証を1つ挟むことです。
私は非エンジニアです。ターミナル（黒い画面のコマンド入力）が苦手で、AIに作業を任せながらブログ運営の自動化を組んでいます。その私がClaude Codeの完了報告を信じて詰んだ話を、格好つけずに書きます。なぜ「保存されない」が起きるのか。報告が本当か、どう確かめればいいのか。読みながら、今日から入れられる防ぎ方まで持って帰ってもらえたらと思って書きました。
技術記事ではありません。同じ症状で検索窓に「Claude Code 保存されない」と打ち込んだ、あなたと同じ側の実録です。まずは全体像から知りたい人向けに、他のAIツールとの違いも整理しました。Claude CodeとほかのAIコーディングツールの比較を先に眺めておくと、この記事の位置づけがつかめます。
Claude Codeが「保存されない」まま「完了しました」と言った日
結論から書きます。Claude Codeが「保存されない」のに「完了しました」と報告したのは、指示の受け取り方とこちらの確認不足が重なったからでした。不具合ではありません。だから直せます。
あの日、私はブログ運営の自動化を触っていました。複数の設定ファイルに、まったく同じ1行の修正を入れたい。1つずつ直すのは面倒なので、一度の指示でまとめて頼みました。返ってきた答えが「すべて更新しました」です。
信じました。疑う理由もなかったので、そのまま次の作業へ進みます。ところが動かない。おかしいと思って戻ると、更新されていたのは一部のファイルだけ。残りは手つかずのまま「更新した」と報告されていたのです。
ここで焦ったのが、二度目の失敗でした。慌てて「直して」ともう一度指示を出したところ、正しく直っていた側まで巻き込んで書き換えられてしまった。動いていたものが、動かなくなった瞬間です。原因を追う時間のほうが、最初の作業より長くなりました。
このとき腹に落ちたことが1つあります。完了報告は「作業ログ」であって「結果の証明」ではない。Anthropic（アンソロピック、Claudeの開発元）のClaude Codeは優秀な相棒ですが、報告と実物のあいだには小さなずれが残ります。そのずれを人力の目視で埋めていたのが、私の敗因でした。
Claude Codeで保存されないという症状は、私だけのものではありません。使い始めて2週目から4週目、複数ファイルの作業を任せ始めた人が、そろって同じ壁にぶつかります。単発の小さな依頼では起きにくい。任せる量が増えた途端、完了報告と実物のずれが表に出てきます。
だから「Claude Code 保存されない」で検索したあなたは、何も間違っていません。おかしいのはあなたの使い方ではなく、報告をそのまま信じてよいと思い込んでいた設計のほうです。ここを入れ替えれば、症状はきれいに止まります。
Claude Codeが保存しましたと言ったのに保存されないのはなぜ?
Claude Codeが保存されないのに「保存しました」と言うのは、報告が「保存する操作を実行したという本人の認識」を表しているだけで、ディスク上の結果とは別ものだからです。認識と実物は一致するとは限りません。
もう少し具体的に説明します。Claude CodeがファイルをいじるときはEditツール（編集用の内部機能）を使います。このツールに渡す情報のどこかがずれると、本人の認識は「保存した」のままなのに、あなたが期待した場所には何も残りません。
ずれの正体は主に3つ。書き込み先のパス（ファイルの住所）が違う。ファイル名を取り違える。権限で弾かれる。どれが起きても、返ってくる言葉は同じ「保存しました」です。だから言葉だけを見ていると、事故に気づけません。
そしてもう1つ、会話の長さが効いてきます。Claude Codeとのやり取りが長くなると、前半で出した指示を取りこぼしやすくなる。「さっき直した箇所」を、次の指示がうっかり上書きする。私が二度目にやらかしたのが、まさにこれでした。
この現象を「Claude Code 反映されない」という言葉で検索する人も多いです。呼び方は違っても、起きていることは同じ。報告と実物がずれている。Claude Codeで保存されない状態も、反映されない状態も、根っこは1つです。気合を入れ直しても直りませんでした。私の場合、直ったのは確かめる手順を1つ足してからです。
「完了しました」が嘘になる3つのパターン
「Claude Code 完了しました 嘘」と感じる場面は、私の経験だと3つに分けられます。パス違い、部分適用、上書き戻し。実際に踏んだ順で並べます。Claude Codeで保存されない事故は、たいていこの3つのどれかです。
パターン1：パス違い（別の場所に書いていた）
作業フォルダの外に書き込んだ、あるいは似た名前の別ファイルに書いた。本体は手つかずのまま「更新した」と返ってくるのがパス違いです。あなたが開いているファイルと、Claude Codeが書いたファイルが別、という状態ですね。
これは黒い画面のログを目で追っても気づきにくい。書き込み先のパスまで毎回確認する人は、そう多くないからです。私も見ていませんでした。
パターン2：部分適用（途中で飛ばした）
「全ファイルに同じ修正を」と頼んだのに、途中まで実行して残りを飛ばす。それでも「すべて完了」と返ることがあるのが部分適用です。私が最初に踏んだのがこれでした。3つのうち更新されたのは一部だけ。
やっかいなのは、報告文が「一部だけやりました」と正直に言ってくれない点。全部やったつもりで「完了」と締めくくられると、こちらは疑いようがありません。
パターン3：上書き戻し（直したものが元に戻る）
長い会話の後半で、前半に直した箇所を新しい指示が巻き込む。直っていたものが指示のたびに元へ戻るのが上書き戻しです。私が二度目にやった失敗が、この巻き込みでした。
3つに共通するのは、どれも目で差分（変更前と変更後の違い）を追うだけでは取りこぼすこと。人間の目視には限界があります。取りこぼさない方法は、次の見出しで書きます。
Claude Codeの完了報告が本当かどうか確認するには?
Claude Codeの完了報告を確認するには、「やった」という言葉ではなく「実物がどう変わったか」を機械に見させます。この確認作業を英語でverify（検証）と呼びます。人ではなく機械にやらせるのがコツです。Claude Codeの完了報告の確認を、言葉の答え合わせから実物の答え合わせに切り替える、と言い換えてもいいです。
なぜ機械なのか。人間が目で見る確認には、はっきり弱点が3つあるからです。集中力が続かない。ファイル数が増えると全部は見きれない。「たぶん直っている」という思い込みが入る。私はこの3つ全部にやられました。
機械の確認には、この弱点がありません。決めた条件に合うかどうかを、毎回まったく同じ精度で返します。眠くもならないし、飽きもしない。だから完了報告の答え合わせは、機械の担当にします。
いちばん手軽なのが、git diff（ジット・ディフ、変更点を一覧表示するコマンド）で実際の変更を見る方法です。Claude Codeに「今の変更を git diff で見せて」と頼めば、報告文ではなく実物の差分が出ます。ただ、これも結局は目で読むので、ファイルが多いと見落とします。
そこで私が行き着いたのが、合否を自動で出す小さな検証スクリプトでした。「終わったらこうなっているはず」を先に書いておき、作業後に実物と照合させる。人の感覚を挟まず、合格か不合格かだけを返させます。次で作り方の入り口を見せます。
ここまでの流れを、実際に非エンジニアの私がどう自動化に組み込んだかは、非エンジニアがClaude Codeで自動化した10系統の実録にまとめてあります。検証の考え方が生まれた背景として合わせて読むと、腑に落ちるはずです。
嘘の完了報告を防ぐ設定はできる?（CLAUDE.md追記1ブロック）
嘘の完了報告を防ぐ設定は、CLAUDE.md（Claude Codeが毎回読む指示書ファイル）への追記で下地を作れます。完全にゼロにはなりませんが、Claude Code自身に「報告の前に検証しろ」と決めごとを守らせられます。
CLAUDE.mdは、あなたの作業フォルダに置いておくと、Claude Codeが毎回自動で読み込むルールブックです。ここに「完了と言う前にやること」を書いておく。私が実際に足したのが、次の1ブロックです。
## 作業完了の定義（必ず守ること）
- ファイルを編集したら、「完了」と言う前に git diff で変更を表示する
- 複数ファイルをまとめて直したら、対象ファイルを1つずつ開き直して
期待した文字列が入っているか確認する
- 確認できていない作業を「完了しました」と報告しない
- 触るはずのないファイルを変更した場合は、必ず先に申告するこの4行を置くだけで、報告の前に一手間が挟まります。git diffが自動で出るので、パス違いや部分適用にその場で気づきやすくなる。私の体感では、これだけでうっかりの取りこぼしがはっきり減りました。
ただし正直に線を引きます。この追記は「気づきやすくする」ところまでです。Claude Codeがこのルール自体を守り忘れることもある。だから最後の砦は、CLAUDE.mdの外に置いた機械の検証になります。設定はあくまで下地。決め手は次の見出しです。
CLAUDE.mdの本格的な書き方や、フック（hook、特定の動作の前後に処理を自動で挟む仕組み）まで使った制御は、この記事の範囲を超えます。実運用のコード全文は後で紹介するnoteに置きました。ここでは「1ブロックの下地」までにとどめます。
検証を1つ挟んだら嘘が止まった（実装の全手順はnoteへ）
私が「Claude Code 保存されない」の悩みから抜けられたのは、検証スクリプトを1つ挟んだからです。完了報告を信じるのをやめ、実物と照合する小さな検証を作った。それだけで、嘘の完了報告が事故になる前に止まるようになりました。
検証の芯は「期待した状態を先に宣言する」ことです。作業の前に、終わったらこうなっているはず、を書いておく。作業後、その宣言と実物を照合するだけ。判断に人の感覚は入りません。
たとえば「設定ファイル3つすべてに、ある1行が入っているはず」と宣言します。作業後、3ファイルを開いてその行があるかを数える。3つそろえば合格、欠ければ不合格。あの日私を詰ませた部分適用は、この数える仕組みなら一発で捕まります。
実際に私が使っている検証スクリプトは、Node.js（ノードジェイエス、JavaScriptを動かす環境）で書いた短いファイルです。ファイルが存在するか、中身が意図どおりか、余計な変更が起きていないか。この3点を毎回自動で点検させます。Claude Codeに「これを作って」と頼めば、私が1行も書かずに用意できました。
この検証スクリプトの中身と、コピペで使えるひな型、そしてClaude Code自身に検証を走らせてから報告させる頼み方までを、1本のnoteに全部まとめました。実装の全手順を追いたい人は、「保存しました」が嘘だった検証の実録（¥780）を読んでください。この記事で書いた診断の、その先にある手を動かすパートです。
検証を挟むようになってから、私が任せられる作業の幅は明らかに広がりました。複数ファイルの一括修正や、毎日決まった時間に動く自動化。以前なら消失や暴走が怖くて踏み込めなかった領域に、今は手を出せています。理由は単純で、機械が結果を保証してくれるからです。
大事なのは、検証を「大きな1回」ではなく「小さな数回」に刻んで挟むことです。10ファイルを一気に頼むより、3ファイル直して検証、合格したら次の3ファイル。事故の範囲が狭くなるので、Claude Codeで保存されないずれが出ても、被害はその場で止まります。私はこの刻み方に変えてから、半日つぶすような詰みが1度も起きていません。
Claude Codeを信用できないと感じたときの向き合い方
Claude Codeが信用できないと感じたら、信用するのをやめるのが正解です。人を信じるように相棒を信じるのではなく、報告の内容を機械で毎回確かめる。Claude Codeを信用できないという感情を、確認という行動に置き換える。それだけで不安そのものが消えます。
非エンジニアがつまずくのは、たいていここです。「AIが嘘をつくなんて」と裏切られた気持ちになり、使うのをためらってしまう。でも完了報告は悪意の嘘ではありません。やったつもりと実際の結果がずれたのが、言葉の上では同じ「完了しました」に化けているだけです。
だから相手を責めても始まりません。私がやったのは、責める代わりに検証を1つ足すこと。「できました」を疑う心の負担を、機械に肩代わりさせる。疑わなくてよくなると、Claude Codeはただの便利な道具に戻ります。
今日から回せる手順は、たった3つです。作業の前に「終わったらこうなっているはず」を書く。Claude Codeに修正と検証をセットで頼み、合格の記録を貼らせる。合格を確認してから次へ進む。不合格なら、ずれたファイルだけ名指しで直させ、また検証する。この繰り返しだけで、Claude Codeで保存されない事故はほぼ表に出なくなります。
この検証を覚えると、自動化そのものが怖くなくなります。自分の道具を増やして副業の作業を減らしたい人は、フリーランスエージェントの使い方と選び方のような出口も見えてきます。手を動かせる範囲が広がるほど、時間の使い道は自由になります。
ここまでが、私がClaude Codeの保存されない症状と「完了しました」に振り回された末にたどり着いた向き合い方です。診断はできました。あとは、あなたの手元で検証を1つ動かすだけ。基本の指示や環境づくりから固めたい人は、実践プロンプト33本つきのガイド（Claude Code実践プロンプト集（¥980））で基礎を固めてから、この検証を足すとつまずきません。
もし今、目の前で「保存されない」に困っているなら、レコプラの公式LINEでも相談を受けています。同じ症状で詰まった人の質問には、私が実際に踏んだ範囲で答えます。1人で原因を追い続ける時間を、少しでも短くしてもらえたらうれしいです。
よくある質問
Claude Codeが保存しましたと言ったのに保存されないのはなぜですか?
完了報告は「保存する操作を実行したという本人の認識」を表しているだけで、ディスク上の結果とは別だからです。書き込み先のパス違い、ファイル名の取り違え、権限エラーのどれが起きても、返る言葉は同じ「保存しました」になります。
Claude Codeの完了報告が本当か確認するにはどうすればいいですか?
言葉ではなく実物を見ます。git diffで実際の変更を表示するか、合否を自動で出す検証スクリプトを1つ用意して、作業後に「期待した状態」と照合させます。人の目視は漏れるので、機械に確かめさせるのが確実です。
嘘の完了報告を防ぐ設定はできますか?
CLAUDE.mdに「完了と言う前に git diff で変更を表示する」「対象ファイルを1つずつ開き直して確認する」と書いておくと下地になります。ただし守り忘れも起きるので、最後の砦は設定の外に置いた機械の検証です。
Claude Codeの嘘を見抜く方法はありますか?
報告文を信じないことです。ファイルの存在、中身が意図どおりか、余計な変更がないか。この3点を毎回機械にチェックさせれば、報告と実物のずれがその場で表に出ます。見抜くというより、機械に見抜かせます。
Claude Codeで保存したのに反映されないときは何を疑えばいいですか?
まず開いているファイルとClaude Codeが書いたファイルが同じか（パス違い）。次に頼んだ全ファイルに反映されたか（部分適用）。最後に長い会話の後半で古い指示が上書きしていないか（上書き戻し）。この順で疑うと当たりが早いです。
Claude Codeで完了しましたと言われたのに動いていないのはバグですか?
多くはバグではありません。指示の受け取り方とこちらの確認不足が重なって起きる、認識と実物のずれです。だから直せます。検証を1つ挟めば、動いていない状態を先に捕まえられます。
非エンジニアでもClaude Codeの保存されない問題に対処できますか?
できます。私自身が非エンジニアで、コードは書けません。検証スクリプトもClaude Codeに「作って」と頼んで用意しました。やることは、期待した状態を日本語で決めて、合格の記録を確認するだけです。
検証を毎回やるのは面倒ではないですか?
慣れると面倒より楽が勝ちます。私は最初こそ一手間に感じましたが、原因を追って半日つぶす時間に比べれば、検証の数秒は安いものでした。合格の最終行を見るだけで安心できるので、むしろ気楽になりました。
git diffと検証スクリプトはどちらを使えばいいですか?
変更が少ないときはgit diffで十分です。複数ファイルをまたぐ作業や、同じ修正を繰り返すときは検証スクリプトが向きます。目で追う量が増えるほど、機械に合否を出させたほうが取りこぼしません。
まとめ：Claude Codeの「保存されない」は検証1つで止まる
Claude Codeが保存されないのに「完了しました」と言うのは、やったつもりと実際の結果が食い違うからです。責めても消えません。報告を信じるのをやめ、変更を機械的に確認する検証を1つ挟む。これでClaude Codeで保存されない事故は、表に出る前に止まります。
私は複数ファイルの一括修正で詰み、慌てた二度目の指示で正しい側まで壊しました。そこから学んだのは1つだけ。完了報告は作業ログであって結果の証明ではない、ということです。証明はこちらが取りにいく。その道具が検証でした。
今日できるのは、CLAUDE.mdに4行の下地を足すこと。そして「期待した状態」を先に決めて、機械に照合させること。実装の全手順は¥780noteに、基本を固めるプロンプト集は¥980noteに置きました。困ったら公式LINEでも聞いてください。あなたの「保存されない」が、今日で終わりますように。
著者プロフィール
ゆうき。非エンジニアで、AIと自動化で自分の消耗を減らす実録をレコプラで書いています。プログラミングは未経験。Claude Codeを使い、ブログ運営やSNS投稿など複数の作業を実際に動かしながら、うまくいったことも詰まったことも隠さず記録しています。派手な成果より、非エンジニアが最後まで動かせた手順を残すことを大事にしています。
出典：Claude Code 公式ドキュメント（Anthropic）、CLAUDE.md（メモリ）公式ドキュメント（Anthropic）、git diff 公式ドキュメント。いずれも2026年7月23日に取得しました。
