LightVelaドキュメント

概要

**Hermes Agentの「脳」は交換可能ですが、交換されるのはモデル層だけで、エージェント全体ではありません。モデル層は今回どう考えるかを決めます — リクエストの解析、ステップの計画、どのツールを呼び出すかの選択、そして答えの表現。エージェント層はその思考を時間をかけて維持します：アイデンティティ（SOUL.md）、ユーザープロファイル（USER.md）、セッション間の事実（MEMORY.mdおよびmemories/）、取得したメソッド（skills/）、メッセージングチャネル、自動化、作業ディレクトリはすべてモデルの外に存在します。だからこそモデルを切り替えてもそれらは削除されません。LightVelaでは、一つのエージェントは同時に正確に一つのアクティブモデルを使用し、モデルを切り替えてもメモリやクラウドストレージはクリアされません。ファイル、スキル、または自動化設定は変更されず、変更されるのは将来の応答の背後にあるエンジンだけです。エージェントが切り替え後に見知らぬ人のように感じる場合、その原因はほとんどの場合、新しいモデルでの指示の解釈、コンテキストの圧縮、および表現の挙動が異なることであり、記憶が失われたことではありません。

---

なぜこの質問が繰り返し出るのか

「エージェントをより強力なモデルに移行できますか？」は、エージェント製品に関して人々が最もよく尋ねる質問の一つです。その直後に続く質問は決まってこうです：「それでも私のことを覚えていますか？」

両方を一緒に尋ねることで、広く誤解されていることが明らかになります — それは、モデルとエージェントが同じものであるという誤解です。その心のモデルでは、エージェントとは単にLLMの周りにチャットインターフェースを包んだものにすぎず、モデルを置き換えるということはアシスタント全体を置き換えることを意味し、やり直すのは避けられないと感じられます。

もしそれが本当であれば、どのエージェントも長期的な価値を持つことはできません。先週説明したプロジェクトの文脈、慎重に調整したトーン、あなたが把握したワークフロー — それらすべてが、技術的なアップグレードのたびにリセットされることになります。それは誰も頼ることのできる製品ではありません。

Hermes Agent は逆の前提に基づいて構築されています：モデルは交換可能なコンポーネントであり、エージェントが持続するものです。 この記事では、それが実際に意味することを詳しく説明します。

---

1. まず三つのものを分ける：モデル、ランタイム、長期資産

モデルの切り替えについて議論する前に、エージェントは少なくともライフサイクルのまったく異なる三つの層を含んでいることを認識するのが有益です。

ほとんどの人は最初のレイヤーとチャットウィンドウしか見ておらず、その間にあるランタイムやその下のアセットレイヤーを見過ごしています。しかし、この二つの下位レイヤーこそが、エージェントが数か月の使用を経ても「同じもの」として認識される理由です。

便利な例えとしては、モデルは人の現在の思考方法、ランタイムはその人の体や手、長期アセットはその人のアイデンティティ、記憶、そして仕事上の習慣にあたります。誰かの考え方を変えても、その人のアイデンティティや記憶が変わらない限り、別人にはなりません。

---

2. モデルレイヤー: 「今回どう考えるか」に責任を持つ

単一のやり取りの中で、モデル層は単にテキストを生成する以上のことを行います。少なくとも次の4つのことを決定します：

1. 解釈 — あなたのメッセージを具体的な目標に変換すること。含意されているが明示されていない制約も含みます。
2. 計画 — 作業に必要なステップ数、何を先に行うか、行動の前に調査が必要かどうかを判断します。
3. ツール呼び出しの判断 — ファイルを読むか、ウェブを検索するか、コマンドを実行するか、またどの引数で行うかを決定します。
4. 表現 — 結果を読みやすい言語に整理すること。どの程度の詳細を含めるか、どの形式を使用するかも含む。

この4つはすべてこの推論パスに属します。それらはあなたの即時の体験に直接影響を与えるため、モデルを切り替えると感覚に顕著な変化が生じます。

同様に重要なのは、モデルレイヤーが持っていないことです：

• モデルはあなたのデータベースではありません。あなたの好み、プロジェクトの状態、過去の結論を保存することはありません。
• モデルはスケジューラーではありません。毎朝7時に何かを実行しなければならないという知識はありません。
• このモデルはチャンネルマネージャーではありません。どのTelegram会話に返信を返すかを決定することはありません。

これらすべての機能はモデルの外に存在します。これが「モデルを切り替えてもエージェントを切り替えているわけではない」という技術的根拠です。

---

3. エージェント層：思考の連続性を担う

エージェント層の責任は、解決する問題ごとに5つのカテゴリーに分かれます。

3.1 アイデンティティと行動ルール：SOUL.md

