---
title: "トラブル対処: エージェントが前より賢くなくなった気がするとき"
description: "Hermes の調子が以前より落ちて見えたり、セッションの途中で物忘れをしたりするときの診断手順。モデルの切り替わり、コンテキストの逼迫、コンテキスト長の誤検出、固定されたメモリのスナップショットを順に確認します"
upstream_path: guides/troubleshooting-agent-quality.md
upstream_blob: 67a10953688c6e07ee0d2512809797664ecdd49e
sources:
  - https://hermes-agent.nousresearch.com/docs/guides/troubleshooting-agent-quality
---

# トラブル対処: エージェントが前より賢くなくなった気がするとき {#troubleshooting-my-agent-feels-dumber}

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

## 1. そのセッションが実際にどのモデルを使っているか確かめる {#1-check-which-model-the-session-is-actually-using}

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

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

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

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

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

## 2. コンテキストの使用量を確認する {#2-check-context-usage}

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

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

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

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

# Or start a fresh session
/new
```

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

:::tip
問題が起きるのを待つのではなく、長いセッションでは `/compress` をこまめに使い、`/usage` で現在地をときどき確かめるのがおすすめです。
:::

## 3. 検出されたコンテキスト長を確かめる {#3-verify-the-detected-context-length}

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

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

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

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

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

```yaml
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.*` のキーを書き換えれば次のメッセージから反映されます。再起動は要りません。

自動検出のしくみと上書きの選択肢は [コンテキスト長の検出](/hermes/docs/integrations/providers/#context-length-detection) を参照してください。

## 4. 「伝えたのに忘れられた」——固定されたメモリのスナップショット {#4-i-told-it-something-and-it-forgot-the-frozen-memory-snapshot}

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

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

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

:::info
固定スナップショットの実際: セッション中の「X を覚えておいて」は、X が**次の**セッションで確実に使えるようになる、という意味です。今のセッションの中でも、その事実は会話の履歴そのものに残っています。エージェントが忘れるのは、その部分の会話がすでに圧縮で失われている場合だけです（手順7を参照）。
:::

くわしい仕組みは [永続メモリ](/hermes/docs/user-guide/features/memory/#how-memory-appears-in-the-system-prompt) を参照してください。

## 5. メモリには上限があり、選び抜かれたものが入る——記録ではない {#5-memory-is-bounded-and-curated-not-a-transcript}

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

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

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

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

自分から手を貸すこともできます。実りのあるセッションのあとに「次のために覚えておいて」と伝えたり、容量が上限に近づいたら「メモリを整理して」と言えば、エージェントが項目をまとめ直します。[メモリとスキルのヒント](/hermes/docs/guides/tips/#memory--skills) と [容量の管理](/hermes/docs/user-guide/features/memory/#capacity-management) も参照してください。

## 6. スキルとツールが読み込まれているか確かめる {#6-check-that-skills-and-tools-are-loaded}

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

**確認:**

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

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

## 7. 圧縮の副作用 {#7-compression-side-effects}

**症状:** 長いセッションのあと（あるいは `/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` は保管されたやり取りまで届きます）、要点をもう一度会話に貼り直してください。

設定の全項目は [コンテキストの圧縮](/hermes/docs/user-guide/configuration/#context-compression)、題名付きセッションがどうつながるかは [圧縮時の自動的な系譜](/hermes/docs/user-guide/sessions/#auto-lineage-on-compression) を参照してください。

---

## 早見表 {#quick-reference}

| 症状 | まず打つコマンド | 考えられる原因 |
|---------|--------------|--------------|
| 全般的に能力が落ちて見える | `/model` | 思っているのと違うモデルでセッションが動いている |
| 長いセッションで質が落ちてきた | `/usage` | コンテキストの逼迫——圧縮するか、新しく始める |
| 思ったより早く上限に当たる | CLI の起動時の行 / `/usage` | 自動検出されたコンテキスト長が違う |
| このセッションで言ったことを忘れた | —（仕様どおり） | メモリの固定スナップショット——次のセッションで現れる |
| 先週の話を忘れた | `session_search` を頼む | メモリには上限があり、要点だけが入る |
| 特定のことができなくなった | `/skills`、`/tools list` | そのセッションでスキルかツールセットが読み込まれていない |
| 長いセッションのあと古い細部が消えた | `/usage`、`/context` | 圧縮が古い履歴を要約した |