【AI社員実践記 第31話】「どこにある？」から2日。サーバーの数字をAIが読める場所へ

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

監視サーバーの中にある稼働率の数字を、Googleスプレッドシートへ書き出しました。最初の実行結果は34サイト分。続けてもう一度動かすと、今度は「SKIP」。同じ日付のデータを重ねて入れずに終わりました。

これで、AI社員が数字を読むために、私が毎回サーバーへつないでコピーする工程を減らせます。すでに動いている週報の処理は変更せず、保存済みのデータをシートへ渡す小さなプログラムを1本追加しました。

きっかけは、2日前のやり取りです。AI社員から「稼働率のJSONを添付してください」と頼まれ、私は「どこにある？」と聞き返していました。集計は自動になったのに、その結果をAIへ渡すところだけ、人が運んでいたのです。

数字はできている。でも、AIからは見えなかった

お客様へ保守の報告を書くとき、サイトがどれだけ安定して動いていたかを伝える数字が要ります。第28話では、サイト別の直近30日間の稼働率と、SSL証明書の残り日数をまとめる週次の仕組みを作りました。

その処理は、月曜朝にメールを出すとともに、結果をJSONという形式のファイルでも保存します。別のプログラムが読み取れるように、項目名と値を組にして残したものです。今回使う材料は、すでにそこにありました。

ただし、保存場所は監視サーバーの中です。チャット側のAI社員が、直接その場所へ入ってファイルを読めるわけではありません。報告文を作るために数字が必要になると、私が接続し、ファイルの中身を画面へ出し、チャットへコピーしていました。

AI社員に「この数字を使って報告をまとめて」と頼む前に、まず数字を渡す作業が必要です。計算する手間は減っていても、最後の受け渡しは残っていました。

前回の第30話では、AI社員が出した作業の行を、人が表へ貼る工程に受け箱を挟みました。今回は向きが反対です。サーバーが持っている数字を、AI社員が読める場所へ渡します。どちらも、仕事の途中に残っていた転記を見直す話です。

新しい仕組みを作る前に、今のメールを探した

この案は、朝のサーバー活用案から出てきました。当社では、AI社員が起動時の報告に続けて、活用案を2〜3案出す決まりにしています。前日は、最初に出てきた3案をすべて見送りました。

その理由は、すでに別の経路で通知が届いていたり、人が作業のついでに確認していたりしたからです。作れることは分かっても、今の仕事がどれだけ減るかが見えませんでした。見送った理由は、次に案を考えるための条件として残しています。

この日、AI社員は稼働率の数字をシートへ移す案を出す前に、月曜の稼働率メールを自分で読めないかを確かめていました。既存のメールが読めるなら、そこから数字を拾えば済みます。新しい保存先を増やす必要はありません。

そのときの返事は、「私からは見つかりませんでした」。この確認で、あらゆるメールの読み方が不可能だと分かったわけではありません。ただ、今回使っている環境では、必要な数字を取り出せる経路が確認できなかった。そこで、スプレッドシートへも書き出す案を深掘りしました。

AI社員に何かを作ってもらう前に、もう使えるものがないかを見ます。前日の「その通知は、もう届いている」という指摘が、今回は作り始める前の確認につながりました。

1つ目：週報はそのまま、シートへ渡す処理を別にする

最初に決めたのは、既存の週次スクリプトへ書き込み処理を足すか、別のスクリプトにするかでした。集計した直後にシートへ書けば、見た目は1本でまとまります。

AI社員が勧めたのは、別にする方でした。いまの週報は、集計してメールを送り、ファイルを保存するところまで動いています。そこへGoogleへの書き込みを組み込むと、その失敗の扱いによっては、既存の処理にも影響が及びます。

今回は、週報が作ったファイルを、あとから別のプログラムが読む形にしました。集計とメール送信のコードには手を入れません。シートへの転記に問題が出ても、既存の週報まで一緒に直す必要がないよう、変更する範囲を分けています。

