【AI社員実践記 第21話】AI社員が途中で力尽きた　「記憶をファイルに置く」仕組みで翌朝復旧

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

AIを長く仕事で使っていると、一つ気になることがあります。

「このAI、前の会話のことをちゃんと引き継げるのか？」

です。

オフィスピコッツでは、AI社員との仕事をかなり長く続けています。

一つのチャットの中だけで完結する仕事もあります。

でも、営業。

サイト運営。

記事制作。

顧客対応。

社内ルール。

こうした仕事は、1日で終わりません。

昨日の続きが今日あり、今日決めたことが来週の仕事につながります。

だから、AI社員との仕事で一番怖いのは、

「前のAIが知っていたことを、次のAIが知らない」

状態です。

今回、その不安がかなり現実的な形で起きました。

作業途中で、AI社員が突然止まったのです。

そして翌朝、

別のAIが、前日の仕事を全部読み直して復旧しました。

今回はその話です。

夜、引き継ぎを書いたあとにAI社員が止まった

オフィスピコッツでは、AI社員との1回の作業会議が終わるたびに、必ず引き継ぎを残しています。

会話だけを残して終わりにはしません。

その日に決まったこと。

返事待ちの相手。

次にやること。

確定したルール。

更新した台帳。

こうした内容を、Google Driveのファイルへ書き出します。

そして次の会話では、

「まずこの引き継ぎを読んでから仕事を始める」

という運用にしています。

この方式で、すでに30回以上の作業会議を重ねてきました。

今回も、夜の作業終了前にAI社員が引き継ぎ書を作りました。

内容の検算も済ませています。

ここまではいつも通りでした。

そのあと、もう一つの台帳を最新版へ更新する作業へ進みます。

ところが途中で、

返答が止まりました。

今回の長い会話では、扱えるコンテキスト量の上限に達し、それ以上作業を続けられなくなりました。

人間に例えるなら、

引き継ぎを書いたあと、次の仕事を途中まで始めたところで力尽きた

ような状態です。

翌朝、新しいAIへ伝えたのは一言だけ

翌朝、新しい会話を立ち上げました。

前日のAIとは別のAIです。

私が最初に伝えたのは、

「昨日の内容を全部確認して、引き継ぎ漏れのない状態に仕上げて」

という趣旨の指示だけです。

こちらから、

「このファイルを見て」

「昨日はここまでやって」

と一つずつ説明し直してはいません。

新しいAIは、まずGoogle DriveのAI社員用フォルダを確認しました。

そこで、いきなり一つおかしな点を見つけます。

「作成済み」と書いてあるのに、そのファイルが存在しない

前日の引き継ぎ書には、

「台帳の新版は本日作成済み」

という記録が残っていました。

ところがGoogle Driveのフォルダを探しても、

その新版がありません。

前日のAIは、

「これから作る予定だったもの」

を、

「もう作ったもの」

として引き継ぎへ書いてしまっていました。

悪意があるわけではありません。

ただ、記録と実物が食い違っています。

これはかなり危険です。

もし新しいAIが引き継ぎ書だけを信じて、

「新版は完成済み」

という前提で次の仕事へ進んでいたら、

存在しないファイルを前提に、その後の作業が積み上がる

ところでした。

引き継ぎ書を信用せず、会話118回分を全部照合した

そこで新しいAIは、前日の作業ログを最初から確認し直しました。

対象になったのは、

118回分のやり取り。

かなりの量です。

その会話ログと、前日に作られた引き継ぎ書を一つずつ照合します。

決定事項は全部入っているか。

返答待ちは抜けていないか。

件数は合っているか。

確定したルールが欠落していないか。

予定と実績が混ざっていないか。

その結果、

引き継ぎ書の内容そのものには脱落がありませんでした。

問題だったのは一つだけ。

「作成済み」と書かれていた台帳が、実際には未作成だったこと。

です。

新しいAIは、前日の会話ログを材料にその新版を実際に作成。

引き継ぎ書側の誤記も修正。

これで前日の作業と、翌日の開始地点が一致しました。

私がやったのは、

最初の指示と最後の確認くらいです。

記憶はチャットではなく、ファイルに置く

なぜ今回、翌朝の別AIが復旧できたのか。

一番大きかったのは、

仕事の記憶をチャットだけに置いていなかったこと

です。

オフィスピコッツでは、AI社員用のGoogle Driveに、大きく5種類のファイルを置いています。

基本台帳。

引き継ぎ書。

サイト台帳。

営業台帳。

確定文面集。

チャット内で、

「前にこう言いましたよね」

という記憶へ頼るのではなく、

確定したことは外部ファイルへ書き出す。

AIが途中で止まっても、ファイルは残ります。

新しいAIは、そのファイルを読んで仕事を再開できます。

今回の事故で、

この設計が実際に機能することを確認できました。

