COLUMN 技術コラム

止めたはずの自動処理が動き続け、直したはずの表記が翌朝蘇る——AIラボの実測で分かった「幽霊ルーチン」の正体と、purpose台帳・クローズ3層プロトコルによる対策を実例で解説します。

先週、私たちのAIラボは1日で6つの幽霊を退治した。

クローズしたはずの実験の計測器が、2日間動き続けていた。停止したはずの配信の再投稿ロボットが、SNSへの書き込み権限を持ったまま毎日3回起動し続けていた。実行済みの単発ジョブが、毎年7月20日に再発火する時限装置として仕掛かったまま残っていた。プレビュー用に立てた即席のWebサーバーが、役目を終えたあとも29時間動き続けていた。

どれも、悪意のあるものではない。すべて自分たちが良かれと思って作ったものだ。そして全部が「動いていて当然」という顔をして、誰にも気づかれずに動き続けていた。

私たちはこれを幽霊ルーチンと呼ぶことにした。この記事は、AIで業務を自動化するプロジェクトが必ず直面する「止め方」の問題と、その対策としてラボで実装した方法の記録である。

なぜAI駆動のプロジェクトで幽霊が生まれるのか

AIに仕事を任せ始めると、気づかないうちに「動き続けるもの」が増殖する。定期実行のジョブ。文章や動画を生み出す生成テンプレート。成果を測る計測器。私たちのラボでは、立ち上げからわずか3日で20本を超えるルーチンが動いていた。

問題は、「作る手順」は皆が設計するのに、「止める手順」は誰も設計しないことだ。

新しい自動化を作るとき、人は起動条件を考え、動作を確認し、うまく動けば満足する。しかし数週間後、その仕事のやり方を変えたとき——実験をやめたとき、方針を転換したとき、ブランド名を変えたとき——「やめた」という決定が資産側に伝わる経路は、デフォルトでは存在しない。

決定は議事録に書かれる。だが議事録はルーチンを止めない。人間の組織なら、担当者が空気を読んで手を止める。AIのルーチンは空気を読まない。指示された通り、永遠に動き続ける。

もっと怖い話——直しても蘇る

幽霊ルーチンよりさらに厄介な現象がある。是正したはずのものが、翌朝蘇るのだ。

実例を挙げる。私たちはあるとき、公開済み動画47本の説明欄に残っていた旧ブランド表記を一括修正した。表記の残存ゼロを確認して作業を終えた。ところが翌朝の新規動画で、同じ旧表記が再発した。

原因は、動画の説明欄を毎朝生成しているテンプレート——スケジュールタスクに書かれたプロンプト——が古いままだったことだ。私たちは「出力」を47本直したが、「生成源」を直していなかった。生成源が古いままなら、汚染は毎朝再生産される。

もうひとつ。ある実験をクローズし、関連ドキュメントから記述を消した。ところが週次の自動生成器が、ハードコードされた分岐によってその実験を翌週復活させた。文書を消しても、文書を書き直すプログラムが古い世界観を持っていれば、決定は上書きされてしまう。

ここから得た教訓を、私たちはクローズ・プロトコルとして定式化した。何かをやめるときは、3つの層をすべて始末するまで完了ではない。

1. ドキュメント——人間が読む記録
2. 機械可読の状態——ステータスフラグや台帳の値
3. 生成源——その記述を再生成するテンプレート・プログラム・定期ジョブ

3層目を見落とすと、1層目と2層目は自動的に巻き戻される。「消したのに蘇る」の正体は、ほぼ例外なくこれだ。

ラボの答え——purpose台帳と「逆向きの監視」

対策としてラボに実装した仕組みは4つある。どれも特別な製品ではなく、設計の習慣に近い。

1. purpose台帳。 すべての定期実行に「存在理由」を人間が書く。このジョブはどの実験のためか、どの事業のためか。たった1行だが、これがないと「止めてよいか」を誰も判断できない。逆にこれがあると、実験をクローズした瞬間に「この目的を持つルーチンはもう不要」と機械的に導ける。

2. 目的-生死照合。 週に一度、台帳と実態を突き合わせ、「クローズ済みの目的を持つルーチンが、まだ動いていないか」を機械照合する。従来の監視は「動くべきものが止まっていないか」を見る。これはその逆向き——「止まるべきものが動いていないか」を見る。この照合を初めて実行した日、20本のルーチンの中から本物の幽霊が2件検出された。冒頭の「毎年7月20日の時限装置」は、この仕組みが見つけたものだ。

3. 停止の定石。 ルーチンを止める前に、2つの問いを確認する。「このルーチンの出力を、誰が読んでいるか」「この記述を、誰が再生成するか」。私たちは一度、不要になった計測器を丸ごと止めようとして、その計測器が朝のレポートに数字を供給していたことに直前で気づいた。止めていたら、翌朝から別の場所の数字が静かに古び続けていたはずだ。多役のルーチンは、役割単位で止める。

4. 月次の定点観測。 是正は一回では守れない。私たちの実測では、是正した面が1週間のうちに2回、別の経路で蘇った。だから外向きの表示・定期実行・生成源を、月に一度まとめて再走査する。ポイントは「異常を全部通知する」のではなく、既知の正常との差分だけを通知すること。毎月鳴る警報は、3ヶ月後には誰も見なくなる。

数字で言うと

すべてラボの実測値である。

• 1日の総点検で見つかった幽霊ルーチン: 4件（週次照合の導入後、さらに2件を機械検出）
• grepでも数値同期でも検知できなかった盲点: 3種（生成テンプレート内の残存、画像に焼き込まれた古い実績数字、検索エンジン向けに遮断しただけで実際には公開されていたバックアップ）
• 週次照合の誤報: ゼロ（意図的に停止中のもの・管理対象外のものを台帳で区別した結果）

とりわけ「画像に焼き込まれた数字」は示唆的だった。テキストの数字は自動同期で守れるが、画像の中の数字はどの検知網にも乗らない。原則はこうなる——賞味期限のある事実を、期限切れを検知できない場所に置かない。

止まる設計とセットでしか、動き続けるものは安全にならない

「AIに仕事を任せる」とは、起動を自動化することではなく、ライフサイクル全体を引き受けることだと私たちは考えるようになった。始める設計よりも、終わらせる設計のほうが難しい。作る手順書の隣に、止める手順書を置く。動かす監視の隣に、止まるべきものの監視を置く。

前回のコラム（事実台帳法）は、AIの「記憶の鮮度」の話だった。今回は、AI駆動プロジェクトの「代謝」の話である。新陳代謝が止まった組織が硬直していくように、やめたはずのものを終わらせられないプロジェクトは、静かに信頼を失っていく。

動き続けるものは、止まる設計とセットでしか安全にならない。

株式会社エヌネットワークスは、25年のインフラ運用実績をもとに、AIエージェントの導入から「止め方」までを含めた運用設計・AgentOps運用代行を提供しています。自社のAIラボで実際に運用・実測した方法だけをお客様に提供します。