SOUL.md は、このエージェントが誰であるか、どのようなトーンで動作するか、何を優先するか、何をしないかを定義します。これは会話ごとに即興で変わるムードではなく、安定したルールのセットです。

モデルを切り替えた後も、SOUL.md はまったく同じ場所にあります。新しいモデルも同じルールを読み取り適用します — ルール自体は変わりませんが、ルールの適用がよりゆるくなることも、より厳密になることもあります。この違いこそ、後で出てくる「違った感じがする」セクションを理解する鍵です。

3.2 ユーザープロファイル: USER.md

USER.md は、あなたに関する安定した情報を保持します：言語の習慣、好ましいコミュニケーションのペース、普段使用しているツール、明示的に避けるべきことです。これにより、エージェントは毎回「長いバージョンにしますか、それとも短いバージョンにしますか？」と尋ねる必要がなくなります。

3.3 セッション間での事実: MEMORY.md と memories/

このレイヤーは、すでに起こった事実や結論で、保持する価値があると判断されたものを保存します：プロジェクトの名前、先週決定されたこと、パラメータがそのように設定されている理由などです。Hermesはこれらのエントリに対してSQLite + FTS5全文検索インデックスを構築し、関連する話題を取り上げたときに一致するものを呼び出します。履歴全体をコンテキストに詰め込むのではありません。

メモリは永遠に追記専用ではありません。これは原子操作add / replace / removeを通じて維持され、/memory pendingを介して確認することができます。完全な設計については、「なぜより多くのメモリが必ずしも良いわけではないのか：Hermes Agentがどのように長期メモリを選択、キュレーション、更新するか」を参照してください。

3.4 キャプチャされたメソッド: skills/

skills/ は「状況 X が発生したときはこれを行う」という標準手順を保存します。各 SKILL.md には通常、そのトリガー条件を宣言する YAML フロントマターが含まれています。これは手続き的記憶であり、宣言的記憶とは異なる経路です — 「記憶はスキルではない: Hermes Agent が事実記憶と手続き的記憶を分ける方法」を参照してください。

3.5 接続性とスケジューリング: チャンネル、自動化、作業ディレクトリ

• チャンネル は、エージェントがどの入口からメッセージを受信し、結果をどこに届けるかを決定します。
• 自動化 は、あなたが何も要求していないときにどの作業を実行するかを決定します。
• 作業ディレクトリ は、タスクの入力と出力が存在する場所、および境界がどこにあるかを決定します。

これらすべてはエージェント層の設定であり、現在どのモデルがアクティブであるかに依存しません。

---

4. 分離が必要な理由：4つの実際的な理由

モデルをエージェントから分離することはアーキテクチャ的純粋さの追求ではありません。具体的な利点を生み出します。

理由その一：モデルは個人資産が蓄積されるよりはるかに早く進化する。 意味のあるほど強力なモデルは数か月で導入される可能性がありますが、あなたの共有メモリ、嗜好、ワークフローはゆっくりと蓄積されます。もしこれら二つが結び付いていた場合、すべてのアップグレードはその蓄積を犠牲にすることになり、ユーザーは単純にアップグレードを拒否するでしょう。

理由その二：異なるタスクには異なるモデルが必要。 迅速なドラフト作成と重い推論は必ずしも同じモデルではありません。分離することで、各作業のために別のエージェントや別のメモリを維持する代わりに、タスクごとにモデルを切り替えることができます。

理由3：プロバイダーの利用可能性は決して保証されない。 プロバイダーがレート制限を行ったり、エラーが発生したり、ポリシーを変更した場合、すぐに別の設定済みモデルに切り替える必要があります。もしメモリがモデルに紐づいていたら、その切り替えは受け入れられないコストを伴うことになります。

理由4：所有権が明確になる。 メモリとスキルが独立したファイルやディレクトリに存在するため、これらは特定のモデルの付属品ではなく、あなたの資産となります。これこそが「自分自身のエージェントをトレーニングする」という表現がそもそも意味を持つ理由です。

---

5. LightVelaでモデルを切り替えたとき、実際に何が起こるか

上記のセクションではメカニズムについて説明しました。こちらでは実際の製品の動作について説明します。

1つのエージェントは一度に正確に1つのアクティブなモデルを使用します。 切り替えとは、どの設定済みモデルが現在アクティブであるかを選択することを意味します — 新しいエージェントを作成するわけではありません。複数のモデルを使用するために複数のエージェントを用意する必要はありません。

切り替えによってメモリ、クラウドストレージのファイル、スキル、または自動化設定は消去されません。 モデルの切り替えは、次回の応答に使用されるエンジンを変更するだけです。チャット履歴を移動したり、クラウドストレージ内のファイルを書き換えたり、スキルや自動化の設定を変更したりすることはありません。

