【AI社員実践記 第30話】AIに表を直接触らせない。「受け箱」を1つ挟んだ日

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

土曜の朝、10時29分にGoogleドライブへフォルダを1つ作り、10時50分に作業表の1行が自動で書き換わりました。フォルダを作ってから、最初の自動更新を確認するまで21分。今あるサーバーを使ったので、今回のために増やした費用は0円です。

自動化したのは、AI社員が出した作業の記録を、私がコピーしてGoogleスプレッドシートへ貼る工程です。新しい作業なら一番下へ追加し、進み具合が変わったら同じ行を探して貼り直す。毎日やっていた、小さな手作業でした。

ただ、AI社員へ表を自由に編集させる形にはしていません。間に「受け箱」のフォルダを置き、表へ書くのはサーバーのプログラムにしました。今回は、そこへ行き着くまでの提案と、誰に何を許すかを決めたやり取りの記録です。

1行10秒でも、貼り忘れると翌日の仕事になる

AI社員は、作業の予定や結果を、表へ貼れる1行にして出します。管理ID、日付、作業の内容、進み具合、担当などをタブで区切ったものです。私はその行をコピーして、自社の作業表へ貼っています。

新規の作業なら末尾へ追加すれば済みます。ただ、進行中の仕事が完了したときには、同じ管理IDの行を探さなければなりません。新しい行として貼ると、同じ作業が「進行中」と「完了」の2行で残ってしまうからです。

1行なら10秒ほど。この日は朝のうちに4行、前日は十数行ありました。毎回大変だと感じるほどではありませんが、AI社員と相談したあとに、私が記録を移す工程が必ず残ります。

貼り忘れると、翌日のAI社員は、まず表に反映されているかを確かめるところから始めます。列がずれたまま入っていた行もありました。相談の中では終わっている仕事が、表の上では終わっていない。記録を次の仕事に使うために、転記まで終える必要がありました。

第28話では、サーバーが顧客台帳を読み、未着手・進行中の行を抜き出せるようにしました。今回は、自社の作業表へ記録を入れる側です。読む手間を減らしたあとに、毎回手で貼っているところが残っていました。

最初の活用案は、3つとも「不要」と返した

最初から受け箱を作ろうとしていたわけではありません。この日の朝、AI社員に「サーバーの活用案を出して」と頼みました。もともと毎回出す決まりでしたが、引き継ぎ書を作り直したときに、その指示が抜けていたのです。

出てきた案は3つありました。WordPressの自動更新を知らせる仕組み、お客様サイトのお知らせの本数を数える仕組み、サイトに入れたタグが外れていないかを見張る仕組みです。

この3つは、全部断りました。更新の知らせはWordPressからメールで届いています。お知らせの本数は、更新作業のあとに実際のサイトを見る工程があります。タグの監視も、その時点の当社では、ほかの作業より先に足したい課題ではありませんでした。

断った理由を伝えると、AI社員は提案の条件を整理し直しました。すでに届いている知らせを重ねない。人が必ず確認している工程との重複を見る。今、繰り返し手を動かしている作業から探す。そのうえで出し直してきた案の一つが、「行を貼る作業をなくす」でした。

これは、なくなれば何が減るかを具体的に言えます。AI社員が作った行を、私がコピーして表へ運ぶ工程です。先ほどの3案よりも、今の仕事に合っていました。監視の必要性を一般論で決めたわけではなく、この日の当社で何を先に整えるかを選びました。

「上書きは許可していません。それでもできるの？」

そこで気になったのが、表の書き換えです。当社では、チャット側のAI社員に、Googleドライブの既存ファイルの削除や上書きを許していません。新しいファイルを作り、古い版を残す。消す必要があれば、人が判断する運用です。

表へ行を入れることも、既存の表を書き換える操作です。「上書きは許可していません。それでもできるの？」と聞きました。

