【AI社員実践記 第39話】返事は、もう来ていた。「相手待ち」を見張る14日ルール

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

「なんか違いますよね。すでにいろいろ進めてる」

AI社員が出してきた「相手待ち」の一覧を見て、こう返しました。そこにあったのは、お客様からの返事を待っていることになっていた作業です。でも、その案件はすでに先へ進んでいました。

メールを読み直すと、返事は届いていました。止まっていたのは案件そのものではなく、作業表の更新だったのです。

2026年10月11日の日曜日、期限を過ぎた仕事を知らせる仕組みに、相手待ちの行を追加しました。それまで通知の対象外だった行も、表の作業日から14日以上たてば、見直し候補に出すためです。

直した初日に見つかったのは、長い返事待ちだけではありませんでした。待ち区分の取り違え、日付の空欄、延期の繰り返し。今回は、見張る範囲を広げたことで、作業表の書き方まで見直した一日の記録です。

「自分の作業」の見張りには、対象外の行があった

当社では、お客様の作業と社内の作業を、それぞれ表で管理しています。1行が一つの作業で、作業日と、待ち区分を記録しています。

待ち区分は、「なし」「自分待ち」「顧客待ち」「社内確認待ち」などです。日付だけでは分からない、次に誰が動く段階なのかを示すための項目です。

毎朝の期限超過の通知は、10月4日に作りました。予定日を過ぎた作業に気付けなかったことがあり、その対策として用意したものです。二つの作業表の写しを読み、作業日を過ぎた未着手・進行中の行を探します。

既存の運用では、朝6時半に処理し、対象があれば私へ知らせることにしていました。AI社員も、その一覧を朝の確認に使う流れです。

ただし、拾うのは待ち区分が「なし」か「自分待ち」の行だけでした。相手からの返事や社内確認を待つ行は、自分だけでは進められないものとして外していたのです。

10月11日は、返事待ちや預かりとして残っていた7件から見直しを始めました。その中で、この対象外という扱いが問題になりました。相手待ちのままなら、日付がどれだけ古くなっても、既存の通知には出てきません。

通知が静かだから、古い仕事がないとは限らない。そもそも見ていない範囲がある、ということでした。

14日で催促するのではなく、14日で見直す

AI社員が提案したのは、相手待ちの行も、作業日から14日以上たったら一覧の最後へ出す変更でした。

私は「1進める」と返し、提案の一つ目だったこの修正を進めることにしました。

ここでいう14日は、返事を待ち始めてからの正確な日数ではありません。表に入っている「作業日」から数える設定です。依頼メールの送信日や、最後に連絡した日を自動で調べて数える仕組みではありません。

また、14日たったら相手へ自動で催促するものでもありません。私たちが、その行を読み直すための目安です。

本当に返事が必要なのか。すでに届いていないか。次に見る日を決めるべきか。もう閉じてよいのか。そこを一件ずつ判断します。

既存の扱いでは、「保留」「中止」「預かり」などと記した行は一覧から外れます。今回も、私が持っておくと決めた件は、預かりとして扱いました。ただし、一覧から外すことと、仕事が完了することは別です。預かったものをいつ見直すかは、別に残る管理の仕事です。

14日という数字も、すべての業務に共通する正解ではありません。今回、相手待ちを見直すきっかけとして置いた当社の運用上の目安です。

動いている処理は、変更する9か所を絞って直す

期限超過の通知は、すでに使っている仕組みです。相手待ちを足すために、今まで出ていた自分の作業が出なくなっては困ります。

そこで今回は、ファイル全体を新しいものへ入れ替えるのではなく、変更箇所を絞って書き換える方法を使いました。いわゆるパッチです。

AI社員が用意したのは、9か所を変更する処理でした。変更対象が見つからない場合は、書き換えずに止まる。変更前のファイルを控えとして残す。変更後には、文法上の誤りがないかを確かめる。そうした手順で進めます。

