こんにちは、オフィスピコッツの小笹です。
土曜の朝、監視サーバーに顧客台帳を読ませました。出てきたのは、「未着手」「進行中」の81行。6月や7月の日付が、そのまま残っています。
AIが新しい仕事を考えたわけではありません。すでに台帳にある仕事を、作業日順に並べただけです。でも、月末に人が抜き出していた一覧をサーバーが作れるようになったことは、思った以上に大きな変化でした。
この日の作業は、手元の記録では10時31分に接続し、11時00分に再起動をかけるまでの約30分。稼働率の週報、補助金の絞り込み、月次報告用データの保存、顧客台帳の読み取りという4つを整えました。既存の契約・サーバーを使い、今回の整備で新たな有料サービスの追加はしていません。
ただし、「4つの整備」と「定期実行を4本追加」は別です。今回は新規追加だけでなく、既存処理の改修と、将来の報告書に向けた土台づくりも含まれています。
きっかけは、毎回かかる3分だった
前日の金曜、お客様2社の定期チェックを終えて報告メールを書いていたとき、稼働率の数字が必要になりました。
監視に使っているUptime Kumaは、監視サーバーの内部で動かしています。管理画面を見るには、SSHで接続経路を作り、ブラウザで開く必要があります。慣れれば3分ほどですが、数字を確認するたびに同じ操作をします。
AI社員に「これ、毎回やらなくて済む形にできないか」と聞くと、月曜朝の自動メールに、全サイトの直近30日間の稼働率を載せる案が返ってきました。報告用の数字を、先に一覧で受け取れるようにするわけです。
ただし、月曜時点の「直近30日」と、金曜時点の「直近30日」は同じではありません。報告に使うときは、集計期間も一緒に確認する。暦月の稼働率や、報告当日までの値が必要なら、別途集計する。この区別は残しておきます。
ほかにも、台帳には「補助金週報の絞り込み」「無事故証明書の土台」「月末の棚卸し用の抽出」が、後日の作業として並んでいました。同じサーバーで進める作業なので、この朝にまとめて着手することにしました。
1つ目：稼働率を、管理画面ではなく週報で受け取る
既存の月次スクリプトをAI社員に見せ、別ファイルで週次版を作ってもらいました。サイト別の直近30日間の稼働率に、SSL証明書の残り日数を添えた一覧です。
試しに動かすと、33サイトが並びました。「稼働率99.5％未満、またはSSL残り14日未満」という条件で、要注意欄には6件。内訳は、稼働率が基準を下回る3サイトと、SSL証明書の残り日数が8〜9日の3サイトでした。
稼働率の低下は、以前から把握していた断続的な停止と照らし合わせます。SSLも、残り日数だけで「異常だ」「正常だ」とは決めません。自動更新の予定があっても、実際に更新されるかは別途確認が必要です。
この一覧が役立つのは、数字を並べるからではなく、台帳にある記録と照らして、見るべきところを絞れるからです。
週報は毎週月曜9時15分に送る設定にしました。この日の確認は試し出力まで。定刻に処理が動き、メールが届くところは、別の確認として残ります。
2つ目：補助金の週報は、0件でもよかった
補助金の締切を知らせる仕組みは、すでに動かしています。ただ、前日の週報は全国向けの大型事業が目立ち、京都・滋賀の小さな会社に関係するものを探しにくい状態でした。
AI社員が既存コードを読んで出した改修案は、週報とX投稿用の下書きに地域・規模の絞り込みを効かせること。「全国」の枠は、補助上限500万円以下、または従業員要件に小規模を示す語があるものを候補に残し、それ以外は件数だけ表示する。記事の下書き用には、従来どおり取得した全件を使う設計です。
最初の試し出力では、「京都・滋賀 1件」と出ました。ところが、中身を見ると全国枠。対象地域に全都道府県が列挙され、その中に「京都府」「滋賀県」が含まれていたため、地域向けとして拾っていました。
そこで、地域一覧の区切りが10以上ある場合は全国扱いにする、簡易的な判定を加えました。これは今回の取りこぼし・拾いすぎを調整するためのルールで、制度の対象地域を完全に理解したわけではありません。
出力は、「今週は京都・滋賀および全国・小規模向けで締切接近（14日以内）の補助金はありません。（全国その他22件）」になりました。
ここで言う0件は、今回の取得範囲と条件に合う候補がなかった、という意味です。京都・滋賀で使える補助金が世の中に一つもない、という意味ではありません。実際に紹介・申請する場合は、公募要領で対象者や条件を確認します。
たくさん届けば便利、とは限りません。見る必要のあるものを絞った結果、0件なら0件と返す。それも週報の仕事です。
3つ目：月次報告のために、数字を残す
稼働率の週次スクリプトには、集計結果をJSON形式でも保存する機能を持たせました。あとで別の処理が読み取れる形で、数字を残すためです。
台帳で「無事故証明書」と呼んでいた構想の土台ですが、監視データだけで「この期間、サイトは一度も止まっていません」と言い切るのは避けたいところです。報告できるのは、監視できた範囲と条件に基づく結果です。
書類の見た目や記載項目は10月に考える予定で、この日に完成したわけではありません。今回は、月次の稼働状況報告へつなげるためのデータ保存を整えました。
なお、週ごとの直近30日データは期間が重なります。単純に平均して「その月の稼働率」にするのではなく、報告対象の期間をそろえることも、今後の設計に含めます。
4つ目：サーバーが、顧客台帳を読む
当社の顧客管理には、Googleスプレッドシートを使っています。月末には「未着手」「進行中」の行を抜き出し、残っている仕事を棚卸しします。この一覧を作る部分を、サーバーへ渡すことにしました。
Google CloudでGoogle Sheets APIを有効にし、サーバーの処理に使うサービスアカウントへ台帳を共有します。サービスアカウントは、人がブラウザで使うアカウントとは別の、プログラム用のアカウントです。
共有画面には、共有先が台帳の所有組織に属していないという注意が出ました。今回は処理に使うサービスアカウントへの共有ですが、「自社の処理用だから大丈夫」とだけ考えず、共有先と与える権限を確認する必要があります。今回の用途は台帳の読み取りであり、書き換えではありません。
サーバー側に抽出用スクリプトを置いて試すと、「未着手・進行中：81行（作業日順）」と出ました。
6月や7月の「進行中」が、まだ残っている。これが、棚卸しで見たい材料そのものでした。
ただ、古い日付があるからといって、すべてが放置案件とは限りません。先方の返答待ちかもしれないし、実際には終わっていて台帳の更新が追いついていないのかもしれない。そこを判断するのは人です。
一覧を抜き出す作業をサーバーへ渡し、人は一件ずつ仕分ける。この分担ができれば、棚卸しの始め方が変わります。
月末日の朝8時にメールで受け取るための定期実行も登録しました。ただし、登録できたことと、月末に正常に動くことは別です。記事化の際に登録画面を見直すと、月末を判定する日付コマンドに、cron用の記号処理を確認すべき箇所が見つかりました。現時点では、81行の試し抽出には成功、月末の自動配信は設定の再確認と動作確認が必要、という段階です。
再起動のあと、AIが見ようとしたのは別のサーバーだった
最後に、監視サーバーを再起動しました。するとAI社員は、「1〜2分後にpikoz.netが開けば確認完了」と案内しました。
でも、pikoz.netは別のサーバーで動いています。今回再起動したのは監視用で、そこに公開サイトはありません。別のサーバーのサイトが開いても、こちらの復旧確認にはならないのです。
私が指摘し、確認対象を、監視サーバー側のコンテナが起動しているかどうかへ修正しました。
「サーバーを再起動したら、サイトが開くか見る」。よくある手順ですが、今回の構成には合いません。当社の構成を台帳に書いていても、こうした取り違えは出ます。一般的な手順と、目の前の環境を照らし合わせる人が、まだ必要です。
手順書の出し方も変えました。前日に完成させておくのではなく、当日の現状を確認してから作る。前日に準備することまでやめるわけではありませんが、実行用の手順は現物を見てから確定することにしました。
4つ整えて、定期実行は2行増えた
今回の内容を分けると、こうなります。
| 整備したもの | この日の位置づけ |
|---|---|
| 稼働率の週報 | 週次版を新設し、試し出力を確認 |
| 補助金週報の絞り込み | 既存処理を改修し、出力を確認 |
| 月次報告用のデータ保存 | 週次処理に保存機能を追加 |
| 顧客台帳の読み取り | 抽出処理を新設し、81行の出力を確認 |
定期実行の追加は週次の稼働率レポートと月次の台帳抽出の2本で、登録行数の確認結果は15行から17行になりました。作業時間は接続から再起動まで約30分。新たな有料サービスの追加はなし。既存のサーバー代や契約中のサービスまで無料になった、という話ではありません。
また、17行という数字は、17行すべてが正常に動いた証拠ではありません。試し出力、定期実行、メールの到着は、それぞれ確かめる必要があります。
抜き出す作業を減らし、判断するところを残す
今回、AIに判断を全部任せたわけではありません。稼働率を見て確認が必要か判断する。補助金の候補が自社のお客様に合うか考える。台帳の81行を見て、進めるもの、待つもの、完了にするものを分ける。そこは、人の仕事として残っています。
変えたのは、その前に毎回していた作業です。管理画面を開いて数字を探す。大量の情報から候補を拾う。台帳の行を抜き出して並べる。そうした下準備を、少しずつサーバーへ渡しました。
約30分で進んだことはありました。でも、速く登録できたから完成、ではありません。AIが確認先を間違えたところも、定期実行の再確認が必要なところも含めて、今回の実践です。
サーバーが台帳を読めるようになった。その次は、出てきた一覧を使って、人が仕事を整理する番です。
AI社員実践記は、まだ続きます。
技術の話はここまで。考え方の話は「社外Web担当の頭の中」へ。
京都産業21 登録専門家（No.46）／滋賀県DX協創パートナー／デジタル庁 デジタル推進委員。2002年開業、創業25年目。京都・滋賀を中心に1万件超のWeb活用・制作に携わる。 会社概要を見る