LightVelaドキュメント

概要

モデルを切り替えてもHermes Agentがあなたを忘れることはありません。なぜなら、モデル、ペルソナ、メモリは三つの別々に保存される層だからです：モデルは推論と生成を担当し、SOUL.mdは役割と表現の境界を定義し、USER.mdとMEMORY.md（memories/を含む）はユーザープロファイルとセッション間の事実を保持します。LightVelaでは、モデルを切り替えると後続の返信の背後にあるエンジンが変わるだけで、メモリ、クラウドストレージのファイル、スキル、または自動化設定が消えることはなく、チャット履歴も移動しません。後で実際に"違う感じ"がすることはありますが、それは新しいモデルの指示に従う能力、文脈圧縮、冗長性、ツール呼び出しの傾向から生じるものです。データの喪失によるものではありません。それらを見分ける方法は正確に1つだけです：知っているはずの事実について質問してください。もし答えれば、スタイルの違いを見ていることになります。答えられなければ、メモリ層を調査してください。

---

表現が変わった — メモリも変わったのだろうか？

モデルを切り替えた後、最も一般的な経験は次の通りです：言い回しが変わり、長さが変わり、それまでに話したことをもう取り上げなくなる。

ほとんどの人の最初の反応は「忘れられた」です。その反応は自然です — 日常生活で、誰かが共通の過去のことに触れなくなると、私たちは忘れたのだと思うことがあります。

しかし、エージェントシステムの内部では、この類推は誤解を招きます。「言及しないこと」と「知らないこと」はまったく別物です。 前者は表現戦略であり、後者はデータの欠落です。診断方法、修正コスト、重大性が異なり、これらを混同すると存在しない問題を修理するのに時間を費やすことになります。

この記事では、この二つを明確に区別し、実行可能なテストを提供します。

---

1. 五つの層：何が置き換えられ、何が残るか

まず、「モデルを切り替える」行為が実際に何を変えるのかを正確に把握します。

重要なポイント：最後の4つの層はすべてモデルの外に存在します。 モデルが置き換えられても、それらのファイルとディレクトリは元の場所にそのまま残り、新しいモデルがそれらを読み取り適用します。

このため、ドキュメントではモデルを切り替えてもエージェントの記憶、クラウドストレージのファイル、スキル、または自動化設定が消去されないと明言できるのです — これは誰かが追加した保護機能ではなく、層状ストレージの自然な結果です。作業分担の全体像については、「Hermes Agentの脳は置き換え可能か？モデル層とエージェント層」を参照してください。

---

2. では、なぜ実際に違いを感じるのでしょうか？

データはすべて intact であるのに、なぜ体験が変わるのでしょうか？それは、同じコンテキストが異なるモデルに渡されると、再解釈されるからです。

モデルは次のような実際の次元で異なります：

2.1 指示の遵守

SOUL.md の制約はまだ存在しますが、新しいモデルではそれをより緩やかに適用する場合もあれば、より厳密に適用する場合もあります。もし「結論から先に述べる」と書いた場合、あるモデルは常にそれに従いますが、他のモデルは複雑な質問では結論に至るまで徐々に構築します。

見た目上: 性格が変わった。 実際には: ルールは変わらず、遵守の仕方が変わった。

2.2 コンテキスト圧縮

回答を作成する際、エージェントはどの程度の背景情報を引用するかを決定します。モデルによって重視の仕方は異なります：あるものは積極的に「先ほどXについて触れました」と再述しますが、他のものはあなたが知っていると仮定して、すぐに要点に入ります。

見た目：私たちが話したことを忘れたように見える。 実際：記憶は機能していますが、単にそれを再述しなかっただけです。これは最もよく健忘症と誤診されるケースです。

2.3 冗長さの好み

同じ質問でも、モデルによって回答の長さは数倍違うことがあります。

見た目としては: 賢さが落ちた、または冗長になった。 実際には: USER.md の設定や明示的なリクエストで調整可能な、異なるデフォルトの冗長性。

2.4 ツール呼び出しの傾向

一部のモデルは回答する前にファイルを読んだり検索したりすることを好む; 他のモデルは既存のコンテキストに依存する傾向がある。

見た目としては: ツールの利用をやめた。 実際には: ツールを呼び出すための閾値が異なるだけ。

2.5 言語スタイル

言い回し、呼称、トーンはいずれも変わる可能性がある。

見た目: 他の誰かになった。実際: 表面的で最も無害なカテゴリ。

まとめて見ると、これら五つには一つの共通点があります: それはすべて「何を知っているか」ではなく、「どう表現するか」に関するものです。 これこそ、以下のテストが依拠しているものです。

---

3. 一つの行動で決まります: 既知の事実について質問すること

感覚で判断しないでください。決定的なテストを使用してください。

方法: 明示的に伝えたと確信している事実を思い浮かべ、それはすでに長期記憶にあるはずです — プロジェクト名、言語の好み、明示的な制約など。切り替えた後は、その事柄について正確に質問してください。

解釈:

このテストは、表現変数を取り除くことで機能する：答えが明確な事実について尋ねているので、スタイルがどう変わっても正確さは客観的である。

---

4. スイッチ後の完全なチェックリスト

この順序は、大多数のケースをカバーしている。

