トラブル対処: エージェントが前より賢くなくなった気がするとき

Hermes が昨日より切れ味を欠いて見えたり、20分前に伝えたことを忘れていたりすることがあります。これはたいてい謎めいた現象ではなく、具体的で確かめられる原因が1つあるだけです。次の手順を上から順にたどってください。よくある答えから並べてあります。

1. そのセッションが実際にどのモデルを使っているか確かめる

症状: 回答が浅くなった、コードの質が落ちた、推論がどこか噛み合わない——全般的にそう感じる。

確認: 引数なしで /model を実行すると現在のモデルが表示されます。/status なら、そのセッションのモデル・プロバイダー・プロファイルをまとめて見られます。

意味するところ: モデルが変わるということは能力が変わるということで、しかも自分の思っているのと違うモデルに乗ってしまうのは簡単に起こります。

• ただの /model <name> による切り替えは、既定ではそのセッション限りです（model.persist_switch_by_default: true を設定していない場合）。つまり、今のモデルは config.yaml の内容と一致しているとは限りません。
• ダッシュボードの Models ページで主モデルを変更しても、それが効くのは新しいセッションだけです。すでに開いているチャットは、始まったときのモデルで動き続けます。
• 簡単な作業のために速いモデルへ切り替えたのであれば（ヒントとベストプラクティス が勧めているやり方です）、込み入った推論の作業に戻るときは切り替え直すのを忘れないでください。

モデルが違っていたら、/model <name> でそのセッションを直せます。--global を付ければ config.yaml に書き込んで恒久化できます。なお、セッションの途中で切り替えるとプロンプトキャッシュが破棄され、次のやり取りで会話全体を入力として読み直すため満額の料金がかかります。長いセッションでは、正しいモデルで新しく始めたほうが安く済むこともあります。

2. コンテキストの使用量を確認する

症状: 出だしは快調だったのに、応答が遅くなってきた、途中で切れる、前のほうの話を見失っている。

確認: /usage でトークンの使用量とコンテキストウィンドウの状態が分かります。/context なら、ウィンドウを何が占めているのか（システムプロンプト、ツール定義、スキル、メモリ、会話）と空き容量を、目で見て把握できます。

意味するところ: 会話が長くなるとメッセージとツールの出力が積み上がり、コンテキストの上限に近づきます。長いセッションで質の低下に気づいたら、次のようにします。

# Compress the conversation (summarizes history, preserves key context)
/compress

# Or start a fresh session
/new

/compress は会話の履歴を要約し、大事な文脈を残したままトークン数を大きく減らします。/compress here [N] は直近 N 往復をそのまま残して残りを要約し、話題の指定（/compress focus <topic>）を付けると、全体を要約するときに何を優先して残すかを絞り込めます。

3. 検出されたコンテキスト長を確かめる

症状: コンテキストの問題が思いのほか早く出る。最初の長い会話でもう上限に当たる、あるいはモデルの公称ウィンドウから考えるとずっと早い段階で圧縮が走る。

確認: CLI の起動時の行を見てください。検出されたコンテキスト長が表示されています（例: 📊 Context limit: 128000 tokens）。セッション中なら /usage でも確認できます。

意味するところ: Hermes がそのモデルのコンテキスト長を誤って自動検出している場合があります。次のように明示してください。

# In ~/.hermes/config.yaml
model:
  default: your-model-name
  context_length: 131072  # your model's actual context window

独自のエンドポイントであれば、プロバイダーの項目にモデルごとに書くこともできます。

providers:
  my-server:
    api: "http://localhost:11434/v1"
    models:
      qwen3.5:27b:
        context_length: 64000

Ollama を使っている場合、num_ctx を独自に設定しているなら、Hermes 側にも同じコンテキスト長を設定してください。Ollama の /api/show が報告するのはそのモデルの*最大*コンテキストであって、実際に設定した num_ctx ではありません。ゲートウェイが動いている状態でも、model.context_length や compression.* のキーを書き換えれば次のメッセージから反映されます。再起動は要りません。

自動検出のしくみと上書きの選択肢は コンテキスト長の検出 を参照してください。

4. 「伝えたのに忘れられた」——固定されたメモリのスナップショット

症状: セッション中に何かを覚えておくよう頼み、保存されたと返ってきたのに、*同じ*セッションの後半でそれを知らない様子だ。

確認: 壊れてはいません。タイミングの問題です。セッションの途中で保存されたメモリはすぐにディスクへ書かれますが、システムプロンプトに反映されるのは次のセッションからです。

