【AI社員実践記 第35話】更新メール24件から、立替費用の請求漏れ2件を見つけた日

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

更新のお知らせを24件読ませたら、請求の記録が見当たらないものが9件残りました。私が1件ずつ確かめると、そのうち2件は本当の請求漏れでした。1件は4月の更新分。9月になっても、お客様のために立て替えた費用を請求できていませんでした。

作業したのは、2026年9月29日の火曜日です。監視サーバーからGmailを読み、更新に関するメールをスプレッドシートへ記録する。その記録と顧客管理表を突き合わせ、請求の行が見当たらないものを知らせる仕組みを作りました。

第28話では、サーバーに台帳を読ませ、棚卸しの材料を抜き出しました。今回は、台帳の外に届いているメールと、台帳の中にある請求の記録をつなぎます。「更新された」と「請求した」の間に残った仕事を、見えるようにするためです。

ただし、機械が出した9件すべてが請求漏れだったわけではありません。請求済みのものも、入金済みのものも混ざっていました。今回は、見つけた2件だけでなく、残りをどう仕分け、次の更新でまた見落とさない形にしたかも書きます。

自動で支払われる費用ほど、請求が後回しになる

前日の9月28日、請求まわりで2種類の抜けが見つかりました。以前に作った請求書が送付されずに残っていたことと、当社が立て替えている更新費用が請求されていなかったことです。

AI社員からは、それぞれを見張る案が出ました。請求の作業が期限を過ぎても残っていたら拾う仕組みと、更新の知らせを基に立替費用を拾う仕組み。今回は後者を詰めました。請求書の送り忘れと、そもそも請求の作業が立っていないことを、分けて考えた形です。

当社で扱うドメインの更新費用には、年に数千円程度のものがあります。自動更新なら、カードから支払われ、更新のお知らせがメールで届きます。ここまでは、人が操作しなくても進みます。

一方で、お客様への請求は「月末にまとめて」「次の請求書へ一緒に載せて」と後回しになりがちです。更新費用は支払っているので、サイトが止まるわけでもありません。請求の抜けが、サイトの不具合として知らせてくれることはないのです。

当社には立替金が残り、お客様への請求も遅れます。「誰も困らない」のではなく、その場で気づくきっかけが少ない。ここを、月末に私が思い出せるかどうかに任せていたのが問題でした。

そこで、更新のメールが届いた事実を、毎朝表へ移しておくことにしました。メールを探し直すところから始めず、請求の記録と並べて確認できる材料を残します。

仕組みを決める前に、実際のメールを見た

前日にAI社員が出した案は、いくつかの部品をつなぐものでした。Gmailのフィルタでメールを転送し、Cloudflare側で受け、小さなプログラムで中身を読み、サーバーへ渡して表に書き込む。やりたいことに対して、経由する場所が多い案でした。

29日は、先に実際のメールを4月までさかのぼって調べました。どの会社から、どんな件名で届き、本文に何があるのか。確認したメールには、次の違いがありました。

同じ更新に関わるメールでも、更新完了、入金の通知、これからの更新予告では意味が違います。件名に「更新」があるからといって、すべてを支払い済みの立替費用として扱うことはできません。

実物を見てから、入口を変えました。既存のサーバーが、毎朝Gmailを直接読みに行く形です。新しく転送先を設けず、サーバー側のPythonプログラムで、読み取りから表への記録まで進めます。

既存のメール接続設定とスプレッドシートへの接続を使うので、今回追加する処理の置き場を絞れました。ファイル1本で仕事が完結するという意味ではなく、メール、表、認証情報、定期実行という前提の上に、読み取りの処理を追加する形です。

最初の案をそのまま実装していたら、後から確認する場所も増えていたと思います。届いているものを見てから入口を決めたことで、今回必要な構成がはっきりしました。

まず、メールを読めるところまで確かめる

本体を作る前に、サーバーからGmailへ接続し、対象のメールを検索できるかを試しました。メールを読むための通信方式であるIMAPを使い、確認用の処理ではメールボックスを読み取り専用で開きます。

