AIエージェントの失敗には、ハルシネーションとは別の分類があります。推論は論理的に正しく、ツールも仕様どおり動き、それでも最終アクションが間違う。原因は「推論してから実行するまでの間に現実が変わった」ことです。この問題に対処するPythonランタイム「FreshCtx」が2026年8月28日にオープンソース化されました。本記事は、この仕組みが中小企業の自動判断で何を変えるのかを、当社の自動運用の実測とあわせて読み解きます。なお株式会社TOEはAI検索対策・AI導入支援を売りうる利害関係者です。その立場を明示したうえで書きます。
何が起きたのか — 「賞味期限切れ」の推論という失敗パターン
FreshCtxの開発チームは、AIエージェントの失敗を時間軸で分類し直しました。素材にある例がそのまま核心です。
- 10:00 エージェントがシステム状態を観測
- 10:01 その証拠をもとに推論
- 10:05 元の証拠が変化
- 10:15 以前の判断を実行
10:01時点で完全に正しかった推論が、10:15には使えなくなっている。これは推論が論理的に間違ったのではなく、古くなった（stale）のです。素材の具体例は在庫ドリフトです。在庫12・注文10なら「処理できる」という推論は正しい。しかし実行前に別の取引が8個を消費し、在庫が4になっていれば、古い推論のまま実行したエージェントは誤ったアクションを起こします。これはモデルの知能不足ではなく、実行時の証拠鮮度（evidence freshness）の問題だ、というのがチームの主張です。
ハルシネーション・Memory・RAG・認可とどう違うのか
素材は、この問題が既存の概念では埋められないことを丁寧に切り分けています。表にまとめます。
| 概念 | それが答える問い | FreshCtxが答える問い |
|---|---|---|
| ハルシネーション | モデルは誤情報を生成していないか | 生成後、証拠が変わっていないか |
| Memory | エージェントは以前何を観測したか | 観測した内容は今も真か |
| RAG | ある時点で正しい情報を取り込めたか | 検索の後に証拠が変化していないか |
| 認可 | この主体はこのアクションをしてよいか | この推論を支える証拠はまだ有効か |
とくに重要なのは、この問題がモデルの性能と無関係だという点です。ハルシネーションなら「モデルが優秀になれば解決する」という未来が描けます。しかし推論の鮮度問題は、最強のAIを使っていても、古い証拠に基づく推論なら実行時に破綻します。つまりエージェント型のAI活用が増えるほど避けられなくなる、という構造です。
FreshCtxが実際に何をするのか
FreshCtxは再検証を「第一級ランタイムプリミティブ」として組み込む設計です。エージェントが推論の依存した証拠を宣言し、AIが支援するアクションを実行する直前に、FreshCtxがその証拠を再検証します。現在のランタイムは証拠の状態を4つに区別します。
- FRESH（新鮮）
- CHANGED（変化した）
- EXPIRED（失効した）
- UNAVAILABLE（検証できない）
証拠が変化・失効・検証不能のとき、ランタイムポリシーが「古い推論が黙って実行に進む」ことを防ぎます。v0.1に含まれるアダプターは、ファイルシステム・Gitの状態・HTTPリソース・PostgreSQLデータソース・MCPで読み取り可能なリソースの5種で、拡張可能です。導入は pip install freshctx です。
設計思想として、FreshCtxはあえて狭いランタイムに徹しています。Memoryプラットフォームでも、ベクトルデータベースでも、認可エンジンでもない。行うことは「AIによるアクションの実行前に、宣言された証拠を再検証し、影響を受ける古い推論を無効化する」の一点だと明言しています。既存のエージェントスタックを置き換えず、証拠鮮度の制御だけを追加する狙いです。
中小企業にとって何が変わるのか
日本の製造業で在庫管理や機械稼働状況の自動判断をAIに任せるなら、この「証拠の有効性を実行直前に再検証する」という概念を先読みしておく価値があります。怖いのは、表面上は何も問題なく見えるまま数字が狂い始める点です。ハルシネーションのように「明らかに変な出力」が出るわけではないため、気づくのが遅れます。
ただし、これは今すぐ全社導入すべきツールという話ではありません。FreshCtxが効くのは「観測→推論→計画→待機→ツール呼び出し→承認待ち→実行」のように、判断と実行の間に時間が空き、その間に在庫・設定・DBレコードが他者に書き換えられうる場面です。人が最終ボタンを押す運用なら、そもそも実行直前に人が現物を見ます。自律的に実行するエージェントを本番に出す段になって、初めて必須の装備になります。
当社の自動運用の実測を突き合わせると、この「待機時間中に状態が変わる」構造は他人事ではありません。当社は社内業務の自動化を27本動かし、AI秘書のブリーフィングを毎朝8:00に回し、メディア側では収集・要約・記事化を人手を介さず毎日自動で動かしています（2026-08-30時点で収集済みニュース3000件・本文取得済み949件・記事272本）。日次の自動更新は36日分の記録があり、最後に動いたのは2026-08-30です。これだけ多段のパイプラインを無人で回すと、上流のデータが更新された後に下流の判断が実行される瞬間は構造的に生まれます。証拠鮮度は、規模の大小より「判断と実行が時間的に離れているか」で効いてくる問題だと、自社の運用実感からも言えます。
なお、FreshCtxの導入で失敗が何件減るか、といった効果は当社では測っていません。素材にも効果測定の数値はありません。「後から気をつけていれば、という無駄な失敗を前倒しで防げる」という主張は、素材が述べる期待であって、検証された成果ではありません。
この記事で言えないこと
- FreshCtxを導入すると誤アクションが何%減るのか。素材にも当社にも、効果を測った数値はありません。
- 実運用での再検証にかかるレイテンシや処理コスト。素材からは分かりません。
- 日本の中小企業でFreshCtxを本番導入した事例。当社は把握しておらず、素材にもありません。
- FreshCtxと既存の在庫管理システム・ERPとの具体的な連携手順。素材はアダプターの存在を示すのみです。
- 同じ出来事を扱った他社の報道。今回は0件で、比較・食い違いの検証はできません。
- 当社はFreshCtxを本番導入して自社の失敗削減を測ってはいません。この記事は概念の読み解きです。
まとめ
- FreshCtxは、推論してから実行するまでに現実が変わる「証拠鮮度」の問題を扱うPythonランタイムで、2026-08-28にオープンソース化されました。
- 失敗はハルシネーションではなく、正しかった推論が古く（stale）なった時間軸のズレです。在庫12・注文10の推論が、実行前に在庫4へ変われば誤判断になります。
- Memory・RAG・認可のいずれとも別問題で、しかもモデルの性能と無関係。エージェント活用が増えるほど避けられません。
- 証拠をFRESH/CHANGED/EXPIRED/UNAVAILABLEの4状態で判定し、古い推論が黙って実行されるのを実行境界で止めます。
- 中小企業で効くのは「判断と実行が時間的に離れる」自律エージェントの場面。人が最終ボタンを押すうちは急ぎませんが、概念の先読みには価値があります。効果は当社も素材も測っていません。
あわせて、当社の視点を掘り下げたAIエージェントの推論に「賞味期限」があるとは？ — FreshCtxが実行直前に証拠を再検証する仕組みで、中小企業の自動判断は何が変わるのかと、AIエージェントの推論には「賞味期限」があるのか — 実行直前に証拠を再検証するFreshCtxで中小企業の自動判断は何が変わるのかもご覧ください。無人運用の線引きについては生成AIの社内ルールに何を書くか — 規定があるのは3.7%。当社が実際に運用している7つの線引きが参考になります。
この記事はZenn AIの「AIエージェントの推論にも『賞味期限』がある：FreshCtxをオープンソース化しました」を素材に、株式会社TOE（AIの鬼）が2026-08-30時点で自動集計した自社運用の実測とあわせて書きました。
