確認を何回挟んでも、戻せないものは戻せない。非エンジニアが最初に作る「戻せる状態」

AIで作ったツールが入っているパソコンが、明日の朝いきなり起動しなくなったとします。
どこまで元に戻せるか、すぐに答えられますか。

僕は答えられませんでした。
というか、そんな質問があること自体、考えたこともなかったんです。

202回分の仕事が、パソコン1台の中にあった

電気工事士で非エンジニアの拓です。AI（Claude Code）と一緒に勤め先の業務ツールを作っています。

ツールを作り始めて半月くらいたったころ、AIとの作業の途中で、こう言われました。
これまでの仕事は、全部このMacの中にしかないですよ、と。

ツールの中身、AIに毎回読ませているルールのファイル、作業の記録、202回分の変更の履歴。それが全部、机の上のノートパソコン1台に乗っていました。落として壊れたら、そこで終わりです。

言われるまで、危ないなんて思っていませんでした。
怖かったわけじゃなくて、危機感そのものが無かったんです。ここが今回いちばん書きたいところで、これってエンジニアなら自然に持っている感覚なのかもしれません。「消えたらどうする」を先に考える癖は、失ったことがある人か、それを仕事にしている人にしか無いんですよね。

非エンジニアがAIでツールを作ると、この感覚が抜けたまま、ツールだけが先に育っていきます。

変更の記録を残す仕組みも、自分から入れたものじゃなかった

振り返ってみると、最初の一歩もAIからの提案でした。

ツールが動き始めてまもないころ、作ってみて見えてきた課題をAIに聞いたときのことです。AIは作ったものを見直して、いちばん効くのは「変更の記録を残す仕組み（Git）がまだ入っていないこと」だと答えました。何をどう直したかが残っていないと、あとから確かめようがない、と。

「そこから着手しようか」と返して、その日のうちに入れました。
これで何かを壊しても前の状態に戻れる。そう思っていたんです。

でも、戻れたのはコードだけでした。

「確認を増やす」か「戻せるようにする」か

夜の10時半を回ったころ、AIからこう聞かれました。手元で直したものを、実際に毎日使われているツールへ送る作業、確認なしで進めていいですか、と。

選択肢の先頭には「ここだけは毎回聞いてほしい（おすすめ）」とありました。理由は、間違えても変更の記録からは戻せないから。送る先のスプレッドシートは、事務員さんが毎日日報を入れている本物なんです。

僕はどれも選ばずに、こう打ちました。

毎回確認を挟んでも、間違えたときに戻せないことは変わりませんよね。確認は、戻せないものを戻せるようにはしてくれない。止める回数を増やす前に、戻せる状態を作るほうが先だと思ったんです。

そこでAIに、ツールに関わるものを「壊したら戻せるか」で数え直してもらいました。

• ツールのコード：戻せる（変更の記録がある）

• 公開の設定：戻せる（1分で元の値に戻せる）

• 公開しているURL：消すと戻せない（作り直すと別のURLになる）

• 表に入っている日報のデータ：戻せない（コピーが1枚も無い）

あとで分かったんですが、スプレッドシート自体にも変更の履歴は残っていて、完全にゼロというわけではありませんでした。ただそれは、人が画面で操作しないと戻せないし、そのあとに事務員さんが入れた分まで一緒に巻き戻ってしまいます。

コードも設定も戻せるのに、確認は一律に挟んでいました。反対に、いちばん戻せないデータのほうには何の手当ても無かった。止める場所が、ずれていたんです。

戻せないものを、戻せるようにした

それで翌日から、日報のデータに手を付けました。

危ない作業の前にボタン1つで今の状態を保存できるようにして、毎日1回、自動で表のコピーを取るようにしました。

最初は、古いコピーは手で捨てる作りでした。これには僕から3つ言っています。自動で消えたほうがいい。コピーが増えると、どれが最新でどれが要らないのか、人の目では分からなくなる。かといって自動で消すなら、必要なものまで消しちゃう危険はどう防ぐのか。

AIが出してきたのは、日数で消さないやり方でした。直近7日分は全部残して、それより古い分は月ごとに1つだけ残す。これなら、月初めに壊れて月末の請求で気づく、みたいな遅れて見つかる事故でも、壊れる前の状態がちゃんと残ります。

控えは「送れた」ではなく「取り戻せた」まで

最初の話に戻りますね。
Mac 1台にしか無かった202回分の仕事は、ネット上の非公開の保管場所（GitHub）に控えを送るようにしました。送る前には、パスワードみたいなものが混ざっていないかをAIに調べてもらっています。

大事だったのは、実はそのあとです。送った控えを別の場所に取り寄せ直して、変更の記録が全部そろっているか、取り寄せたものでツールの計算がちゃんと合うかまで確かめました。

控えは、取り戻せて初めて控えです。

ここから、自分のツールでやってみる

ここからは手を動かす話です。Claude Code に貼るだけで使える指示文を、やる順に5つ並べました。どれも練習用に作った小さなツールで実際に動かして、書いたとおりに動くのを確かめてあります（4だけは、GitHubに送る手前までです）。

始める前に用意するもの

• Claude Code が使える状態になっていること。 まだの人は、画面の写真を見ながら進められる導入の記事を書きました。

• ツールのファイルが、パソコンのフォルダに入っていること。 Apps Script の画面（ブラウザ）で直接コードを書いている人は、この記事の手順がそのままでは使えません。その場合のやり方も、別の記事で書きます。