画面の結果は、ムームードメインが31通、Wixが2通、バリュードメインが3通でした。検索期間は同じではなく、順に8月以降、5月以降、9月以降です。ここでの件数は接続と検索を確かめるためのもので、後から4月以降を読み取る24件とは、条件が違います。

今回の接続では、既存のアプリパスワードを使っています。ただし、「読み取り専用」は処理側でメールボックスを開く方法の話です。パスワード自体の権限を読み取りだけに制限した、という意味ではありません。PythonのIMAPの説明

アプリパスワードは認証情報なので、値は画面へ出さずに扱いました。これは当社の既存環境で行った実装の記録です。Googleは通常「Googleでログイン」の利用を推奨しており、この接続方法を新規導入の標準として勧めるものではありません。Googleのアプリパスワードの説明

24件は「請求する件数」ではなく、メールから拾った記録

接続を確かめたあと、メール本文の形に合わせて読み取りの処理を作りました。日付、会社、ドメイン名、金額、更新日などを取り出し、スプレッドシートの「立替更新ログ」というタブへ書く設計です。顧客名は、管理サイトの一覧と対応させます。

同じメールを繰り返し記録しない設計も入れています。毎朝動かす処理なので、昨日読んだメールを今日も見つけることを前提にする必要がありました。

最初は、表へ書き込まない試し実行です。対象は4月1日以降。結果は24件でした。内訳はムームードメインの自動更新10件と入金10件、バリュードメインの更新完了1件、Wixの更新予告2件、さくらの決済通知1件です。

ここでの24件は、メールから取り出した記録の数です。24社でも、独立した24件の更新でも、24件の請求漏れでもありません。同じ対象に関する別種類の通知が含まれる可能性もあり、件数や金額をそのまま請求の総数・総額にはできません。

Wixの2件も、今回読んだのは更新の予告です。メールを受信した日と、実際の更新日を分けて考えます。また、さくらの決済通知には対象ドメインがないため、このメールだけでお客様の請求行へ自動的に対応させることはできません。

まず記録を集める。そのうえで、今回の条件で突き合わせられるものを絞る。この順番にしたことで、読み取りに成功した件数を、そのまま成果として大きく見せずに済みました。

9件を人が仕分けすると、本当の請求漏れは2件だった

24件を表へ書き込んだあと、月末用の突き合わせを試しました。この段階ではメールを送りません。結果を画面に出し、知らせる対象が妥当かを先に確かめます。

当社で決めた条件は、更新から2か月たっても、顧客管理表にそのドメイン名を含む「請求」の行が見当たらないものを拾う、というものです。この2か月は当社の確認条件で、請求期限や支払期限を定めたものではありません。

結果は9件でした。

私が1件ずつ見直すと、内訳は次のようになりました。

2＋1＋2＋3＋1で9件です。機械が見つけたのは、請求の記録と結び付かなかったもの。その中に、実際の請求漏れ2件が含まれていました。

漏れていたうち1件は、4月の更新から約5か月が過ぎていました。金額やお客様名は掲載しませんが、更新の通知を受け取っただけでは、請求まで進んだことにはならないと分かる結果でした。

一方、ドメイン名がなかった2件は、行に「ドメイン更新実費」などと書かれていました。人が読めば分かっても、ドメイン名を目印にする処理には結び付けられません。入力の書き方が、機械の判定を左右していました。

これを受け、立替請求の作業表にはドメイン名を記載することにしました。私の返事は「立替請求の作業表にドメイン名はあった方がいい」。今回の誤検出を、その場の手直しだけで終わらせず、次に行を書くときの決まりへつなげました。

「いつも外す」と「その回だけ外す」を分けた

入金済みのものまで、毎月知らせる必要はありません。ただ、外し方を間違えると、次の更新で起きた請求漏れまで見えなくなります。

