Fable 5「記憶喪失」報告｜モデル変更に耐えるAI運用
Fable 5「記憶喪失」報告
2026年8月21日、XではClaude Fable 5を使う開発者から、以前の指示や作業状態をうまく引き継げないという声が話題になりました。現時点で、Fable 5というモデル自体が一律に「性能低下した」と断定できる一次情報はありません。一方で、昨日まで進めていた仕事を説明し直す、保存済みの記憶や過去セッションを読ませ直す、その復旧に利用枠を使う——という困りごとが複数の公開報告で確認できます。
ここで見落としたくないのは、モデルの賢さと、仕事を続きから再開できることは同じではないという点です。どれだけ高性能なモデルでも、目的、決定、却下理由、現在地点を取り出せなければ、その仕事では「記憶喪失」に見えます。反対に、記憶をモデルの外へ整理しておけば、最上位モデルでなくても、遅いながら同じ目的地へ進めます。
「性能低下」より先に見るべき記憶喪失
今回の話題には、モデルの推論能力、安全分類、製品側のルーティング、コンテキスト管理、記憶の検索、セッション再開など、異なる問題が混ざっています。利用者からは結果しか見えないため、「昨日頼んだことを忘れた」「急に話が通じなくなった」という一つの体験になります。
Anthropicの公開GitHubには、Fable 5とOpus 5が、永続メモリーファイルと過去セッションに答えがあるのに参照せず、同じ問題をやり直したという利用者報告があります。報告者は、過去セッションを読ませた後は数分で解けた一方、その前に一日で6時間以上を失ったと記録しています。これはAnthropicが認定した原因説明ではなく、再現環境を添えた公開ユーザー報告です。
別のFable 5の報告では、進行中の安全な開発作業を途中で閉じようとし、作業状態を戻す会話が週間利用枠を大きく消費したとされています。報告者自身も、原因がモデル、分類器、ルーティング、Claude Code側のどこにあるかは判断できないと明記しています。だから「Fable 5が壊れた」と決めつけるより、「どの層で文脈が切れても復旧できるか」を考える方が実務的です。
長いコンテキスト＝長期記憶ではない
コンテキストウィンドウは、いまの推論に入る作業机です。長期記憶は、次回も使う判断を保管し、必要な時に探し、正しい版を選ぶ書庫です。机が広くても、書庫の索引が壊れていれば必要な資料は見つかりません。逆に、書庫が整っていれば、机が小さくても必要な資料だけを持ち込めます。
Claude Code公式ドキュメントも、コンテキストが埋まると古いツール出力の整理や会話要約が行われ、初期の詳細指示が失われる可能性があるため、永続ルールはファイルへ置くよう案内しています。つまり、コンテキストが大きいこと自体は強みですが、それだけで継続運用の記憶が完成するわけではありません。
さらに、Claude Codeのコスト説明では、処理するコンテキストが大きいほどトークン使用量が増えるとされています。忘れた前提を長い会話の中で何度も説明し直すと、復旧の一往復ごとに重い文脈を扱うことになります。「思い出させるだけで利用枠が減る」という体感は、こうした構造と整合します。ただし、特定利用者の「8割」という数字を全利用者へ一般化はできません。
反対材料：Fable 5は記憶が弱いモデルなのか
ここは慎重に切り分ける必要があります。AnthropicはFable 5について、長時間の作業で指示を維持しやすく、ファイルベースの永続記憶を与えた評価では、以前のモデルより改善幅が大きかったと公式発表しています。公式プロンプトガイドも、Fable 5向けに記憶システムを作り、過去の教訓をファイルへ保存する方法を勧めています。
この反対材料から分かるのは、「Fable 5は記憶が弱い」と単純化できないことです。モデルの基礎能力が高くても、保存場所、検索、注入、圧縮、製品設定のどこかで文脈が切れれば、利用者には忘却として現れます。モデル評価と、利用中の製品体験は別の層です。
Claudeのブラウザ版にも、チャットから記憶を生成し、プロジェクトごとに記憶空間を分ける公式のメモリー機能があります。「Claudeには記憶がない」という説明も正確ではありません。問題は、記憶がどこにあり、誰が確認でき、別のモデルや環境へどう持ち出せるかです。
スポーツカー依存：モデル性能だけで走る設計
私たちは、モデル性能だけに文脈の維持を任せる状態を、舗装されていない道をスポーツカーの馬力だけで走る設計だと考えています。エンジンが強い間は速く進めます。しかし、モデル更新、利用枠、ルーティング、コンテキスト圧縮、検索失敗のどれかが起きると、まっすぐ走れなくなります。
しかも記憶がプラットフォーム内だけに閉じていると、別の車へ乗り換える時に道路まで失います。ClaudeからOpenAI、Gemini、ローカルモデルへ切り替えたくても、確定事項や却下理由が会話の中にしかなければ、仕事を続きから再開できません。モデルを替えられることと、仕事を移せることは別です。
これは「Claudeを使わない方がよい」という話ではありません。強いモデルは、複雑な問題を速く解くために有利です。ただし、最上位モデルだけが正しい道を見つけられる設計にすると、そのモデルが一時的に使えないだけで事業が止まります。
舗装された道路：外部記憶を運用の正本にする
舗装に当たるのが、モデルの外に置く記憶です。私たちの運用では、会話全文を「記憶」と呼びません。長く使う決定、今日の作業記録、現在地点、承認境界、失敗時の戻し方を分け、読み直せるファイルとして残します。
最低限、次の5種類があれば再開しやすくなります。
- 目的：何を実現する仕事か
- 現在地点：完了した工程と、次の一手
- 正本：最新の仕様や判断がある場所
- 境界：自動で進めてよいこと、人の確認が必要なこと
- 復旧情報：失敗時の戻し方、二重実行を防ぐ手掛かり
重要なのは、保存だけで終わらないことです。記憶を探す仕組み、必要な部分だけを読むルール、古い判断を最新として扱わない仕組み、実行後に現物を確認する流れまで必要です。AIの記憶はチャット履歴とは違うという考え方が、ここで効いてきます。
モデル変更に耐える：OpenClawとHermes Agentの強み
OpenClawの公式ドキュメントでは、長期記憶をワークスペース内のMarkdownへ保存し、モデルに隠れた永続状態はないと説明しています。人間が読めるため、誤った記憶を修正でき、別のモデルが同じ正本を参照できます。
また、OpenClawは設定した主モデルが利用制限や一時障害で使えない時、別モデルへ進むモデルフォールバックを持ちます。Hermes Agentも、複数の推論プロバイダーを切り替えられ、組み込みのMEMORY.mdに加えて外部記憶プロバイダーを選べます。どちらも「一つのLLMにすべてを預ける」より、モデルと記憶を分離しやすい構造です。
私たちの環境では、今回話題になったような全面的な作業停止は確認していません。ただし、これは「忘却が絶対に起きない」という意味ではありません。記憶検索の索引、セッションの範囲、読み込み予算、設定差分は別に監視する必要があります。外部記憶の価値は無事故の保証ではなく、壊れた場所を見つけ、別モデルで復旧できることにあります。
今日からできるモデル非依存の記憶設計
最初から大きな記憶基盤を作る必要はありません。まず、毎回説明している前提を一つのファイルへ移します。次に、作業を終える時に「完了したこと／次の一手／戻し方」を3行で残します。最後に、別のモデルへ切り替え、そのファイルだけで作業を再開できるか試します。
再開できなければ、モデルが弱いと判断する前に、足りなかった記憶を特定します。目的が曖昧だったのか、古い仕様を読んだのか、次の一手がなかったのか。失敗をモデルへの不満で終わらせず、道路の穴として直せば、次は軽いモデルでも前へ進めます。
AIを乗り換えても記憶を連れていくことと、モデルが変わっても文脈を維持することは、これからのAI運用で同じくらい重要になります。
よくある質問
Claude Fable 5は本当に性能低下したのですか？
現時点では一律の性能低下を断定できません。公開されているのは利用者報告で、原因はモデル、分類器、ルーティング、製品側の記憶・コンテキスト管理など複数考えられます。Anthropic公式はFable 5の長時間作業と記憶性能の向上も示しています。
ClaudeをやめてOpenAIへ移れば解決しますか？
モデルを替えるだけでは解決しません。記憶がClaude内の会話だけにある場合、移行先は判断の続きを知りません。先に目的、正本、現在地点、境界を外部化してから切り替える必要があります。
OpenClawなら記憶喪失は起きませんか？
起こり得ます。検索索引や設定、読み込み範囲が壊れれば必要な記憶を取り出せません。ただし、元の記憶が読めるファイルとして残っていれば、原因を調べて復旧し、別モデルへ引き継げます。
モデルはエンジン、記憶は道路
Fable 5をめぐる「記憶喪失」の声は、特定モデルの評価だけで終わらせるには惜しい問題提起です。どれほど高性能なモデルでも、仕事の前提を持ち出せなければ、更新や障害のたびに最初からやり直しになります。
スポーツカーなら速い。でも軽自動車でも目的地へ着ける。その状態を作るのは、モデルの外にある、見えて、直せて、持ち運べる記憶です。AIを選ぶことと同じくらい、AIが走る道路を整えることが、安定運用の差になります。
あわせて読みたい
AIと記憶の関係を研究する実録から、エージェントメモリーズ開発秘話まで。記憶を持つAIのつくり方を綴っています。
ほかの記事を読む Agent Memoriesを見る