1. 切り替えが有効になったことを確認する — コンソールには選択したモデルが表示されているはずです。これで「切り替えたつもりだったが、実際には切り替わっていなかった」という可能性は排除されます。
2. 短いテストメッセージを送る — 新しいモデルが正常に応答することを確認します。切り替え後の最初の応答が少し遅い場合は、他の操作を行う前に一度だけ待って再試行してください。
3. 既知事実のテストを実行する — セクション3を使用してメモリ層を確認します。
4. ペルソナが引き続き期待通りであることを確認する — トーンや制限がSOUL.mdの範囲内にあるか観察します。明らかにずれている場合は、主要な制約をより具体的にします。
5. スキルがまだ発動するかスポットチェックする — 該当する状況でスキルを試し、スキルがロードされることを確認します。
6. 自動化の出力品質を確認する — モデルフィールドを同期しているわけではなく、出力の品質 を確認していることに注意してください。自動化には「固定モデル」設定はありません。
7. クラウドストレージのファイルが無事であることを確認する — 切り替えは書き換えを行わないため、これは確認作業のみです。

ステップ6は強調に値します。なぜなら、切り替え後に各自動化のモデルを再同期しなければならないという広く流布された主張があるからです。実際には、自動化は名前、スケジュール（固定曜日、固定間隔、または一度きり）、タスク指示、稼働時間帯、および通知チャネルで構成されており、モデルフィールドは存在しません。したがって、正しい対応は、1回実際に実行されるのを待ち、出力の品質が期待通りであるか確認することです。

---

5. 切り替え後に実際に動作しなくなる場合

これは異なる種類の問題です — 「感覚が異なる」のではなく「機能しない」場合です。次の順序でトラブルシュートしてください：

1. モデル構成が完了していることを確認する — モデル構成に戻り、対象モデル、資格情報、およびプロバイダー設定を確認してください。
2. アカウントの利用可能性とクォータを確認する — モデルがアカウントで利用可能であり、プロバイダー側のクォータや残高が十分であることを確認してください。
3. 動作が確認されているモデルでテストする — これにより「このモデルに問題がある」のか「全体の経路に問題がある」のかを区別できます。
4. 診断で最近のログを確認する — それでも応答できない場合は、ログを使用して問題がモデル、設定、タスクのどこにあるかを判断し、その後モデルの設定をリセットするかどうかを決定します。

覚えておくべき一般的な原則の1つは、一度に1つの要素を変更し、変更ごとにテストすることです。 モデルを切り替え、ペルソナを編集し、スキルを追加することを一度に行うと、失敗の原因を特定できなくなります。トラブルシューティングの際、この規律は、すべてを一度に設定するという感覚よりもはるかに価値があります。

---

6. 切り替えるべき場合と、そうでない場合

切り替えにはコストがあります：異なる表現スタイルに再適応する必要があり、プロンプトを再調整する必要があるかもしれません。ですので、動機を明確にする価値があります。

切り替える価値がある場合：

切り替える価値がない場合：

• 一つの回答に失望したからです。まず、プロンプトが十分に具体的であったか、またはSOUL.mdの制約が十分に具体的であったかを確認してください。
• 他のモデルがより強力だと聞いたからです。強いことは、あなたのタスクの組み合わせやコストのプロファイルにより適していることと同じではありません。
• 「メモリ問題を修正する」ために。メモリの問題はモデル層では解決できません。代わりにメモリエントリを確認してください。

4行目の「同じテストメッセージ」というフレーズが重要です：毎回異なる質問でモデルを比較すると、モデルの違いではなく質問の難易度を測定していることになります。

---

7. LightVelaのアプローチ：切り替えを低リスクの操作にする

Hermesはメカニズムレベルでレイヤー分離を実現しますが、モデルアクセスや環境の管理は依然としてオペレーターに委ねられています。LightVelaの方向性は、切り替えを日常的でリスクの低い、検証可能な操作にすることです：

• 1つのエージェントは一度に1つのアクティブモデルを持つ — 切り替えは選択を意味し、モデルごとに別のエージェントを用意する必要はありません。
• 資産は切り替え間でも安定 — メモリ、クラウドストレージのファイル、スキル、オートメーション設定は影響を受けず、チャット履歴も移動しません。
• 切り替えは検証可能 — コンソールにはアクティブモデルが表示され、テストメッセージ1つで成功を確認できます。
• 失敗は特定可能です — 診断では最近のログを保持し、モデル、構成、タスクの問題を分離します。
• 単一要因の変更が推奨されます — 一度に一つのことを変更し、すぐにテストすることが文書化された推奨事項です。

---

主なポイント

• モデル、ペルソナ、ユーザープロファイル、メモリ、スキルは五つの独立した層です；切り替えは最初の層だけを置き換えます。
• 文書化された挙動: 切り替えはメモリ、クラウドストレージ、スキル、オートメーションを消去せず、チャット履歴も移動しません。
• 「違う感じ」は、5つの表現レイヤーの違いに由来します：指示の遵守、文脈の圧縮、冗長さ、ツール呼び出しの傾向、言語スタイル。
• 実際の記憶喪失を判断するには一歩です：確実に知られている事実について尋ねます。
• オートメーションには固定モデル欄はありません；切り替えた後は、その欄を探すのではなく、出力の品質を確認してください。
• トラブルシューティング中は、1つのルールを守ります：一度に1つの要素を変更し、すぐにテストすること。