結論から
AIに実務を任せ始めると、最初は「何をやらせるか」に目が向く。メールを分類する、日報を書く、記事のたたき台を作る、集計表を更新する。だが任せる仕事が増えてから本当に困るのは別のところだ。そのAIが止まった時、誰が気づくのか。間違った報告をした時、誰が疑うのか。
うちでは、実務をするAIの上に、動きを監視し、証拠を確認し、必要なら修理するAIの層を置いている。2026年8月7日の朝、その統治層自身に4件のバグが見つかった。最初の修正完了は午前6時17分23秒、最後は午前7時23分34秒。66分11秒の間に、4件の原因を切り分け、修正し、再発防止のテストまで通した。オーナーが一件ずつ追加指示したわけではない。
1件目:安全に止まったのに「故障」と数えていた
最初のバグは、AIが安全装置によって正しく処理を拒否したのに、監視側がそれを失敗として数えていたことだ。
たとえば、経費登録のAIが「領収書が足りないので登録しません」と止まったとする。これは正しい停止だ。ところが監視AIが「登録できなかった=故障」と判断すると、直さなくてよいものまで修理対象になってしまう。
正常な拒否4件を集計から外し、本当に対応が必要な8件は残ることを再確認した。
2件目:15分で止まると、診断まで消えていた
次は、AIの作業が15分でタイムアウトした時、後続の診断まで止まるバグだ。
作業が終わらなかったこと以上に、「どこまで進んだか」「何が原因か」が残らないことが問題だった。次のAIは、また最初から調べるしかない。
修正後は、作業中の生存記録を残し、タイムアウトしても診断結果を必ず出すようにした。模擬タイムアウトでは終了コード124を返しながら、古い記録であることと判定結果も残ることを確認している。
3件目:「理由を書いた」だけで監査を通れた
3件目は、仕事の待ち行列が0件になった理由を、何か一文書けば合格できていた問題だ。
「対象なし」と書いてあっても、本当に対象がないかは見ていなかった。AIはもっともらしい文章を作るのが得意だ。だから、文章があることを証拠にしてはいけない。
修正後は、理由が指している記録が実在し、内容も一致していることまで確認する。架空の理由は不合格、実在する証拠と一致する理由だけ合格。13件のテストで境界を固定した。
4件目:今作った記録を「古い」と勘違いした
最後は、同じ処理の途中で作った新しい記録を、過去の記録と取り違えて「更新されていない」と判定するバグだ。
比較対象を処理開始前の記録だけに限定して修正した。最後は実際の処理を動かし、新しい記録が「FRESH」と判定され、全ゲートを通るところまで確認している。
AIを働かせるなら、AIを疑う仕組みも要る
4件に共通していたのは、AIモデルの賢さではない。合格条件の設計だった。
- 正しい停止と故障を分ける
- 失敗しても診断を残す
- 説明文ではなく実在する証拠を見る
- 比較する時刻の境界を決める
自動化を増やすと、成功だけでなく誤判定も速く広がる。人が毎朝すべてを見張るのではなく、AIが一次点検し、直せる範囲を直し、人にしか決められないことだけを上げる。この分担ができて、やっと「AI秘書」になるのだと思う。
小さな会社が業務を自動化する場合も同じだ。問い合わせ整理や記事作成を自動化する前に、「何をもって完了か」「止まった時に何を残すか」「最後に人が見る場所はどこか」を決めておく。それだけで、翌朝に原因不明のエラーを追う時間が減る。
AI秘書の仕組みに興味がある方へ
うちでは、こうした「気づく・疑う・直す」の仕組みも含めて、AI秘書「ラポ秘書」として日々の運用に組み込んでいる。毎週繰り返している1業務を無料で棚卸しし、自動化できる部分だけでなく、止める条件・証拠の残し方・人が確認する地点まで一緒に整理する。「止まっていることに気づけない」不安に心当たりがあれば、ラポ秘書に無料で相談する。
※時刻・件数・テスト結果は、2026年8月7日の社内運用記録に基づく。顧客名・案件名・現場情報は掲載していない。