サーバー自体が止まれば両方に影響しますし、元の週次ファイルができなければ転記する材料もありません。それでも、シートへ書く処理の都合を、週報のコードへ持ち込まずに済みます。今回分けたかったのは、その依存関係でした。

同じ数字を使うために、もう一度稼働率を集計し直すこともしません。既存の週報と、そのとき保存したデータを使います。メールとシートで別々の計算をするより、どの集計結果を見ているかをそろえやすくなります。

2つ目：項目名と空欄の扱いを、実物で確かめる

書き出す項目も、記憶で決めずに確認しました。第27話では、ClarityのAPIから返る項目名と、AI社員が想定した名前が合わず、怒りクリックを485件とする不適切な要約が出ています。

数字が取れたことと、正しい意味で読めたことは別です。今回は、2日前にチャットへ貼った週次ファイルの実物を読み返してから、シートへ渡す処理を作ってもらいました。

並べるのは、取得日、対象期間、サイト、直近30日の稼働率、SSL証明書の残り日数、確認回数の6項目です。報告に使う数字だけでなく、いつの集計で、どの期間を対象にしたかも一緒に残します。

SSLの残り日数が入っていないデータは、空欄のまま扱います。ここへ0を入れてしまうと、「情報がない」と「残り0日」が同じ表示になってしまいます。今回の転記では、元データの空欄を勝手に数字へ置き換えない形にしました。

私は、受け皿になるスプレッドシートを1つ作り、サーバー用のアカウントへ編集者として共有しました。そのURLをAI社員へ渡し、書き込み先を決めます。表を作る準備のあとには、サーバーへプログラムと実行手順を貼り付ける作業もあります。

第30話でも扱ったように、今回のサービスアカウントは、マイドライブ内で新しいファイルを所有する使い方には向きません。そこで、人が作った既存のシートを共有して使います。共有ドライブなど、別の構成なら選択肢は変わります。Googleのサービスアカウントに関する説明

3つ目：書き込まないテストから、本番、再実行へ

設置後、最初に動かしたのはテスト表示でした。読むファイルと、シートへ入れる予定の行を画面へ出し、書き込みはしないモードです。

第24話では、安全確認のつもりで付けた「–help」が、本番処理を止める役割を果たしませんでした。その経験があるので、オプションの名前だけで安心せず、表示だけで終わる手順を先に確かめる運用にしています。

表示には「TEST（no write）」とあり、対象は9月14日の34件です。画面上では、文字の長さやタブの幅によって数字の位置がそろわないことがあります。見た目の位置だけで列を判断せず、6項目として読み取れているかを確かめてから、本番へ進みました。

本番の実行結果は、9時9分15秒に「OK day=2026/09/14 rows=34」。そのまま同じコマンドをもう一度実行すると、9時9分36秒には「SKIP already in sheet day=2026/09/14」と出ました。

今回のスクリプトでは、同じ集計日がシートに入っているかを見て、入っていれば追加を見送る作りにしています。Googleスプレッドシートが、日付を見て自動的に重複を防いでくれるわけではありません。転記する側に設けた判定です。

これで確認できたのは、書き込みに成功したあと、同じデータで再実行した場合の動きです。通信が途中で切れた場合など、どんな失敗でも正しく回復できるところまで試したわけではありません。まず、通常の追加と、直後の重複回避を確かめました。

シートに入ったのは、9月20日ではなく9月14日の数字

シート側でも、値が入ったことを確認しました。実行ログは34件。表には6つの見出しが並び、稼働率、SSLの残り日数、確認回数が、それぞれの列へ入っています。

AI社員からも、シートを読み、列ずれなく入っていることを確認したと返事がありました。これまではサーバーから数字を貼って渡していましたが、今回の表を読む経路が使えたわけです。

ここで気を付けたいのは、作業した日と、数字が表している日が違うことです。サーバーで動かしたのは9月20日。今回取り込んだのは9月14日の集計で、表の対象期間は「08/15〜09/14」でした。