AI社員からの事前の確認報告では、元の処理と当時の作業表の写しを使い、翌朝として動かした比較も行っています。既存の自分の作業欄は変わらず、最後に相手待ちの欄が加わった、という報告でした。

私がサーバーで修正を実行すると、画面には「9か所を当てた」という結果と、控えの保存先が出ました。

変更範囲を絞り、控えを残すことは、確認や戻し作業の助けになります。ただ、それだけで修正が正しいと保証されるわけではありません。文法が通ることと、欲しい行を拾えることも別です。次に、実際の出力を確かめました。

メールを送らないテストで、自分の作業3件と相手待ち2件

最初の実行は、メールを送らない形にしました。どんな一覧ができるかを見てから、毎朝の運用へつなげるためです。

結果は、自分の作業が3件、追加した相手待ちが2件でした。

自分の作業3件の内訳は、お客様の作業が2件、社内の作業が1件。相手待ち2件は、その3件とは別の欄に出ています。

一覧に出たことは、確認すべき候補が見えたということです。5件すべてを、今日すぐ作業しなければならないと決めたわけではありません。

実際、追加欄の一つは、私が預かると判断した件でした。そしてもう一つが、冒頭で「なんか違いますよね」と返した件です。

返事待ちの行を閉じても、引き継ぎはまだ終わらない

その行は、リニューアルに必要な確認への返事を待っている扱いでした。しかし私は、その後のやり取りが進んでいることを覚えていました。

AI社員がメールを読み直すと、必要な返答はすでに届き、私から次の進め方も案内していました。それなのに、作業表では返事待ちの行が残っていたのです。

返事が届いたことを、表へ反映するのが抜けていました。これを、そのまま催促の材料にしていたら、相手からすれば「もう返事をしたのに」となるところです。

しかも、古い行だけの問題ではありませんでした。返事の中で確定した条件が、次に行う作業の行へ引き継がれていませんでした。次の準備に使う欄にも、まだ「質問中」という意味の記述が残っていました。

そこで、確定した条件を次の作業へ書き足し、返事待ちの古い行を閉じました。

行を一つ完了にすれば終わり、ではありません。返事を読んだ結果、次の作業の前提が変わったなら、そちらも更新する必要があります。

今回、見張りは古い行を見つけました。でも、返事が来ていることや、その中身まで自動で判断したわけではありません。メールと作業表を照合したことで、待つ必要がなくなっていたと分かりました。

見張りを直した初日に、見張りへ渡すデータの方にも修正が必要だと分かりました。

さらに見直すと、止まり方が三つに分かれた

私は続けて聞きました。

「これ以外に止まってると判断できるものはあるか？」

AI社員は、二つの表とメールを照らし合わせました。すると、14日の欄を加えるだけでは解決しない状態が見えてきました。

一つ目には、当社から手続きをやり直すと伝え、先方から返答もあったのに、表では相手待ちになっている件がありました。メールでこちらが次の行動を引き受けているなら、待ち区分もそれに合わせる必要があります。

ただ、確認したメールに実行の記録がないことだけで、絶対に未実施だと断定はできません。私も状況を確認し、前提条件が整ったあとに当社が進める作業として、自分待ちへ直しました。

二つ目は、社内の表で見つかった日付のない9行です。今回の通知は作業日を基準にするため、空欄のままでは期限超過として拾えません。「日付のない行を探す」という別の見方が必要でした。

三つ目は、延期です。法人番号データを利用するためのID申請は、作業日を4回先へ送っていました。サイトのバックアップ作業も、失敗したあと、3回先へ送っていました。

今の日付だけを見ると、新しく予定した仕事に見えます。でも、そこへ来るまでに何度延期したかは分かりません。今回は作業の経緯をたどって見つけたもので、延期回数を自動で拾う機能まで作ったわけではありません。

一覧を減らすより、次にどう扱うかを決める

