AIエージェントが誤ったアクションを実行する原因は、ハルシネーションだけではありません。2026年8月28日にZenn AIで公開された「FreshCtx」の記事は、推論が論理的に正しく、ツールも仕様どおり動いても、推論してから実行するまでの間に現実が変わると判断が破綻するという失敗パターンを指摘し、それを扱うPython製ランタイムをオープンソース化したと発表しました。この記事はその中身を、中小企業のAI自動判断という視点で読み解きます。なお当社（株式会社TOE / AIの鬼）はAI検索対策・AI導入支援を売りうる立場であり、その前提で読んでください。
何が新しいのか — 「推論の賞味期限切れ」という分類
これまでAIの信頼性の話は「モデルが誤情報を生成する（ハルシネーション）」に寄っていました。FreshCtxの主張は別の失敗を切り出す点にあります。
記事が挙げる時系列はこうです。
| 時刻 | 出来事 |
|---|---|
| 10:00 | エージェントがシステム状態を観測 |
| 10:01 | その証拠をもとに推論 |
| 10:05 | 元の証拠が変化 |
| 10:15 | 以前の判断を実行 |
10:01時点で完全に正しかった推論が、10:15には使えなくなっている。推論が論理的に間違ったのではなく、古くなった（stale）のだ、というのが核です。
記事の具体例は在庫ドリフトです。エージェントが「在庫12、注文数10 → この注文は処理できる」と判断する。この推論自体は正しい。しかし実行前に別の取引が8個を消費し、在庫が4になる。古い推論のまま実行すれば、誤ったアクションになります。これはモデルの知能不足ではなく、実行時の証拠鮮度（evidence freshness）の問題だ、というわけです。
なぜモデルが賢くなっても解決しないのか
ここが中小企業にとって重要な点です。ハルシネーションなら「モデルが優秀になれば減る」という期待が持てます。しかし証拠鮮度の問題はモデルの性能と無関係です。最強のAIを使っていても、古い証拠に基づく推論なら実行時に破綻します。
エージェントは1回で完結せず、時間をまたいで動きます。記事はその流れを「観測 → 推論 → 計画 → 待機 → ツール呼び出し → 承認待ち → 実行」と書いています。この待機や承認待ちの間に、ファイル・Gitコミット・データベースレコード・APIリソース・在庫・設定が変わりうる。別のエージェントや人間が先に操作することもある。危険なのは「生成時に正しかった推論は実行時にも正しい」と暗黙に仮定することだ、と記事は指摘します。
つまりエージェント型のAI活用が増えるほど、この問題は避けにくくなります。在庫管理や機械稼働状況の自動判断をAIに任せるなら、「証拠の有効性を実行直前に再検証する」という概念を先に知っておかないと、表面上は何も問題なく見えるまま数字が狂い始める、という構図です。
Memory・RAG・認可とは何が違うのか
FreshCtxの記事は、既存の仕組みとの違いを丁寧に切り分けています。素材から整理すると次のとおりです。
| 仕組み | 答える問い | FreshCtxとの違い |
|---|---|---|
| Memory | エージェントが以前何を観測したか | 記憶しても、その内容が今も真とは限らない |
| RAG | ある時点で正しい情報を検索して取り込む | 検索の後に証拠が変化すると防げない |
| 認可 | この主体はこのアクションを実行してよいか | 権限があっても古い推論で誤実行しうる |
| FreshCtx | この推論が依存する証拠は今も有効か | 実行境界で鮮度シグナルを提供する |
inventory = 12 を完璧に記憶していても、それは古い情報を正確に保存しているだけかもしれません。RAGで時刻Aに新鮮だった情報が、時刻Bでも新鮮とは限りません。認可が十分でも、古い推論に基づけば誤ったアクションは実行できてしまう。FreshCtxはこれらを置き換えるのではなく、実行の直前に「証拠がまだ有効か」を確かめる層を足す、という位置づけです。
エージェントとRAGなどの違いを整理したい方には、社内での線引きをまとめた生成AIの社内ルールに何を書くか — 規定があるのは3.7%。当社が実際に運用している7つの線引きもあわせてどうぞ。
FreshCtxは具体的に何をするのか
記事によると、FreshCtxは再検証を「第一級ランタイムプリミティブ」として組み込む設計です。エージェントは推論が依存した証拠を宣言し、アクション実行前にFreshCtxがその証拠を再検証します。現在のランタイムは証拠の状態を4つに区別します。
- FRESH（変わっていない）
- CHANGED（変化した）
- EXPIRED（失効した）
- UNAVAILABLE（検証できない）
CHANGED・EXPIRED・UNAVAILABLEのとき、ランタイムポリシーが「古い推論が黙って実行に進むこと」を止められます。
v0.1で再検証できる証拠ソースは、ファイルシステム／Gitの状態／HTTPリソース／PostgreSQLデータソース／MCPで読み取り可能なリソース。アダプターは拡張可能とされています。配布は pip install freshctx で、GitHub・PyPI・Webが公開されています。記事は「巨大なAIフレームワークを目指さない」と明言し、MemoryプラットフォームでもベクトルDBでも認可エンジンでもなく、宣言された証拠を実行前に再検証して古い推論を無効化する、その一点だけを行うと述べています。
「値を見せない」「キーを渡さない」といった、エージェントの実行境界を狭く設計する発想は最近まとまって出てきています。関連してAIエージェントに「キー名だけ」渡す設計は成立するのか ― trustlessが値を見せない一点に絞った理由、AIエージェントがHugging Faceを自分でハッキングした──なぜ「目標を与えれば安全に動く」は幻想なのか？も、同じ「エージェントは想定どおり動くとは限らない」という文脈にあります。
当社の実測と突き合わせると何が言えるか
当社は社内業務の自動化を27本運用し、ニュース収集・要約・記事生成を人手を介さず毎日自動で回しています（2026-08-29時点で収集済みニュース3000件・自社要約つき1841件・本文取得済み933件・記事270本、運用中のAI API課金は0円）。この自動化は「観測して判断して実行する」流れを含みますが、当社はFreshCtxのような証拠鮮度の再検証を実装しておらず、その効果を測っていません。この記事は導入事例ではなく、外部の発表の読み解きです。
言えるのは、当社の自動化が扱っているのが主に「記事を書く・公開する」という、実行前後で外部状態が矛盾しても致命傷になりにくい領域だ、ということです。逆に在庫・決済・インフラ・機械稼働のように、実行の瞬間の数字が結果を左右する領域では、証拠鮮度の問題が現実の損失に直結します。FreshCtxの記事が挙げる在庫ドリフトは、まさに日本の製造業の在庫管理・受発注に重なります。
この記事で言えないこと
- FreshCtxが実運用で誤実行をどれだけ防ぐか、その効果は素材に数字がなく、素材からは分かりません。
- FreshCtxの導入コスト・保守負担・既存システムへの組み込み難易度は素材に記載がなく、分かりません。
- 中小企業のどの業務でこの再検証が費用対効果に見合うかは、当社は測っていません。
- 当社の自動化27本に証拠鮮度の問題が起きているかどうかも、計測していないため分かりません。
- 「aiエージェント 総務」のような総務業務での具体的な適用可否は、素材に事例がなく分かりません。
まとめ
- AIエージェントの失敗には、ハルシネーションとは別に「推論の賞味期限切れ（証拠鮮度）」がある、というのがFreshCtxの核です。
- この問題はモデルの性能と無関係で、推論から実行までの時間差と、その間の現実の変化から生まれます。
- FreshCtxは実行直前に宣言済みの証拠を再検証し、FRESH／CHANGED／EXPIRED／UNAVAILABLEで古い推論の実行を止める、狭い設計のオープンソースです。
- Memory・RAG・認可とは別の問いに答える層で、既存構成を置き換えず足す位置づけです。
- 在庫・決済・機械稼働など「実行の瞬間の数字が効く」自動判断を本番に出す中小企業は、この概念を先に知っておく価値があります。ただし当社は導入・効果測定をしておらず、ここでは効果を保証できません。
この記事はZenn AIのFreshCtx公開記事を素材に、当社（株式会社TOE / AIの鬼）の自動運用の実測（自動化27本・記事270本・AI API課金0円、2026-08-29時点）とあわせて書きました。
