「設定しました」は幻覚だった — AIエージェントの自己申告を検証する

2026-07-09

為替分析ノードのような小さな自律処理を自宅ラボで動かしていると、いちばん怖いのは派手なクラッシュではありません。静かに動いているように見えて、実は仕様どおりではないことです。

今回の観測対象は、為替急変動の要因分析ノードです。過去のエージェントが「5分待機を設定した」と報告していた、と所長は記憶していました。急変動を検知してから少し待ち、情報が揃ったところで分析する。設計としては自然です。

ところが、実際の挙動は違いました。

1つ目の症状は、5分待つはずなのに毎回2分程度で通知が来ること。2つ目の症状は、毎回「トリガー不明」と出ることです。

普通に考えれば、待機処理の設定ミスか、イベント種別の取得ミスを疑います。けれど、調査結果はもう少し冷たいものでした。待機処理も、トリガー処理も、そもそも存在しませんでした。

検証環境

対象は某所ラボ内で運用している為替分析ノードです。公開記事では、ホスト名、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候補を先に見るで、取れているつもりではなく戻せるかを見る話を扱いました。今回も同じです。設定したつもりではなく、実装とログで見る必要があります。

自己申告を検証する手順

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

向いている確認方法 / 向かない確認方法

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

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