出てきたものを、まとめて今日の作業へ戻すわけにはいきません。私が預かるもの、閉じてよいもの、次に見る日を入れるものを分けました。

棚卸し全体の記録では、預かりとしたものが2件、閉じたものが2件、日付を入れたものが5件あります。最初の7件に加えて、その後に見つけた行も確認しているため、これらを単純に足して「最初の7件を何件処理した」とは数えません。

延期していた二つについては、その日に進めることにしました。

「法人番号今から」「バックアップもそのあと」

私の返事は、それだけでした。新しい予定日を入れる前に、今できるところへ着手することにしたのです。

一方、前提条件を待つ作業は、今日すぐ終わらせられるとは限りません。大切なのは、一覧の件数を減らすことだけではなく、誰が何を待ち、次に何をするのかを明確にすることでした。

4回延期していた申請は、実際の画面を見て進めた

法人番号データをプログラムから取得するための、アプリケーションIDの申請に進みました。

9月に作った手順書がありましたが、その説明と、今回開いた申請画面が一致しませんでした。画面を見ながら、必要な手順を組み直しました。

ここは、古い手順書の方が必ず正しいとは考えないようにします。一方で、画面が違うからといって、いつ制度やページが変わったかまで断定することもしません。今回必要な手続きは、実画面と現在の公式案内で確かめます。

国税庁の法人番号システムWeb-APIの案内にも、利用にはアプリケーションIDが必要で、申請手続きは適格請求書発行事業者公表サイトから行うと説明されています。

この日の作業記録では、15時38分に申請が終わりました。ただし、申請の完了とIDの発行は別です。公式案内の発行目安は2週間から1か月程度で、この日にIDを受け取り、データ取得まで動かしたという話ではありません。

止まっていた申請は進められました。その先の受け取りと動作確認は、次の仕事として残ります。

バックアップは再試行が通っても、保存範囲を分けて考える

続いて、バックアップです。1回目は、また失敗しました。

今回はエラーの記録を確認でき、データベースを書き出す途中でメモリ不足になっている、と作業記録に残っています。その途中では、AI社員がサーバー会社を取り違えて案内する場面もありました。私の画面で気付き、環境に合わせて直しました。

次の案は、画像や、不要なコメント、記事の過去の編集履歴などを除外して、書き出す量を軽くする方法でした。再試行は、16時に通ったと記録されています。

ただし、ここを「サイト全体のバックアップがそろった」とは書けません。今回の資料だけでは、実際に何を除外したか、ほかの設定も変えたか、保存物に何が含まれているかまでは確認できないからです。

仮に画像を除外していれば、そのファイルだけで画像まで戻せるわけではありません。必要なデータが別に保存されているかも含めて考える必要があります。処理が完了したことと、必要な状態へ復元できることは別です。

今回進んだのは、失敗したまま延期していた処理を再開し、再試行の完了まで持っていったところです。保存範囲と復元の確認まで済んだ、という結論にはしません。

今回の数字と、まだ残っている確認

今回追加したのは、相手待ちが古くなったら、こちらへ戻して見るための欄です。作業表の誤りを全部直す機能でも、相手へ自動で連絡する機能でもありません。

日付のない行や、延期を繰り返す行を継続して見つける仕組みも、今回の修正だけでは完成していません。そこは、次に整える余地として残っています。

それでも、対象外だった行を見直すきっかけができたことで、届いていた返事と、更新されていない作業表のずれが見つかりました。次の作業に必要な条件も、改めて引き継げました。

見張りを作ると、知らせに出てきたものへ目が向きます。今回は、その反対側の、出てこないようにしていた行を見ることが役に立ちました。

「相手待ち」と書いてあっても、本当に相手の番なのか。予定日が先でも、それまで何度送ってきたのか。表の一語や一つの日付だけで決めず、やり取りと経緯へ戻って確かめる。その入口を一つ増やした日でした。

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

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

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