そこで、除外のリストを2種類に分けました。ドメイン名だけなら、今後も対象から外す。ドメイン名と日付を組み合わせた行なら、該当する回だけ外す。自社ドメインと、今回の入金確認済みの記録を、同じ扱いにしないためです。

請求済みで入金待ちの1件も、今回の「請求の行がないものを拾う」通知からは外しました。ただし、入金を確認する仕事まで完了にしたわけではありません。翌日の連絡予定として、別に残します。

請求する仕事、送付する仕事、入金を確認する仕事は、それぞれ状態が違います。立替の通知を減らすために、必要な確認まで消してしまわないことが大切でした。

再確認では候補なし。毎朝と月末の2行を登録した

請求行へのドメイン名の追記、新しい請求作業2件の登録、除外リストの設定を終え、もう一度突き合わせました。画面には「送信なし（見当たらない更新なし）」と出ました。

ここでの候補なしは、今回の条件で引っかかる記録がなくなったという意味です。2件の請求書を送付し終えたことや、すべて入金されたことの証明ではありません。請求の作業行を立てれば、この見張りの対象から外れるので、その後の作業は台帳で追う必要があります。

最後に、サーバーの定時実行であるcronへ2行を追加しました。毎朝7時25分にメールを読み、表へ記録する。月末の朝7時35分に、請求の記録と突き合わせる、という設定です。

請求行が見当たらない候補を、月末に知らせる設計にしました。ドメインを特定できない決済通知は、人が見る対象として扱います。画面の「送信なし」は今回の再確認の結果であり、あらゆる確認事項がなくなったという意味ではありません。

作業メモでは、深掘りに入った15時すぎから再確認まで約30分です。前日の検討や事前のメール調査まで含む総作業時間ではなく、今回の実装と確認の目安として記録しています。

この日に確かめたのは、手動での読み取り、表への記録、突き合わせの結果と、定期実行への登録です。毎朝・月末に自動で動いた後の記録までは、この回の資料には含まれていません。登録した時点で、継続運用も確認済みとはしません。

同じ日に見直した、もう2つの置き忘れ

この日は、立替費用のほかにも、予定と報告の置き方を見直しました。

一つは、サイトの定期作業を完了にしたあと、次回の予定行がない先が5件あったことです。完了と次回の予定が別々に扱われていたため、今回の仕事だけが閉じ、次の仕事が残っていませんでした。

作業記録では、AI社員が更新用のファイルを作る際、完了にした先の次回行が同じファイルにあるかを機械で確かめ、なければ作成を止める形にしています。さらに、次回の予定がない先を抜き出すタブも顧客管理表へ追加しました。

もう一つは、毎週月曜に届いていた5通の報告メールです。読むだけで終わる週が多かったため、数字を表に残し、条件に当たったときにメールで知らせる形へ変更しました。

この2つも、毎回覚えておく仕事を減らすための見直しです。ただし、この回に掲載した画像5枚が示すのは立替費用の処理です。ほかの変更について、継続運用の結果まで示しているわけではありません。

今回できたことと、残しておく確認

メールの形式が変わっても読めるか。同じメールを読み直しても増えないか。翌年の更新を、前年の請求行や除外指定で見逃さないか。この先の運用で確認すべき点は残っています。今回の1回の結果だけで、すべての請求漏れを防げるとは言えません。

それでも、受信箱に埋もれていた更新の記録を、請求の作業と突き合わせるところまでは進みました。請求漏れ2件を見つけ、誤って候補になった理由を整理し、入力の決まりと除外の扱いを直せたことが、この日の成果です。

今回よかったのは、9件という結果をそのまま正解にしなかったことでした。人が仕分けたことで、本当に請求するもの、書き方を直すもの、別の仕事として追うものが分かれました。

AI社員に任せたかったのは、請求漏れだと断定してもらうことより、私が確かめるべき記録を並べてもらうことです。その先の判断と、決めた作業を終えるところまでつないで、初めて立替費用の見張りになります。

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

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

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