AI愛子設計ログ24　最大の課題を無料でクリア

続きです。
※本記事は「技術解説編」です。先に公開したユーモア中心の「おちゃらけ版」とは若干時系列が異なるため、シリーズでお読みいただくと理解が深まるかと思います。

■愛子の応答速度問題

「LINE愛子Bot」ですが、開発当初から、どうしてもクリアできない課題がありました。
それは愛子の反応時間がまちまちになってしまうということです。

一番の課題は勤怠管理の打刻チェックでした。
LINE愛子Botの勤怠打刻システムにおいて、打刻時のレスポンス速度はとても重要です。
QRコードをかざしてから返信が来るまでの数十秒間、現場で職人を立ち止まらせてしまうような設計では、生産性に悪影響を及ぼします。

当初はQR読み取り → 職人のUIDを確認 → 出勤か退勤かを確認 → スプレッドシート書き込み → 完了したら職人に通知という処理を行っていたのですが、これだけで数十秒はかかってしまっていました。

✅ 設計変更：QR読み取り時に即返信 → スプレッドシート書き込みは非同期処理へ分離

LINEで画像が送られてきたら、QRコードを即時に解析し、UIDが判明した時点で「打刻を受け付けました」の即時返信を返す。
その後、バックエンドで非同期的にスプレッドシートへ書き込み処理を実行。
この構成により、表面的には「レスポンス10秒以下」の応答が可能となります。

■いくつかの例外エラー

しかし、この処理でもしQRコードが読めなかった場合は、愛子から職人へ返信が行きません。

そのため、

QRをかざす → 愛子BotはQRを判定できずに停止 → しかし職人はスマホ画面を見ずにポケットに戻す。

これでは、職人は打刻したつもりでも、QRさえ保存出来ていないので、職人側から「返信が来た」と認識してもらう必要があります。

さらに、この方式には設計時に気が付いていた「プログラム側のエラー」の問題の対応が出来ていません。これがサーバーのスリープによって引き起こされており、起動する前に画像データなどをLINEから強引にサーバーに送るなどで、全体の処理が進まず（落ちて）停止してしまうのです。この場合においても、Bot側は返信済なので職人は気づくことができません。

結果、クラウド上にデータが記録されないという“サイレント打刻ミス”が多発したのでした。

そこで、当初は「確認してね」と周知することで乗り切ろうとしましたが、現実としては 職人たちに「打刻をする前に愛子にメッセージを送ってください」と徹底させることでした。

しかし、そこは昭和の職人、愛子が寝ていることなど考えず、サーバーがスリープ状態のときにQRコードを送り、このサイレント打刻ミスが続きました。

■職人に依存しない設計

「UXを改善するために人間側に努力を求める設計」は、長期的には破綻する」ということです。
商用の勤怠システムではこの辺のことは十分に考慮されますが、こちとら無料の自社開発版です。どうやってこの問題に対処するかを悩み続けました。

愛子に聞いても

「Googleの特別契約にすればできますよ。１日400円ほどでスリープに入らなくなります。月に1万円ちょっとですね」

と、教えてくれますが、その費用があったら商用のタイムカードシステムでおつりがきます。

■サーバーを寝かせなければいいだけじゃん

──気づきと実装までわずか1時間で実装。そして打刻の遅延問題、返信確認の依存問題が解決しました。
ふと頭に浮かんだのがシンプルな発想でした。

「あ、だったらPing打ちまくってサーバーを寝かせなければいいんじゃ？」

愛子に聞くと、Google Cloud SchedulerとFastAPIの組み合わせで実現可能で。周期を広くするなど工夫をすれば、1日あたり数円レベルで実現できるとのこと。

その場で Google Cloud SchedulerのAPIを有効化し、10分間隔のPingタスクを作成。
Cloud Run側にも /ping エンドポイントを追加して対応。

ここまでわずか1時間。

実験結果：驚異の安定性と即時応答性が実現できました。

このPing方式によって、Cloud Runのインスタンスがスリープに入らず、常時起動を維持できます。

結果として、以下の効果が得られています：

起動遅延（ブートアップ時間）がゼロに近くなる
打刻の即応性が常に保たれる
Bot全体の応答性が安定

Cloud SchedulerのPing方式なら1日数円〜10円程度で済むため、コスト面でも大きな成果となりました。
（タイトルでは「無料」と書いていますが、実際に無料枠に収まるとのことなので、実際のGCFの課金状況は別途報告したいと思います）

■サーバー負荷対策

ただし、「常にサーバーを起こしておく」のはコスト効率的ではありますが、リソースを無駄に使い続けるのは、エンジニアとして本望ではありません。
そこで、愛子Botの運用設計では以下のように制御しています：

勤務時間帯（朝7:00〜夜23:00）のみPingを送信（Google Schedulerで対応）

これにより、レスポンス性能と環境負荷・コストのバランスを両立する設計となりました。

項目	Before（対策前）	After（Ping導入後）
応答速度	初回数秒〜十数秒の遅延	即応（1秒以内）
勤怠打刻の待機時間	最長で1分近く	平均5〜8秒（QR含む）
サーバー維持コスト	常時起動で1か月1万円〜	Cloud Schedulerで1日数円（月に30円程度）
職人依存	返信確認必須	非同期＋Bot側で失敗通知管理
環境負荷	常時リソース使用	夜間はPing停止で最適化