AIエージェントの「設定済み」を検証する3点照合

AIエージェントの「設定済み」を信じてよいか迷う運用者へ、宣言・コード・実動作の3点で検証する手順を示します。結論から言うと、今回の5分待機は調査時点で実装されていませんでした。

観測対象は、自宅ラボで動く為替急変動の分析ノードです。「検知後に5分待つ」という過去の報告に対し、現行コード、バックアップ全世代、実際の受信時刻と完了時刻を照合しました。

待機ロジックは0件で、3回の処理時間は58秒、68秒、64秒でした。「トリガー不明」も機構の故障ではなく、AIレポートの【判定】不明でした。

自己申告と実装を照合する環境

対象は某所ラボ内で運用している為替分析ノードです。公開記事では、ホスト名、IP、Webhook、内部の起動方式、具体的なエージェント製品構成は扱いません。

このラボの全体像は、別記事の我が家の物理構成マップで整理しています。無人運用の土台については無人で回す土台も近い文脈です。今回の話は機材紹介ではなく、その上で動くAIエージェントの報告をどう検証するか、という運用記録です。

• 現行コード
• バックアップ全世代
• シェル履歴
• 環境変数
• 実際に受信した検知と分析完了時刻
• AIレポートの出力内容

調査の狙いは単純です。「5分待機を設定した」という報告が、実装として残っているかどうかを見ることです。

症状1: 5分待つはずが、58〜68秒で終わる

検知3件について、受信から分析完了までの時間は次のとおりでした。

• 58秒
• 68秒
• 64秒

5分待機が入っていれば、少なくとも300秒付近の遅延が観測されるはずです。ところが実測は1分前後でした。

ここで重要なのは、「2分で通知」という体感表現を、そのまま仕様違反として扱わないことです。運用者の記憶は便利ですが、ログほど厳密ではありません。今回の実測では、通知までの時間は2分ではなく58〜68秒でした。

つまり、この症状は「5分待機が2分に短縮されている」ではありません。「待機らしい待機がなく、AIの処理時間だけで返ってきている」と見るほうが自然です。

症状2: 「トリガー不明」は、トリガー機構の故障ではなかった

もうひとつの症状は、毎回「トリガー不明」と出ることでした。

名前だけ見ると、イベントの発火元を識別するトリガー機構があり、それが壊れているように見えます。ですが、全文検索では「トリガー」という文字列自体が見つかりませんでした。

実際に存在していたのは、AIレポート内の見出しに近い表現です。

【判定】不明

これはトリガー種別ではなく、AIが原因を特定できず「不明」と判定していた、という出力でした。当日の判定は3件連続で「不明」です。

つまり「トリガー不明」という症状は、実装上のトリガー欄が壊れていたのではありません。レポートの見出しを、人間側がトリガー情報のように読んでいた可能性が高い、ということです。

全文検索の結果: 待機コードは0件

現行コード、バックアップ全世代、シェル履歴、環境変数を横断して全文検索しました。

結果は、待機ロジック0件です。バックアップ全世代を含めても0件でした。

「300」という数字は1件だけ関係しそうに見えましたが、内容は旧プロンプトの「300文字で要約」でした。300秒待機ではありません。

• 5分待機のコードは存在しない
• 「トリガー」という文字列も存在しない
• 実測の処理時間は58〜68秒
• レポート上の判定は3件連続で「不明」

壊れていた機能を探していたつもりでしたが、壊れる対象がありませんでした。

真犯人は「過去の報告」だった

今回の不具合らしきものは、2つとも実在しませんでした。

「5分待つはずが短い」は、5分待機コードが存在しなかったためです。「トリガー不明」は、トリガー処理ではなくAIレポートの判定見出しでした。

実在したのは、「5分待機を設定した」と報告された記録、またはそのように記憶された運用上の前提だけです。

AIエージェントが意図的に嘘をついた、という話ではありません。ここを雑に断じると、対策も雑になります。問題はもっと実務的です。

報告と実装は乖離します。嘘をつく気がなくても、乖離します。そして誰も検証しなければ、AIエージェントの「やりました」は幻覚のまま運用前提に混ざります。

後日談: 幻覚を実装して、初めて仕様になった

この調査のあと、本当に5分待機とモデル固定を実装しました。そこで初めて、仕様どおりに動く状態になりました。

少し奇妙ですが、過去の自己申告は、調査時点では幻覚でした。後から実装したことで、ようやく実体を持ったことになります。

これは笑い話に見えますが、無人運用ではかなり危険な型です。自動起動、遠隔復旧、死活監視、バックアップが整っていても、アプリケーション内部の前提が間違っていれば、静かに間違ったまま回ります。

死活監視についてはUptime Kumaの死活監視はDownと通知失敗を作って見るで、失敗を意図的に作って見る考え方を書いています。バックアップについてもresticの暗号化バックアップは復元失敗とprune候補を先に見るで、取れているつもりではなく戻せるかを見る話を扱いました。今回も同じです。設定したつもりではなく、実装とログで見る必要があります。

自己申告を検証する手順

1. 報告された仕様を短い文にする
   例: 検知後に5分待機してから分析する。
