【AI社員実践記 第29話】台帳の置き場を変えた日。更新を任せる前に整えた3つの備え

こんにちは、オフィスピコッツの小笹です。

AI社員に、基本台帳の次の版を作ってもらいました。作業は約5分。完了報告には「追加40行・変更9行・削除0行」とあり、前の版は変更せずに残っています。ただ、そこへ進む前に、約35分かけて台帳を扱う環境と確認の手順を整えました。

きっかけは、台帳の更新中にチャット側の上限へ当たったことです。会社の決まりごとをまとめた基本台帳は99KB。進行中の案件をまとめた引き継ぎ書は190KBを超えていました。前の日の続きから仕事をするための記録が育ち、その記録を更新する作業が重くなっていたのです。

今回は、Googleドライブにある台帳をPCのフォルダから直接編集する形へ変えました。その前に用意したのが、旧版のコピー、変更履歴、番号の照合という3つの備えです。ファイルを直せるようにするとき、前の記録をどう残し、何を見て更新完了とするかまで考えた回です。

きっかけは、1行直すための全文の往復だった

AI社員には、毎朝、基本台帳と引き継ぎ書を読ませてから仕事を始めてもらっています。会社の方針、以前決めたルール、進行中の仕事。そうした前提をファイルに残し、別の会話になっても続きから始められるようにしています。

第21話では、途中で止まった仕事を、引き継ぎ書や会話の記録と照合して復旧しました。記憶をチャットだけに置かないことは役に立ちます。ただ、外に置いたファイルも、仕事が進むたびに更新しなければなりません。

当時の方法では、AI社員がGoogleドライブから台帳の全文を読み、変更を反映した全文を書き出して、新しい版として保存していました。直したいのが1行でも、この往復です。登録している自動処理の本数を変えるだけでも、変更しない会社のルールや過去の記録まで一緒に扱います。

Googleドライブ上のファイルが、どんな方法でも部分編集できないという話ではありません。そのとき使っていたチャット側の操作方法が、全文を受け渡す形だったということです。ファイルが大きくなるほど、変更したい量と、実際に読み書きする量の差が広がっていました。

上限に当たった原因を、ファイルサイズだけで断定することはできません。それでも、この往復は減らせそうです。「手作業を増やさずに、更新のやり方を変えられないか」とAI社員へ相談しました。

台帳を、PCのフォルダから直接扱う

提案されたのは、パソコン版Googleドライブを入れ、台帳のフォルダをPCから扱えるようにする方法でした。そのフォルダでClaude Codeを使い、台帳ファイルを直接読み書きします。Claude Codeは、ファイルの内容を確認し、編集やコマンドの実行を進められるAIの道具です。

必要な箇所を確認し、変更する箇所へ修正を当てる。毎回、全文をチャットへ貼り直したり、出来上がったファイルを手でアップロードしたりする工程を減らします。PC側で保存した変更は、Googleドライブの同期を通じて反映されます。Googleドライブの公式説明

ここで扱うのは、テキストファイルとして保存している基本台帳と引き継ぎ書です。第28話の顧客台帳はGoogleスプレッドシートで、「未着手」「進行中」をサーバーが抜き出す話でした。今回は、AI社員が仕事を引き継ぐための文書に変更を反映し、次の版を作ります。同じ台帳という名前でも、対象と任せる作業が違います。

なお、PCのフォルダから扱えば、AIの利用上限がなくなるわけではありません。Claude Codeでも、読んだ内容や作業のやり取りはコンテキストと利用枠を使います。今回変えたのは、台帳の全文を何度も受け渡していた更新の工程です。Claude Codeの公式説明

便利になる前に、過去の記録が消えないか気になった

直接編集できれば、作業は進めやすくなります。ただ、私が気にしたのは削除や上書きでした。以前、引き継ぎ書の版を重ねる中で、前の版にあった項目が次の版から抜けたことがあります。

引き継ぎ書は、読みやすく要約できれば十分な文書ではありません。まだ終わっていない仕事や、以前決めた制約が必要です。整理する途中でそうした項目まで落ちると、次のAI社員は、その仕事が残っていること自体に気づけなくなります。

これまでは新しい版を別ファイルとして作っていたので、古い版は残っていました。直接編集する道具へ変えても、この残し方は続けたい。更新の速さと引き換えに、以前書いたことを探し直す作業が増えては困ります。