9月20日にシートへ入れたからといって、9月20日までの稼働率になったわけではありません。SSLの残り日数も、元データの集計時点の値です。AI社員が表を読めるようになったあとも、報告へ使うときは取得日と対象期間を一緒に見ます。

第28話で扱った「直近30日」と「その月全体」の違いも、そのまま残ります。週ごとの値を単純に平均して月間の稼働率にしたり、古い集計を今日の状態として書いたりしない。受け渡しを自動化しても、数字の意味まで変わるわけではありません。

月曜の集計を、毎日9時20分に見に行く

元になる週次ファイルは、月曜朝の処理で作られます。最初の案は、シートへ書く処理も月曜だけ動かす形でした。途中でAI社員から、毎日9時20分に実行する提案が出ました。

同じ集計日は追加しないので、火曜以降も、すでに転記済みならスキップします。一方、月曜にGoogle側へ接続できず書き込めなかった場合は、翌日の実行がもう一度試す機会になります。

週次のデータを毎日見に行くのは、毎日新しい稼働率を計算するためではありません。転記できなかったときの、次の機会を用意するためです。集計する頻度と、転記を試す頻度を分けました。

翌日になれば必ず埋まる、という保証ではありません。共有設定の間違いや、元ファイルができていない状態は、日が変わるだけでは直りません。それでも、一時的な問題が解消していれば、手で再実行する前に、次の定刻で進められる設計です。

今回の追加処理では、新しい通知メールは増やしませんでした。既存の週報が届くところへ、さらに転記完了の通知を重ねないためです。その分、報告に使う前には、シートに必要な集計日が入っているかを見る。メールが増えないことと、確認が要らなくなることは分けておきます。

定期実行は18行から19行へ。総作業時間は未計測

定期実行の登録前には、いまの実行行を数えました。第27話では、コメントや空行を含めた37行と、実行する処理の14行を混同しています。今回は、同じ数え方で登録の前後を比べました。

結果は、18行から19行へ。今回増えたのは1行です。ただし、19行すべての動作を確認したという数字ではありません。今回の転記についても、手動で動いたことと、次の定刻に動くことは別の確認になります。

9時8分という時刻は、画面にあるファイルの更新時刻です。相談やシート作成を含む作業全体の開始時刻ではありません。今回は全体の所要時間を測っていないので、「何分で全部できた」という数字は付けませんでした。

最後に止まったのは、サーバーではなく返事の書き方だった

技術的な確認が通ったあと、別のところで話が止まりました。AI社員の完了報告は、冒頭が「いま確認してほしいことはありません」でした。ところが、その末尾には私への質問が2つあり、返事を待つ形になっていました。

私が「とまってる？」と聞いて、そこで食い違いが分かりました。確認することはないと伝えながら、確認が返るまで進まない。処理の結果よりも、次に誰が動くのかが、報告の中でそろっていなかったのです。

前日に、「確認してほしいことは冒頭に、全部並べる」と決めたばかりでした。今回も、そのルールをAI社員自身が外しています。決まりを記録したことと、次の返事で実行できたことは別でした。

表への書き込みに成功しても、仕事全体が自動で前へ進むとは限りません。完了した作業と、返事が必要な質問を分け、次に必要な行動を最初に伝える。サーバーの処理と同じように、人とAIの受け渡しにも、詰まる場所がありました。

数字を運ぶところまで、仕組みの一部にする

今回、稼働率を計算する方法は変えていません。すでにあった週次の数字を、AI社員が読めるスプレッドシートへ渡しました。初回の34件と、再実行時のスキップを確かめ、毎日転記を試す設定まで進めています。

次は、次回の定刻に新しい集計が入るか、AI社員がその取得日と対象期間を確認して使えるかを見ます。表を開けることが、古い数字を使わないことまで保証してくれるわけではありません。

「貼ってください」「添付してください」が繰り返し出る場所には、人が運んでいる情報があります。今回は、その一つに経路を作れました。数字を取りに行く手間を減らし、数字をどう報告へ使うかの確認に時間を回していきます。

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

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

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