提案は、チャット側のAI社員と、表へ反映するプログラムを分ける形でした。AI社員は、受け箱へ新しいテキストファイルを置く。サーバーのプログラムがそれを読み、決めた処理で作業表へ反映する。表を編集する権限は、私がサーバー用のアカウントへ付けます。

ここで、元の禁止ルールを、そのまま別の道で通してよいことにはなりません。サーバーが表を編集する範囲について、改めて許可が必要です。AI社員からも、末尾への追加だけにするか、同じ管理IDの行の上書きまで認めるかを聞かれました。

追加だけでは、この日の4行のうち3行が手作業のまま残ります。すでにある仕事の進み具合を変える行だったからです。私は、同じ管理IDの行を更新するところまで許可しました。何でも書き換えてよいという許可ではなく、今回の転記に必要な操作を決めています。

共有の権限と、プログラムの約束を分ける

Googleドライブの通常の共有設定には、「表の一番下への追加だけ」という役割はありません。閲覧者は読むための権限、編集者は内容を変更するための権限です。編集者として共有すれば、表の内容を書き換えられます。Googleの共有権限の説明

今回、プログラムにさせることは2つに絞りました。新しい管理IDなら末尾へ追加する。同じ管理IDがあれば、その行を更新する。行を削除する処理は入れず、上書きの前には元の行をサーバーのログへ残す設計です。

これは、Google側の権限で削除を禁止できたという意味ではありません。編集できるアカウントを使い、そのプログラムに行わせる処理を限定しています。共有の設定と、コードが守る範囲は別のものです。

受け箱へ置いた内容は、最終的に表へ反映されます。AI社員が直接表を開かなくても、出したデータが間接的に表を変える点は同じです。そのため、受け取った行の列数と管理IDの形を調べてから反映する処理も用意しました。形が合っていることと、作業の内容が正しいことは分けて見ていきます。

まず対象を自社の作業表に絞ったのも、そのためです。お客様の作業履歴まで一度に広げず、自分たちの記録で運用を確かめることにしました。

受け箱は読むだけ。結果は既存の表へ書く

流れは、AI社員が新しいファイルを置き、サーバーが10分おきに受け箱を見て、新しく見つけたデータを表へ反映し、結果をメールで知らせる形です。サーバーから受け箱へファイルを書き戻す工程は設けませんでした。

この形には、同じ朝に分かったGoogle側の制約も関係しています。別のアクセスデータ取得の準備で、AI社員は当初「サーバーからGoogleドライブへCSVを置く」と提案していました。ところが、サーバー用のサービスアカウントは、保存容量を持たず、ファイルを所有できません。

今回のようにマイドライブのフォルダを共有して、新しいファイルを作らせようとする形は、そのままでは通りません。Googleの公式説明では、共有ドライブを使うか、人のアカウントを代理する認証方式を使う方法が案内されています。Googleの保存容量エラーの説明

AI社員はその制約に気づき、別件のCSV保存案を、人が用意した既存のスプレッドシートへ書く形に修正しました。今回の受け箱も、サーバーは置かれたファイルを読み、共有済みの表を更新する構成です。「共有フォルダならどこでも新規ファイルを作れる」と考えず、使うアカウントでできることを確かめました。

1回目：手で動かして、新規1行を確かめた

ブラウザ側で行った準備は3つです。受け箱フォルダをサーバー用アカウントへ「閲覧者」で共有し、作業表は「編集者」で共有する。さらにGoogle CloudでDrive APIを有効にしました。共有権限の設定が2つと、APIの有効化が1つです。

そのあと、AI社員が書いたプログラムをサーバーへ置いて、手で1回実行しました。最初から定期実行に任せず、まず1つのファイルを受け取ったときの結果を見ます。

続いてメールが届きました。「自社作業表：新規1行・上書き0行」とあります。処理が終わったという表示だけでなく、何行を追加し、何行を更新したかが分かります。