意味するところ: これは文書化された、意図どおりの動きです。メモリはセッション開始時に固定されたスナップショットとしてシステムプロンプトへ差し込まれ、その差し込み内容はセッションの途中で変わりません。LLM の接頭辞キャッシュを保つためです。エージェントがセッション中にメモリの項目を足したり消したりすると、その変更はすぐディスクへ残りますが、システムプロンプトに現れるのは次のセッションが始まったときです。ツールの応答は常に最新の状態を返すので、保存されたこと自体は本当です。

くわしい仕組みは 永続メモリ を参照してください。

5. メモリには上限があり、選び抜かれたものが入る——記録ではない

症状: 先週のセッションでじっくり話したことなのに、Hermes がその細部を思い出せない。

確認: メモリの容量と中身です。システムプロンプトのメモリ見出しに使用量が出ますし（例: [67% — 1,474/2,200 chars]）、hermes journey list で保存されたメモリの項目とスキルをすべて確認できます。

意味するところ: 永続メモリには意図的に上限があります。MEMORY.md は 2,200 文字（およそ 800 トークン）、USER.md は 1,375 文字（およそ 500 トークン）です。ここに入るのは選び抜かれた要点であって、会話の記録ではありません。保存する価値があるのは、好み、環境まわりの事実、決まりごと、そして訂正です。話し合いの細かな内容は、設計としてここには残しません。

「先週 X について話したか」を思い出すには、別の仕組みがあります。session_search は過去のセッションすべて（全文検索付きの SQLite に保存されています）を検索し、いま手元のメモリに無くても数週間前の話題を見つけられます。ただ頼めば済みます——「デプロイの話をした過去のセッションを検索して」のように。

自分から手を貸すこともできます。実りのあるセッションのあとに「次のために覚えておいて」と伝えたり、容量が上限に近づいたら「メモリを整理して」と言えば、エージェントが項目をまとめ直します。メモリとスキルのヒント と 容量の管理 も参照してください。

6. スキルとツールが読み込まれているか確かめる

症状: 以前はある作業の流れを手際よくこなしていたのに、いまは素朴なやり方で取りかかる。あるいは、前にできたことを「できない」と言う。

確認:

• /skills — 入っているスキルを見ます（エージェントが頼りにしていたスキルが消えている場合があります）。
• /reload-skills — ~/.hermes/skills/ を読み直して、追加や削除を反映します。
• /tools list — 使えるツールを見ます。以前 /tools disable で無効にしたツールは、そのセッションのあいだ外れたままです。
• /context all — スキルごと・ツールセットごとの消費量の一覧で、実際に何が読み込まれているかの目録も兼ねます。

意味するところ: スキルはエージェントにとっての手順の知識で、複数段階の作業の流れやツール固有の指示が入っています。スキルが無かったり、ツールセットが絞られていたり（たとえばプロンプトを軽くするために hermes chat -t "terminal" で始めた場合）すると、そのセッションでエージェントが使えるものは本当に少なくなります。/tools enable でツールを戻すか、スキルを名前で明示的に呼び出して（/github-pr-workflow）読み込まれることを確かめてください。

7. 圧縮の副作用

症状: 長いセッションのあと（あるいは /compress を実行した直後）、Hermes は大きな流れは覚えているのに、会話の前半の細かい部分を失っている。

確認: 圧縮が走ったかどうかです。メッセージ系のプラットフォームでは /usage と /context に圧縮の統計とコンテキストの状態が出ますし、手動の /compress は必ず結果を報告します。

意味するところ: 圧縮は古い会話の履歴を要約に置き換えます。それが目的であり、余裕を作るために細部を手放すのは避けられません。どういう形で行われるかを知っておいてください。

• 直近のメッセージは守られます。既定では最後の20件が圧縮されず（protect_last_n）、最初のやり取りも固定されるので（protect_first_n: 3）、当初の目的が見えたままになります。
• 圧縮は破壊的ではありません。既定の compression.in_place: true では、セッションは1つの永続的な id を保ち、圧縮前のやり取りはそっと保管されます。削除ではなく、session_search で検索でき、取り戻すこともできます。
• in_place: false（以前の動き）にすると、圧縮のたびに元のセッションと結びついた新しいセッションへ移ります。題名の付いたセッションは "my project" → "my project #2" → "my project #3" と連なっていきます。題名で再開する場合、hermes -c "my project" は自動的にいちばん新しいものを選びます。
• 話題を指定すると、全体を要約するときに何を残すかを絞れます。/compress focus auth-refactor とすれば、その筋の細部を残し、そのぶん他が薄くなります。

圧縮で失われた細部がどうしても必要なら、エージェントに検索を頼むか（session_search は保管されたやり取りまで届きます）、要点をもう一度会話に貼り直してください。

設定の全項目は コンテキストの圧縮、題名付きセッションがどうつながるかは 圧縮時の自動的な系譜 を参照してください。

早見表