LightVelaドキュメント

概要

A Hermes Agent のファイルは、ひとつの散らかったフォルダに入っているわけではありません。これらは異なる責任を持つ三つの場所に属します。作業ディレクトリには現在のタスクの入力、出力、ツールの実行が格納されており、実際の境界があります — ツールはワークスペースを越えて任意のシステムパスに移動することはできません。コンテキストファイル（SOUL.md、USER.md、MEMORY.md）は普通の添付ファイルではなく、エージェントが関係性と作業を理解する方法に影響を与える長期的な合意です。クラウドストレージはタスクの資料と出力のためのエージェントのファイル作業領域です：単一ファイルのアップロードおよびダウンロードは最大1 GBまでサポートされ、削除はそのエージェントのクラウドストレージにあるホストされたコピーのみを削除し、元の場所のファイルには一切触れません。あなたのコンピュータ上では、あるエージェントのファイルが自動的に別のエージェントで利用可能になることはありません。三者を分離する実用的な価値は、常にドキュメントがどこに存在するか、誰がそれを読むことができるか、どれくらいの期間保持されるかを把握できることです。これにより、秘密情報が長期的な文脈に混入することを防ぎ、重要な資料が一つのチャットログ内にしか存在しない状態を避けることができます。

---

ファイルがどこに存在するかが、エージェントが作業を中断した地点から再開できるかを決めます

よくある失敗を想像してください。プロジェクト概要をチャットに貼り付け、エージェントに重要なポイントを抽出させると、ちゃんとした結果が得られます。3日後に戻ってきて「その概要に基づいてスケジュールを作って」と依頼します。しかし作られたスケジュールは明らかに合致していません — なぜなら、その概要は3日前の会話の中にしか存在せず、信頼して取り出せる場所に保存されていなかったからです。

次に、二つ目の失敗を想像してください。エージェントがあなたのサーバー設定を「覚えておく」手助けをするために、あなたは秘密鍵を含む設定ブロックを長期的なコンテキストファイルに書き込みました。それ以降、そのブロックはすべてのセッションでバックグラウンドとして読み込まれます。これはメモリの意図された使用方法ではなく、不要な長期的な機密データの露出です。

どちらも同じ問題を指しています：ファイルがどこに存在するかは整理の好みではありません。それは、資料が確実に取得できるか、誰がそれを読むか、どれくらいの期間保持されるかを決定します。 この記事では、三つの場所とそれぞれの境界について説明します。

---

1. 三つの場所、三つの責任

全体像から始めましょう。

最もよく混同されるペアはコンテキストファイルとクラウドストレージです。どちらも保持されますが、読み込まれる方法はまったく異なります：コンテキストファイルはすべてのセッションの常駐バックグラウンドであり、クラウドストレージファイルは必要に応じて取得され、すべての会話に自動的に注入されることはありません。

この区別が、機密情報の取り扱い方法を直接決定します — 以下で説明します。

---

2. 作業ディレクトリ：作業が行われる場所、そして境界がある場所

作業ディレクトリは、現在のタスクの入力、出力、およびツールの実行を提供します。それには二つの定義的な特性があります。

第一に、それは作業現場です。 ファイルの読み取り、ファイルの書き込み、コマンドの実行、アーティファクトの生成はすべてここで行われます。本当に作業を続けることができるエージェントは、毎回最初から始めるのではなく、中間状態をここに保持する必要があります。

第二に、明確な境界があります。 ツールは作業スペースを越えて任意のシステムパスにアクセスすることはできません。その制限は能力の欠如ではなく、ファイル読み取り/writeを使いやすく、かつ制御可能にするための前提条件です。全ファイルシステムにわたって制限なしに読み取り/writeができるエージェントは、単一の判断ミスでも取り返しのつかない結果につながる可能性があります。

この境界を理解することには実践的な意味があります：エージェントにドキュメントを処理させたい場合は、任意のディレクトリを探させるのではなく、エージェントがアクセスできる場所にドキュメントを置いてください。

---

3. コンテキストファイル：添付ファイルではなく、長期契約

これら三つのファイルはしばしば「エージェントにアップロードした資料」と間違えられます。これらの役割はまったく異なり、エージェントがこの関係やこの仕事を理解する方法を決定します。

アップロードされた資料と異なる三つの方法：

相違点1：読み取りのタイミング。 コンテキストファイルは各セッションで使用される常駐背景です；クラウドストレージのファイルは必要な時にのみ取得されます。

相違点2：内容の形。 コンテキストファイルは安定したルール、好み、事実のエントリに適しており、大量の生データには向いていません。10ページの概要をMEMORY.mdに入れると、それ以降のすべてのセッションで負担になります。

違いその3：機密性の要件。 これらは常駐しているため、パスワード、キー、または不要な機密情報を長期コンテキストファイルに書き込まないでください。 エージェントが機密性の高い設定を扱う必要がある場合は、制御された経路を通じて提供し、その後は背景に残さずにクリーンアップしてください。

この3つ目のポイントは、本記事の中で最も重要な実務上のルールです。

3つのコンテキストファイルが共にどのように振る舞いを形成するかについては、"Hermes Agentの人格はどこから来るのか: ペルソナ、好み、長期記憶"を参照してください。

---

4. クラウドストレージ：エージェントのファイルワークスペース

クラウドストレージはエージェントのファイルワークスペースとして位置づけられています：タスクの資料を一箇所に保管し、ファイルをアップロード・整理したり、必要に応じてローカルにダウンロードしたりできます — すべてコンソールから操作可能です。