5ファイルには、それぞれ役割がある

単純に、

「全部1つの長い引き継ぎファイルへ書けばいい」

とはしていません。

仕事の種類によって分けています。

基本台帳には、会社として変わりにくいルールや確定情報。

引き継ぎ書には、今回決まったこと、返事待ち、次の作業。

サイト台帳には、各サイトの状態やURLなどの管理情報。

営業台帳には、提案した相手や反応。

確定文面集には、実際に採用した文章。

こうしておくと、

新しいAIが全部の履歴を毎回読み直す必要はありません。

まず引き継ぎを読む。

必要になったら基本台帳を見る。

営業なら営業台帳を見る。

記事なら確定文面を見る。

仕事に応じて、必要な記憶だけ読む。

人間の会社でも、

何でも一冊のノートへ書くより、

顧客台帳。

案件管理。

マニュアル。

議事録。

と分けた方が使いやすいのと同じです。

「件数を書く」だけで、引き継ぎはかなり強くなる

もう一つ、今回かなり効いたルールがあります。

それが、

件数を書くこと。

です。

たとえば引き継ぎ書には、

「送付・着手待ち　22件」

「返答待ち　22系統」

のように、

項目名だけではなく数も書きます。

なぜ件数を書くのか。

次のAIが、

もう一度数え直せるからです。

引き継ぎ書には22件と書いてある。

実際に数えたら21件。

それなら、

どこか1件抜けている。

とすぐ分かります。

文章だけの要約だと、

一項目抜けていても気づきにくい。

でも数字があると、

機械的に検算できます。

AIは文章を要約するのは得意です。

その一方で、

要約の途中で何かを省略する可能性もあります。

だから、

要約とは別に、数で検算できるようにする。

今回、かなり有効でした。

「返事待ち22件」ではなく「22系統」としている理由

今回の引き継ぎ書では、単純な件数だけでなく、

22系統

という表現も使っています。

例えば一人の相手と、複数のやり取りが続いている場合があります。

メールが3通あったから3件ではなく、

「この相手から返答待ち」

という一つの流れとして扱う。

そのため、

単純なメール数ではなく、

仕事として何本の返答待ちがあるか

を数えます。

これも、

人間が引き継ぐときと同じです。

メールの通数を数えても、仕事の残数は分かりません。

「今、誰の返事を待っているのか」

を単位にした方が使いやすい。

AI社員との引き継ぎも、だんだん普通の業務管理に近づいてきました。

最後の保険は、会話ログそのもの

今回、引き継ぎ書にはほぼ問題がありませんでした。

でも、一つだけ「作成済み」という誤記がありました。

もし引き継ぎ書の内容自体が大きく壊れていたらどうするか。

そのときの最後の保険が、

会話ログそのもの

です。

今回、新しいAIは118回分を読み直しました。

かなり地道です。

でも、

「昨日、本当は何を決めたのか」

を確認する材料としては、これ以上確かなものはありません。

引き継ぎ書は、会話を圧縮したものです。

圧縮すると、情報は減ります。

だから、

要約したファイルと、元データの両方を残す。

普段は要約を使う。

何かおかしいときだけ元ログへ戻る。

この二段構えが効きました。

AIの「作ったつもり」を検算で止められた

今回、一番印象に残ったのは、

未作成のファイルを、

「作成済み」

と記録していた点です。

AIは、自信を持って間違うことがあります。

今回も、

悪意なく、

「この後作る予定だったもの」

と、

「既に完成したもの」

が混ざりました。

ここで大事なのは、

AIを信用するか、信用しないか

ではないと思っています。

信用ではなく、

検算できる形にする。

ファイルが作成済みなら、

本当にそのファイルが存在するか検索する。

22件と書いてあるなら、

本当に22件あるか数える。

新版と書いてあるなら、

バージョン番号を見る。

こういう確認を、AI自身にもやらせる。

これなら、

「AIだから間違える」

ではなく、

間違えても見つけられる運用

にできます。

新しいルール1：「作成済み」は実物を確認してから書く

今回の事故から、引き継ぎルールを一つ追加しました。

今後、

「作成済み」

と引き継ぎ書へ書く場合は、

その前に、

実際のファイルが存在することを確認する。

というルールです。

フォルダを検索。

ファイル名を確認。

最新版か確認。

そこまで終わってから、

「作成済み」

と記録します。

予定と実績を混ぜない。

AIだけの問題ではありません。

人間の仕事でもよくあります。

「やります」

と、

「やりました」

は別です。

新しいルール2：力尽きそうなら、全部完成させようとしない

もう一つ追加したのが、

会話の終盤で無理をしない

というルールです。

今回のAIは、

引き継ぎ書を完成。

そのあと、さらにもう一つ大きな台帳を作ろうとして止まりました。

結果として、

その2つ目について、

「作ったつもり」

が引き継ぎへ混ざりました。