• Claude Code を、そのフォルダで開くこと。 違うフォルダで開くと、AIは別のファイルを見て作業します。

「Git」という言葉が何度か出てきます。ゲームのセーブみたいなものだと思ってください。変更するたびにセーブ地点を作っておけば、あとでどの地点にも戻れます。この記事で「記録」と書いているのは、このセーブのことです。

1. セーブできるようにする

このフォルダを、Gitで変更の記録を残せるようにしてください。
始める前に、パスワード・APIキーなど、記録に入れてはいけないものが混ざっていないか調べてください。
見つかったら、消したり書き換えたりする前に、どこに何があったかを私に知らせてください（使っているものを消すと、ツールが動かなくなることがあるため）。
記録に入れてはいけないものを外したうえで、いまの状態を最初の記録として残してください。

APIキーは、ほかのサービスを使うための合言葉です。混ざっていると、AIは作業を止めて、こんなふうに聞いてきます。

それが使っているものかどうか分からなければ、そのまま伝えちゃって大丈夫です。

使っているかどうか分かりません。ツールが止まらない方法でお願いします。

実は、最初に試したときは「知らせて」の一文を入れていませんでした。そうしたら、コードの中に直接書かれていた鍵を、AIは聞かずに消したんです。使っていない鍵だったので無事でしたが、使っている鍵だったら、そこでツールが止まっていました。

2. セーブを習慣にさせる

このフォルダのCLAUDE.mdに、次のルールを書き足してください。
・作業が一区切りついたら、指示がなくてもGitに記録する
・記録には「何を変えたか」だけでなく「なぜ変えたか」を書く
・記録は、コードを読めない人が読んでも分かる言葉で書く
書き足したら、このルールに沿って、その変更も記録してください。

CLAUDE.md は、Claude Code が作業を始めるたびに読むメモです。ここに書いておけば、毎回「セーブして」と頼まなくても、区切りごとに勝手にセーブしてくれます。

3. 戻せるもの・戻せないものを数える

このツールに関わるものを全部洗い出して、「壊したときに戻せるか」の表にしてください。
列は「もの」「戻せるか」「戻し方」「戻すのにかかる時間」です。
コードだけでなく、スプレッドシートの中身、公開や共有の設定、URLも入れてください。
戻せないものには、戻せるようにする案を付けてください。
専門用語は使わず、コードを読めない人にも分かる言葉で書いてください。
この作業では、まだ何も変更しないでください。

いちばん効くのは、これです。練習用のツールで試したときは、こんな表が返ってきました（一部を抜き出して、行ごとに並べ直しています）。

• コードのファイル：戻せる。パソコンの中の作業の記録帳から、前の状態を呼び出せる

• 作業の記録帳そのもの：戻せない。このパソコン1台の中にしかなく、外に控えがない

• 公開の設定：戻せない。変更前の状態のメモがないと、元に戻せない

2つ目を見てください。「記録がパソコン1台の中にしか無い」ことを、こっちが聞く前から「戻せない」に入れてきました。自分に危機感が無くても、数えさせれば出てくるんです。

AIが実際には開いて確かめられなかったもの（Googleの画面の中の設定など）には、その印が付いてきます。そこだけは自分の目で見てください。

4. 控えを外に置き、取り戻せるか確かめる

このフォルダの控えを、GitHubの非公開のリポジトリに置きたいです。
私が画面で操作する部分と、あなたがやる部分を分けて、順番に教えてください。
送る前に、パスワード・APIキーなどが混ざっていないか調べてください。
送ったあとは、別の場所に取り寄せ直して、中身がそろっているかを確かめてください。

GitHub は、ネット上にあるセーブデータの置き場所みたいなものです。無料で作れて、非公開にすれば自分しか見られません。アカウントは自分で作ります。この指示文を貼ると、AIが「ここはあなたが画面で操作」「ここは私がやる」と分けて、順番に案内してくれます。

5. 壊れたときに戻す

ここまでやっておくと、壊れたときにこう頼めます。【困っていること】のところだけ、自分の言葉に書き換えてください。

ツールの様子がおかしいです。
【困っていること】8時から17時まで働いた日の作業時間が、8時間のはずなのに7.5時間になっています。
変更の記録をさかのぼって、いつ・どの変更からおかしくなったのかを調べてください。
戻す前に、何を戻すのか、戻すとほかに何が一緒に戻ってしまうのかを、コードを読めない人にも分かる言葉で説明して、私のOKを待ってください。

練習用のツールに、わざと休憩の計算を狂わせる変更を入れて試してみました。AIはセーブ地点を順にさかのぼって、原因の変更を1つに絞り込み、こう返してきました。

「OKです」と返すと、その1行だけを元に戻し、理由を書いてセーブしました。戻したあとに計算し直すと、ちゃんと8時間になっていました。

「一緒に何が戻ってしまうか」をわざわざ聞くのは、丸ごと昨日の状態に戻すと、そのあとに直した別の部分まで消えてしまうことがあるからです。

危機感は、借りればいい

エンジニアじゃない僕には、「消えたらどうする」という感覚は今も育っていません。
それでも困らなくなったのは、その感覚をAIから借りる手順を持てたからなんです。

何が戻せないかを聞く。戻せないものを戻せるようにする。控えを取り戻せるか確かめる。確認の回数を増やすのは、そのあとで十分でした。