その心配を伝えると、AI社員からは「素のままだと今より危険です」と返ってきました。そのうえで、編集を始める前に3つの備えを用意することになりました。

1つ目：旧版を残し、コピーした次の版を編集する

まず、今ある版には手を入れず、コピーして次の版を作ります。今回なら、基本台帳v6からv7を作り、変更するのはv7だけです。直接ファイルを編集できるようになっても、旧版を残す手順は変えません。

これなら、新しい版に疑問が出たとき、編集前の内容を開いて比べられます。AIの「元の内容を残しました」という説明だけで確認を終えず、比較する相手を手元に残しておくわけです。

ただし、旧版が残っているだけでは、次の版の抜けを自動で見つけることはできません。あとから戻れるようにすることと、更新した時点で間違いに気づくことは、別の準備が要ります。

2つ目：Gitで、変更した内容を履歴に残す

次に、台帳のフォルダをGitで管理します。Gitは、ファイルの変更を記録し、以前の状態と比べたり、記録した状態へ戻したりするための仕組みです。プログラムだけでなく、テキストの台帳にも使えます。

旧版のコピーが編集前の文書を残す役なら、こちらは変更をたどるための記録です。何を追記し、どこを書き換えたかを、前の記録と比較できます。次の版ができたという結果だけでなく、その間に何が変わったかを見られるようにします。

Gitの履歴は、ファイルを保存するたびに自動で残るものではありません。変更を確認して「コミット」という操作で記録します。今回は、台帳を作ったあとにチェックし、履歴へ残すところまでを、一連の更新作業にしました。Gitの公式説明

文書の最新版だけがあっても、間違いに気づいたとき、どこから見直すか分からなければ困ります。旧版を残すことに加え、変更した内容を追えるようにしておく。台帳を毎日使うために、更新の記録も必要だと考えました。

3つ目：件数だけでなく、残っている番号を照合する

引き継ぎ書の項目や、基本台帳のルールには番号を付けています。これまでも更新時に件数を確かめていましたが、件数が同じでも、同じ項目が残っているとは限りません。1件消えて1件増えれば、総数は変わらないからです。

そこで作ってもらったのが、前の版と新しい版の番号を比べる小さなプログラム「check_ids.py」です。前の版にあって、新しい版にはない番号を探し、見つかれば不合格にします。件数の確認から、項目を識別する番号の確認へ進めました。

画面には、増減した件数と、消失の有無、追加された番号が並んでいます。引き継ぎ書のある区分は171件から190件へ増え、追加番号は172〜190。別の区分は32件から33件へ増え、追加は33でした。何件増えたかに加えて、どの項目が増えたかをたどれます。

ここに写っているのは、準備段階で既存の版を比較した結果です。このあと作る基本台帳v7の検査とは分けて扱います。「合格」という文字があっても、比較したファイルが違えば、今作った版を確認したことにはなりません。

作業記録では、試験用の版から番号を2つ抜き、その2つを指摘して不合格になることも確かめました。抜けのない文書で合格するだけでなく、意図的に抜けを作ったときに止まるかを試しています。

この照合は、Gitへ履歴を記録する直前にも実行するようにしました。不合格ならコミットを止めます。ただし、ファイルの保存や削除そのものを禁止する仕組みではありません。チェックを通らない変更を、そのまま履歴へ記録する前に止めるためのものです。Gitのフックに関する公式説明

番号が残っていても、その中の文章が正しく引き継がれたかまでは、この照合だけでは分かりません。番号の消失はプログラムで調べ、文章の変更は差分を読んで確認する。調べる対象を分けることで、何が確認済みかも分かりやすくなりました。

最初の更新は、「一度だけ許可」で進めた

フォルダには、Claude Codeが作業するときの規約をまとめた「CLAUDE.md」も置きました。旧版を編集・削除しないこと、番号を照合してから履歴に残すこと、削除が必要だと考えたら実行前に確認することなどを書いています。

これはAIへ読ませる作業ルールです。記載すれば操作が物理的に禁止されるわけではありません。最初の更新は、変更の前に確認を挟む手動の運用で進めました。

最初の仕事は、基本台帳v6をコピーし、追補2本を反映してv7を作ることです。作業中には5回の確認が出ました。その都度、削除・移動の操作が含まれていないか、編集対象が旧版v6になっていないかを見て、「一度だけ許可」で進めています。