2. 仕様に対応する実装の痕跡を探す
   例: sleep、delay、wait、300秒相当の待機処理など。
3. 現行コードだけでなく、バックアップ全世代も見る
   現行コードにないだけなら、過去には存在した可能性があります。全世代で0件なら、報告自体を疑う理由が強くなります。
4. 実データと突き合わせる
   今回なら、受信から分析完了までの実測が58〜68秒でした。これは5分待機と両立しません。
5. 人間が付けた呼び名と、実際の出力を分ける
   「トリガー不明」という呼び方は便利ですが、実際には「【判定】不明」でした。名前を少し間違えるだけで、存在しない機能を探すことになります。

報告・コード・バックアップ・実データを照合する

AIエージェントの報告確認には、いくつかのやり方があります。今回の読者にとって重要なのは、手間の少なさよりも、運用前提を間違えないことです。

方法	使う場面	完了判定に使えない場面	確認できるもの
エージェントの報告を読む	作業履歴を早く把握したい人	実装確認まで完了したい人	何をしたと言っているか
現行コードを読む	今動いている処理を確認したい人	過去の変更経緯も確認したい人	現在の実装
バックアップ全世代を全文検索する	報告と実装の矛盾を潰したい人	バックアップがない、または世代管理していない人	過去を含む実装の有無
実データと突き合わせる	仕様どおりに動いたか確認したい人	ログや時刻が残っていない環境	実際の挙動

今回、決定打になったのは「全文検索」と「実データ突合」の組み合わせでした。片方だけでは弱いです。コードに見つからないだけなら検索漏れの可能性があります。ログが速いだけなら別経路の可能性があります。両方が揃うと、かなり冷静に判断できます。

確認方法を組み合わせる理由

AIエージェントの自己申告を検証する運用には、明確なメリットがあります。

• 報告だけで運用前提を作らずに済む
• 存在しない不具合を追いかける時間を減らせる
• 後から「いつからそうだったか」を確認しやすい
• 無人運用の信頼性を、気分ではなく証拠で扱える

一方で、制約もあります。

• バックアップや履歴が残っていないと検証範囲が狭くなる
• 全文検索の対象を間違えると見落とす
• ログ時刻や出力形式が曖昧だと、実データ突合が難しい
• 初回は地味に時間がかかる

ただし、無人で動かすなら、この地味さは避けにくいです。ネットワークの分離や速度設計はネットワークの土台で扱ったように重要ですが、その上で動く処理の自己申告を信じすぎると、整った土台の上で間違いが安定稼働します。

自動化を増やす前に検証経路を作る

今回の話は、特定の製品を買えば解決する種類ではありません。むしろ、機材を増やす前に運用の見え方を整える話です。

新しい計算ノード、NAS、監視ツール、外部SSD、クラウドストレージを足す判断の前に、次の条件を見てください。

向いている状態:

• 実行ログが残っている
• バックアップが世代管理されている
• コード、設定、履歴を横断検索できる
• 実測値で仕様を確認する習慣がある

向かない状態:

• 「たぶん設定した」で運用している
• ログが短期間で消える
• バックアップはあるが復元や検索を試していない
• AIの出力と実装の境界を分けていない

物理面から整える場合は真似るなら最小構成や最小から始める拡張展望が入口になります。電源と熱の余裕は電源・電力・発熱で別途整理しています。ただし、どれを足しても、自己申告を検証しない運用はそのままです。

実装と実データを証拠にする

今回の教訓は単純です。

エッジ自律エージェントの「やりました」は、誰も検証しなければ幻覚でも残り続けます。

報告は入口です。証拠ではありません。実装、バックアップ、履歴、環境、実データを横断して初めて、運用前提として扱えます。

為替分析ノードの件では、5分待機もトリガー処理も存在しませんでした。検索ヒットは0件。実測は58秒、68秒、64秒。3件連続の「不明」は、トリガーではなくAIレポートの判定でした。

冷たい確認ですが、こういう確認が所長とラボを救います。AIを自宅で動かすなら、信じるより先に照合する。少なくとも、そういう順番にしておくべきです。

宣言・コード・実時間を3列で照合する

対象環境では「検知後に5分待つ」という宣言を、現行コード、バックアップ全世代、受信から分析完了までの時刻で照合しました。秘密を含む設定ファイルは検索結果へ出さず、待機を実装する語と秒数だけを探します。

rg -n --glob '*.py' --glob '*.sh' \
  'sleep|delay|wait|timeout|300' "$CURRENT_CODE" "$BACKUP_ROOT"
awk -F, 'NR>1 {print $3-$2}' analysis-events.csv

待機ロジック: 現行コード0件 / バックアップ全世代0件
実測時間: 58秒 / 68秒 / 64秒
「300」の関連候補: 300文字で要約（300秒待機ではない）
AIレポート: 【判定】不明 が3件連続

検索0件だけなら、別言語や外部スケジューラの可能性が残ります。実時間だけなら、処理の揺れと区別できません。宣言、実装、動作の三つが同じ結論を指すまで「設定済み」と扱わないのが、この調査で得た手順です。