表を開くと、57行目に今回の作業が入っていました。日付は2026年9月19日、状態は「進行中」です。作業の内容が所定の列へ入り、列ずれも起きていません。受け箱方式を作っている、その作業自体を最初の1行にしました。

ログの「OK」、メールの「新規1行」、表に入った実際の行。この3つを見て、最初の追加ができたと確認しました。メールだけで完了にせず、反映先の表まで開いたところが、この試運転です。

2回目：10分おきの設定で、同じ行が「完了」になった

新規追加を確かめたあと、サーバーの定期実行設定に、10分おきに動かす1行を追加しました。次は、新規行を増やす試験ではなく、すでに入っている行を更新する試験です。

AI社員が、同じ管理IDで状態を「完了」にした新しいファイルを受け箱へ置きました。今度は、私がプログラムを手で実行したり、表へ貼り直したりせずに待ちます。

10時50分に届いたメールは、「新規0行・上書き1行」でした。

表の57行目は、「進行中」から「完了」へ変わっていました。同じ仕事がもう1行増えたのではなく、先ほど入れた行の状態が変わっています。

ここまでで、手動実行による新規追加と、定期実行による同じ管理IDの更新を、それぞれ1回確認できました。毎回の転記で必要だった2種類の動きが、実際の表でつながったことになります。

画面が崩れたとき、7,563バイトだけで判断しない

途中では、長いプログラムをサーバーの画面へ貼り付けたとき、最後の行が崩れて見える場面もありました。文字が重なったようになり、これで保存できたのか気になります。

このときAI社員は、「7,563バイトと出れば、1バイトも欠けていません」と説明していました。ただ、その説明では確認が足りません。同じ大きさのファイルでも、内容が同じとは限らないからです。

実際の作業では、保存後のサイズを見たうえで、Pythonの構文検査を通し、プログラムを実行しています。そのあと、実行ログ、通知メール、表への反映まで確かめました。構文検査も、文法上の問題を調べるもので、処理内容の正しさをすべて保証する検査ではありません。Pythonの構文検査に使った機能

この日に言えるのは、見た目が崩れていても、保存後のプログラムで今回の追加・更新が動いたということです。元のプログラムと1バイトも違わないと証明したわけではありません。AIの説明に出てきた数字と、その数字で確かめられる範囲を分ける必要がありました。

21分でできたことと、これから見ること

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

21分は、受け箱フォルダを作ってから最初の自動更新までです。その前の提案のやり取りや、今後の運用確認まで含めた時間ではありません。

この時点では、わざと形式を崩したファイルを渡して拒否されるか、保存した元の行から戻せるかまでは試していません。追加と更新が1回ずつ動いたところから、日々の運用で確かめていきます。お客様の作業履歴へ広げるかは、まず1〜2週間使ってから私が決める予定です。

また、冒頭で抜けていた「活用案を毎回出す」という決まりは、指摘したその場で別の記録に起こしました。3案を断った理由も、次の提案で読む判断材料として残しています。書き残したことで、今後同じ抜けや提案がなくなったとまでは言えません。次の引き継ぎで、その記録が使われるかも見ていきます。

行を運ぶ手間を減らし、判断するところを残す

今回なくしたかったのは、AI社員との相談のあとに残る、コピーして表へ貼る作業でした。受け箱を挟んだことで、AI社員は新しいデータを置き、サーバーは決めた手順で反映し、人は許可する範囲と結果を確認する形になりました。

実装できる案を増やすだけでは、仕事は軽くなりません。すでに届いているメールや、普段の確認と重なる提案を断ったあとで、毎日残っていた転記にたどり着きました。必要な仕組みを選ぶには、今の仕事の流れをAIへ伝えることも要ります。

表への編集を許したからこそ、何を更新し、何を残すかを決めました。まず自社の1行が追加され、同じ行が完了になるところまで確かめる。小さく始めたこの21分を、毎日の記録を途切れさせない運用につなげていきます。

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

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

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