いきなり追補を書き込む前に、コピーが正しくできたかを調べる。この途中の確認も手順に含まれていました。旧版を残すという約束が、実際の操作にも反映されているかを見てから進めます。

承認画面が出たこと自体で、作業内容が正しくなるわけではありません。「次の版を作る」と説明しながら旧版を編集していないか。コピーのつもりで移動していないか。説明文と操作対象を照らし合わせるところは、人の仕事として残しました。

約5分でできたv7と、AIが判断を入れた2か所

基本台帳v7の作成は約5分でした。完了報告では、追加40行・変更9行・削除0行。恒久ルールの番号は100件から111件へ増え、消失なし。旧版v6は無変更で、コミット時の再検査も合格したと報告されています。

ここでいう「削除0行」は、古い文章がすべてそのまま残っているという意味ではありません。変更9行には文言の差し替えも含まれます。番号の検査結果と、文章の変更内容は分けて読みます。

報告には、AIが判断を入れた点も2つ添えられていました。一つは、cronの登録行数について、記述全体を置き換えず、台帳に残っていた数字を16から17へ直したことです。数字以外の既存の説明は残しています。これは台帳の記載修正で、今回サーバーへ定期実行を追加したという話ではありません。

もう一つは、環境情報を追記する場所です。章の末尾にまとめて置くのではなく、関連する小節の末尾へ入れたと報告がありました。どちらに置いても番号の照合は通りますが、次に読む人やAIにとって、探しやすさは変わります。

「できました」だけで終わらず、どこで判断したかが分かる。その報告があれば、こちらも意図に合うかを確認できます。機械で確かめられる項目と、文章を読んで判断する変更を、完了報告でも分けて扱えるようになりました。

準備35分と版作り5分。この日にできたところ

今回の作業と確認結果を整理すると、次のようになります。

約35分は、パソコン版GoogleドライブやGit、Python、Claude Codeなどを使う環境と確認手順の準備です。その後の約5分が、基本台帳の次の版を作る作業でした。「5分で全部を導入した」という数字ではありません。

今回できたのは、基本台帳v7をこの手順で作るところまでです。引き継ぎ書の既存の版同士では照合を試しましたが、次の版を同じ方法で作る作業は、この時点ではまだ残っています。

チャットで相談し、フォルダで次の版を作る

ここからは、AI社員の仕事を2か所に分けます。判断の相談、お客様向けの文面、過去のやり取りの確認はチャット側。台帳の版作りや番号の照合は、ファイルを扱うフォルダ側です。

チャット側で変更内容をまとめ、フォルダ側で前版をコピーして反映する。照合して、差分を確かめ、履歴に残す。相談したことを台帳へ反映する工程を、毎回全文を書き出す形から変えていきます。

今回の作業は既存のClaude契約の範囲で利用し、新たな有料契約は増やしていません。ただし、ClaudeとClaude Codeで利用枠を共有するため、PC側で動かした分も含めて利用状況を見る必要があります。契約と利用枠に関する公式説明

Googleドライブとの同期には、PCと同期アプリが動き、通信できる状態も必要です。監視用サーバーで動かす案はありますが、それはPCで2週間ほど運用してから考える予定にしました。まずは今回の手順を、日々の台帳更新で使って確かめます。

速く直せるようにする前に、戻れるようにする

台帳に記録が増えれば、AI社員へ渡せる前提も増えます。その一方で、全文を往復させる更新方法は重くなっていました。今回は、台帳を扱う場所と、更新を確かめる手順を一緒に変えました。

旧版を残す。変更履歴を記録する。前にあった番号が消えていないかを調べる。それぞれに役割があり、文章の中身を読む確認も残ります。一度うまくいったから、今後の引き継ぎ漏れまでなくなったとは言えません。

それでも、次の版ができたときに見るものは具体的になりました。ファイルがあるかだけで終えず、何を変え、何を残し、どこでAIが判断したかまで確認する。約5分の更新を支えたのは、その前に整えた手順でした。

AI社員実践記は、まだ続きます。

• 無料AI活用診断
• AIレスキュー
• ネット顧問
• AI社員実践記一覧

技術の話はここまで。考え方の話は「社外Web担当の頭の中」へ。