今後は、

残りコンテキストが少なくなった場合、

大きな成果物を2つ作ろうとしない。

1つ目を確実に完成。

保存。

検算。

その後、残り時間が危なければ、

2つ目は、

「材料だけ残す」

ところで止める。

翌日のAIへ回します。

これも人間の仕事と同じです。

退勤5分前に、大きな仕事をもう一つ始めない。

「AIは記憶が消えるから仕事に使えない」は半分正しい

AIを業務利用する話をすると、

「でもAIって前のこと忘れるでしょう？」

と聞かれることがあります。

今回の事故を見ると、その不安はよく分かります。

長い会話が途中で止まる。

新しいチャットになる。

以前の会話内容をそのまま前提にはできない。

でも今回、実際に復旧して感じたのは、

記憶が消えること自体が問題なのではなく、記憶をどこに置いているかが問題

ということです。

人間も同じです。

担当者が休む。

退職する。

忘れる。

記憶違いをする。

それでも仕事が回る会社は、

担当者の頭の中だけで仕事をしていません。

台帳。

議事録。

共有フォルダ。

マニュアル。

案件管理。

引き継ぎ。

そこへ仕事の状態を残します。

AI社員でも、同じことをやっただけです。

属人化対策をAI相手に本気でやってみた

今回の仕組みを一言で言えば、

属人化しない業務設計

です。

人間相手なら、

「○○さんしか分からない」

状態を減らそうとします。

AIでも、

「このチャットしか分からない」

状態を減らす。

会話の中だけに確定事項を置かない。

誰が次に来ても読める場所へ保存する。

件数を付ける。

バージョンを付ける。

元ログも残す。

今回、AIが途中で止まったことで、

この仕組みが単なるルールではなく、

本当に復旧に使えること

を確認できました。

復旧コストは0円だった

今回、新しいツールは導入していません。

特別なデータベースもありません。

使ったのは、

• Google Drive
• 決まった形式の引き継ぎ書
• 会話ログ
• 件数を数えるルール

です。

追加固定費は、

0円。

翌朝、新しいAIが記録を読み直して復旧。

未作成の台帳も完成。

引き継ぎ書も修正。

前日の状態へ戻せました。

AI社員が入れ替わっても、仕事の人格は残せる

ここで少し面白いことも感じました。

前日のAIと、翌日のAIは別です。

それでも、

同じ基本台帳。

同じ引き継ぎ。

同じルール。

同じ確定文面。

同じ営業履歴。

を読めば、

かなり近い方針で仕事を再開できます。

AIそのものに人格が固定されているわけではありません。

でも、

会社の仕事の仕方をファイル側へ置いておくと、AIが変わっても「オフィスピコッツのAI社員」として働きやすくなる。

最近は、そう考えるようになりました。

今回の結論

今回、AI社員は作業途中で止まりました。

翌朝、別のAIが、

Google Driveの引き継ぎ書を確認。

会話ログ118回分を照合。

引き継ぎ内容の脱落がないことを確認。

「作成済み」と書かれていた未作成ファイルを発見。

実際に新版を作成。

引き継ぎの誤記も修正。

前日の仕事を復旧しました。

AIが優秀だったから復旧できた。

それだけではありません。

AIが倒れても拾えるように、仕事を外へ残していた。

そこが一番大きかったと思います。

今回持ち帰ったルールは、

「AIに覚えさせる」のではなく、「次のAIが読めるように残す」

です。

AIと長く仕事をするなら「途中で倒れる前提」にする

AIは便利です。

でも、

会話が長くなれば上限があります。

サービス側の仕様変更もあります。

モデルも変わります。

接続が切れることもあります。

だから、

絶対に止まらないAI社員

を期待するより、

止まっても翌日復旧できる職場

を作る方が現実的です。

これはAIだけの話ではありません。

人間の仕事でも、

優秀な担当者を探すことと同じくらい、

その担当者が休んでも回る仕組みを作ることが大切です。

AIを使い始めて、改めて普通の業務設計の重要さを学んでいる気がします。

あなたの会社の仕事、担当者が明日休んでも続きますか

AI活用を考える前に、

実は一度確認しておいた方がいいことがあります。

会社の仕事が、

誰かの頭の中だけに入っていないか。

顧客対応。

サイト管理。

営業状況。

定例作業。

文章テンプレート。

「○○さんしか分からない」

という仕事は、人間でもAIでも引き継ぎに弱くなります。

オフィスピコッツでは、AI導入そのものだけでなく、

AIへ仕事を任せられる状態に業務を整理するところ

からご相談いただけます。

• 無料AI活用診断：https://pikoz.net/ai-shindan/
• AI社員構築サービス：https://pikoz.net/ai-shain/
• ネット顧問：https://pikoz.net/komon/
• AI社員実践記：https://pikoz.net/category/ai-jissen/

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

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