切り替えの準備と確認、文書化されたフローに従って：

1. 対象のモデルがすでに設定されており、あなたのアカウントで利用可能であることを確認してください。まだ設定されていない場合は、まずモデルの設定を完了してください。
2. 新しいモデルが正常に応答するか確認するための短いテストメッセージを準備します。
3. 切り替え後、そのテストメッセージをチャットで送信し、エージェントが応答すること、またコンソールに選択したモデルが表示されていることを確認します。
4. 切り替え後の最初の応答が少し遅い場合は、短時間待ってからもう一度試し、それ以外を変更する前に確認します。

よくある誤解へのひとつの訂正: 自動化の設定は、名前、スケジュール（固定曜日、固定間隔、または一度限りのいずれかを選択）、タスクの指示、アクティブ時間帯、および通知チャネルで構成されます。「この自動化を特定のモデルに固定する」という項目はありません。 したがって、モデルを切り替えた後にすべての自動化を見直して再同期する必要があるというアドバイスは当てはまりません。切り替え後に確認すべきなのは、存在しないモデル項目ではなく、タスク出力の品質です。

---

6. その後「違うと感じる」理由

これは最もよく健忘症と誤診されるステップです。行動の変化とデータの喪失は異なる問題であり、それらを混同すると間違ったデバッグの道に進むことになります。

モデルは実際にこれらの次元で異なります:

テストは簡単です：確実に知っているべき事実について質問してください。 以前に特定のプロジェクト名や好みを伝えていた場合、切り替えた後に正確にそれについて質問してください。正しく答えた場合、メモリ層は intact（損なわれていない）状態であり、あなたが見ているのはスタイルの違いです。もし本当に答えられない場合は、メモリファイルとエントリがまだ存在するか確認してください。

実用的なルール：一度に一つの要素を変更し、変更後にテストすること。 モデルを切り替えたり、ペルソナを編集したり、スキルを追加したりを同時に行うと、どの層が問題を引き起こしたのか判断できなくなります。

---

7. モデルを切り替える価値がある場合

どのモデルが現在最強と呼ばれているかを追いかけるよりも、必要に応じて選ぶ方が役立ちます。

エージェントを切り替えた後に動作しない場合は、以下の順序でトラブルシューティングを行ってください：ターゲットモデルの認証情報とプロバイダー設定が完了していることを確認 → アカウントでモデルが利用可能で十分なクォータがあることを確認 → 作動することが確認されているモデルでテスト → それでも失敗する場合は、Diagnosticsの最近のログを確認。

---

8. LightVelaのアプローチ：モデルを選択肢として扱い、アセットはユーザーが保持

Hermesはメカニズムレベルでモデルとエージェントを分離していますが、Markdownファイルやローカル環境を直接管理することに慣れている人々を対象としています。LightVelaの方向性は、その分離をデフォルトの製品体験にすることです：

• モデルは切り替え可能な設定であり、セットアップ時に固定される一度きりの選択ではありません。
• メモリ、スキル、クラウドストレージ、および自動化はユーザー資産であり、モデルを切り替えても安定して維持されるため、アップグレードしても最初からやり直す必要はありません。
• 切り替えは確認可能です：コンソールにはアクティブなモデルが表示され、チャットでのテストメッセージ一つで切り替えが成功したか確認できます。
• 障害は追跡可能です：診断機能は最近のログを保持しており、問題がモデル、設定、またはタスク自体にあるかどうかを確認することができます。

その結果、モデルの進歩は直接あなたに届き、すでに蓄積したものがその進歩の代償になることはありません。

---

主なポイント

• エージェントには少なくとも3つの層があります：交換可能なモデル層、長時間稼働するランタイム、そして継続的に蓄積される長期資産です。
• モデル層は現在のターンの解釈、計画、ツール呼び出し、および表現を処理します。好みを保存したり、スケジュールを実行したり、チャンネルを管理したりすることはありません。
• SOUL.md、USER.md、MEMORY.md、memories/、skills/、および作業ディレクトリはすべてモデルの外に存在するため、モデルを切り替えてもそれらは一緒に移動しません。
• LightVelaでは、1つのエージェントが同時に1つのアクティブなモデルを持ちます。切り替えてもメモリ、クラウドストレージ、スキル、または自動化はクリアされません。
• 自動化には「固定モデル」設定がないため、モデルを切り替えた後に自動化モデルを再同期する必要があるという主張は正確ではありません。
• 切り替え後に違う感覚になるのは、通常、指示の実行、コンテキスト圧縮、表現の違いから来るものであり、失われたメモリによるものではありません。既知の事実で確認してください。