4.1 使用するタイミング

エージェントが参照資料や作業用ドキュメント、または出力を保存する明確な場所を必要とする場合には、クラウドストレージを使用してください — チャットに一度だけ貼り付けるのに頼る代わりに。典型的な2つのパターンがあります：

• 先にアップロードしてから処理 — プロジェクトの概要をアップロードし、その後でエージェントに重要なポイントを抽出させます。資料は後で参照できるように保持されます。
• 繰り返し作業用のフォルダを作成 — 継続的な作業にはフォルダを与え、それを維持することで、出力物に安定した保存場所を確保します。

4.2 知っておくと良い具体的な制限

これらは、信頼して使用する前に確認すべき事実です:

• 単一ファイルのアップロードとダウンロードは最大1 GBまでサポートされています。 それ以上のサイズは、事前に分割または圧縮する必要があります。
• 削除は、そのエージェントのクラウドストレージにあるホストされたコピーのみを削除します。コンピュータ上の元のファイルは決して削除されません。それでも、削除前に必要なものをすべてダウンロードしてください — ホストされたコピーは一度削除されると戻りません。
• あるエージェントのファイルは、他のエージェントで自動的に利用可能にはなりません。 エージェント間で資料を移動するには明示的な操作が必要です。共有ファイル領域があると想定しないでください。
• アップロード中はページを開いたままにしてください。完了を待ち、現在のフォルダにファイルが表示されることを確認してから、他の操作を行ってください。

4.3 フォルダ構造は複雑である必要はありません

実用的な推奨事項：複雑な階層は通常必要ありません。3つのフォルダ ― material、in progress、done ― でほとんどの状況を扱えます。本当に検索の速さが向上する場合にのみ階層を深くしてください。

構造が健全かどうかを判断するひとつのテスト：フォルダ名は素材がどのタスクに属するかを明確に示しているか？ 中身を思い出すためにフォルダを開けなければならない場合、名前は失敗しており、Agentもその同じ名前を頼りに素材の用途を判断します。

---

5. この文書はどこに置くべきか？意思決定の道筋

特定の文書に直面したときは、順番にこれらの質問を検討してください。

質問1：それは規則ですか、好みですか、それとも事実の記録ですか？ はい → コンテキストファイル。規則はSOUL.mdに、好みはUSER.mdに、事実はMEMORY.mdに。元のソーステキストではなく、精選された結論を保存してください。

質問2：それは保持に値する素材や出力で、繰り返し参照される可能性がありますか？ はい → クラウドストレージ。目的を説明する名前を付けた適切なフォルダーにアップロードしてください。

質問3：それはこの1つのタスクのみに役立つものですか？ はい → 作業ディレクトリで処理してください；長期保存は不要です。

質問4: これにはパスワード、キー、または個人の機密情報が含まれていますか？ はい → 長期コンテキストファイルには入れないでください。 制御された経路で提供し、タスク終了時にクリーンアップしてください。

この経路の価値は、「どこにでも放置する」を合理的な選択に変えることにあります。日常的な摩擦の多くは、質問1と質問2を混同することから生じます — 大量の資料をコンテキストファイルに押し込む、または保持すべき資料をチャットログ内に残すことです。

---

6. 一般的な症状と確認する場所

最後の2行は同じ間違いの2つの側面を示しています：**コンテキストファイルをドキュメント倉庫として扱うこと。**テストは簡単です — もしあるコンテンツが毎回のセッションで読む必要がない場合、それはコンテキストファイルに属しません。

---

7. LightVelaのアプローチ：場所を可視化し制御可能にすること

Hermesは仕組みのレベルで作業ディレクトリとコンテキストファイルを区別していますが、資料のホスティングと取得は依然としてオペレーターによって管理されます。LightVelaの方針は、ファイル作業空間を可視化され、制御可能な製品機能にすることです：

• 統合されたファイルワークスペース — コンソールから製品を離れることなく、アップロード、作成、整理、ダウンロード、名前の変更、削除が可能です。
• 明確な境界 — 作業ディレクトリは限定されており、ツールはワークスペースを越えて任意のシステムパスにアクセスしません。
• 明確な削除の意味 — 削除はそのエージェントのストレージにあるホストコピーのみを削除し、ローカルの元ファイルはそのまま残り、先にダウンロードするように促されます。
• エージェント間の隔離 — エージェントごとに別々のファイル領域があり、共有されるべきでない場所に資料が漏れません。
• 他の機能から切り離されている — モデルを切り替えてもクラウドストレージ内のファイルは書き換えられません。

---

主なポイント

• 三つの場所、三つの役割：作業ディレクトリ（限定された作業場所）、コンテキストファイル（常駐する長期契約）、クラウドストレージ（必要に応じて取得される資料と出力）。
• コンテキストファイルとクラウドストレージは読み取りタイミングが異なります：前者はすべてのセッションで常駐、後者は必要に応じて利用されます。
• クラウドストレージの情報：1ファイルあたり1 GB/download のアップロード上限；削除するとホストされているコピーのみが削除されます；1つのエージェントのファイルは自動的に別のエージェントから利用できません。
• フォルダ構造はシンプルに保つ — material / in progress / done で十分なことが多く、用途がわかる名前をつける。
• 守るべきルールの一つ：パスワード、キー、または不要な機密情報を長期的なコンテキストファイルに書き込まないこと。
• セッションが重く感じたり遅くなった場合は、まず大量の資料がコンテキストファイルに追加されていないかを確認する。