深夜23時半の報告が、ある夜、届かなかった
うちでは、その日にAI秘書がやった作業をまとめた報告を、毎晩23時半に自動で届けるようにしています。届いた報告を見て、翌朝すぐに続きの判断ができるようにするためです。
ところがある夜、いつもの時間になっても報告が来ませんでした。まず考えられる原因は、メインで使っている生成AIの利用上限(いわゆるクォータ)が切れたことです。使いすぎて枠が尽きれば、報告文を作る処理自体が動かなくなるのは自然な話に思えました。実際、その日はメインのAIの利用量がかなり多く、疑うだけの根拠はありました。
ただし、うちの仕組みには「メインが枯渇したら別の生成AIに切り替える」という予備の経路(フォールバック)も用意してあります。もし本当にクォータ切れだけが原因なら、この予備の経路が働いて、多少形は違っても報告自体は届くはずでした。実際、予備に切り替えたという短い知らせは届いていました。それでも報告の本文が届かないのは、もう一段別の理由があるということです。
ログを遡ったら、報告文自体はできていた
ログを1つずつ遡って追いかけると、意外な事実が見つかりました。予備の生成AIは、確かにその夜、報告の文章をきちんと作り終えていたのです。切り替えから4分ほどで、報告のファイルは最後まで書き上がっていました。
つまり止まっていたのは「文章を作る」工程ではなく、その後の「作った文章をチャットへ届ける」工程でした。普段はメインの生成AIが、文章を作った流れのままチャットへ投稿する役目まで一緒に担っています。予備の経路では、出来上がった文章を投稿するのは常駐の司令役のAIの役目と決めていました。ところが、予備の作業が終わったことを司令役に知らせる仕組みがなく、出来上がった本文は誰にも拾われないままでした。いつもの時間から15分ほどたって司令役が気づき、代わりの報告を投稿しています。
原因を「枯渇」だと決めつけていたら、次にやることは利用枠を増やす、あるいは切り替えのタイミングを早める、といった的外れな対応になっていたはずです。実際の原因は容量の問題ではなく、引き継ぎの抜けでした。作る担当はいたのに、届ける担当に出番が伝わっていなかった、というだけの話です。
これを踏まえて、予備の生成AIが報告文を作り終えた時点で、その完了を検知してチャットへ直接投稿する経路を1本追加しました。メインの生成AIが担っていた「投稿する」という工程を、予備の経路にも独立して持たせた形です。これで、予備の生成AIが報告文を作った夜も、司令役の手を待たずにチャットへ送られる経路ができました。
「その後」: 最初の夜は完璧ではなかった
2026年10月26日時点の経過も、正直に書いておきます。直した最初の夜は、15通に分けて送る途中の10通目で送信回数の制限に当たって止まり、残りは司令役が代わりに送りました。翌日、制限に当たったら待って送り直す仕組みと、送る通数を8通以下にまとめる修正を入れました。ただ、その夜は予備の生成AI自身も利用上限に達していて報告文が作られず、司令役が代わりに投稿しています。9月27日から29日の3晩は、最後まで自動で届きました。最後に予備の経路が動いた10月2日の夜は、8通のうち7通まで届いたところで通信が途切れ、最後の1通を送れませんでした。10月3日以降はメインの生成AIが毎晩動いていて、予備の経路はまだ使われていません。
「作る係」と「届ける係」は別々に確かめる
この一件で残った教訓は、複数の生成AIを使い分ける仕組みほど、「文章を作る係」と「それを届ける係」を別々に数えて確認する必要がある、ということです。片方だけ動いていても、もう片方が抜けていれば、外から見た結果は「報告が来ない」という同じ形に見えてしまいます。
利用上限のような分かりやすい原因は疑いやすい一方で、「途中までは正常に動いていた」という可能性は見落とされがちです。実際にログを最後まで遡って、どこまでは動いていて、どこから止まっているのかを確認したことで、ようやく本当の原因にたどり着けました。
複数のAIを組み合わせて日々の業務を任せる場合、1つのAIが動かなくなったときの代役だけでなく、その代役が「最後まで」同じ役割を果たせるように経路を組んでおくことが、地味ですが効いてくる部分だと感じています。
AI秘書の「動いているはずなのに届かない」、原因まで追えていますか
ラポ秘書サービスでは、複数の生成AIを使い分ける運用の中で起きる、こうした見えにくい抜け漏れをログから切り分け、報告や通知が最後まで届く経路まで含めて見直しています。「原因が利用上限なのか、それとも別の抜けなのか分からない」という方は、まずはお気軽にご相談ください。