--- title: "コンテキストセットとピン留め" description: "start_session でエージェントに渡すものをキュレーションする。常時ロードのピン留め、スペースを横断して再利用できるコンテキストセット、メモリのミュート。" --- # コンテキストセットとピン留め エージェントが `start_session` を呼んだとき渡されるのは、ナレッジベース全体ではなく、あなたがキュレーションした起点のコンテキストです。**Agents → Context** は、その起点のコンテキストを組み立てるビルダーです。エージェントが起点で何を目にするかを、ここで過不足なく決めます。常にロードするノート(ピン留め)、スコープに紐づける再利用可能なまとまり(コンテキストセット)、そしてミュートするメモリのカテゴリです。タグによるピン留めとメモリのミュートはファイルファーストで、ノートのフロントマターに書かれるため、リポジトリをクローンし直しても失われません。一方、コンテキストセットとスペース横断のピン留めはメタデータデータベースに保存されます(これは承知のうえの但し書きで、まっさらなホストへのクローンし直しでも `none` モードでも、これらは残りません)。 ## 常時ロードのピン留め ピン留めは、手で付ける「常にロード」の印です(`always-load` タグに属しているかどうかであって、並び順ではありません)。ピン留めには2つの軸があります。 - **個人** — 個人ドメインにあるノートは `profile.alwaysLoad` に入り、**すべての**セッションでロードされます。 - **プロジェクト** — 印を付けたプロジェクトのサブツリーにあるノートは `project.alwaysLoad` に入り、エージェントが**そのプロジェクトで**作業しているとき(`project` ヒント)にロードされます。 ピン留めはノートの置き場所に紐づきます。個人ドメインのノートはプロファイルへ、プロジェクトのサブツリーにあるノートはそのプロジェクトのバンドルへピン留めされます。ビルダーが見せるのは、エージェントが実際にロードするものそのままです。サーバー側のキュレーションもプレビューも、同じコードを通っています。 ## コンテキストセット — スペースを横断するまとまり `always-load` タグでは、ピン留めは1つのスペースの中に閉じます。コンテキストセットはその制約を外します。コンテキストセットとは、**名前を付けて再利用できるノート参照のコレクション**で、別のスコープに紐づけられます。 よくある使い方はこうです。共有スペース `conventions` のノートから「フロントエンド規約」というセットを組み立て、別のスペースにあるプロジェクトへ紐づける。以降、それらのプロジェクトはセッションのたびにこのノート群を受け取り、あなたはセットを1か所で直すだけで済みます — どこでも同時に更新されます。 もっと軽い選択肢もあります。**スペース横断のルースピン**です。セットで包まず、別のスペースにあるノート1つをスコープへ直接ピン留めします。`always-load` タグは同一スペース内のピン留め用、セットとルースピンはスペース横断用、という住み分けです。三者は共存でき、重複は note-id で排除されます。 > [!note] 所有 ≥ 紐づけ > セットはホームとなるスペースに属し、そこでのメンバーシップが閲覧と編集の権限を付与します。個人セットを紐づけられるのは自分の個人ドメインだけです。共有スペース発の共有セットなら、個人ドメインにも任意のプロジェクトにも紐づけられます。個人セットをプロジェクトに紐づけることはできません — それではコンテキストがロードされるのはあなたにだけになってしまうからです。 ## 並び順 = ロードの優先度 一覧でのピン留めとセットの並び順は、自動で導かれるものではなく、あなたがドラッグ&ドロップで決めます。この並びがそのまま優先度になります。上にあるものほど先にロードされ、トークン予算に達したときに削られるのは最後です。ピン留めとセットは1本のランキングを共有するので、セットをピン留めより上に置くこともできます。全体のロード順は **ピン留め → セット → メモリ**(具体的なものが一般的なものに優先します)。そのうえで、あふれた分がスコープの予算に合わせて切り詰められます。 ## メモリのミュート(mute) エージェントのメモリは、既定でコンテキストにロードされます。あるカテゴリがノイズになっているなら、そのカテゴリだけを狙ってミュート(`mute`)します。ミュートすると、明示的なリクエストなしにメモリがエージェントへ届く経路から、そのメモリが一律で外れます。 - `start_session` の時点でロードされる個人プロファイル - `recall` のバンドル組み立て - `start_session(project).knownValues` のカテゴリ辞書 > [!important] Search がミュート済みのメモリを見るのは意図的 > `search` はミュート済みのメモリを**除外しません**。そもそもメモリをインデックスしているのは、「書く前に検索する」重複排除のためです。ここで隠してしまえば、エージェントはミュート済みのカテゴリを見つけられず、同じものを二重に作ってしまいます。ミュートは自動で入るコンテキストを黙らせるだけで、削除ではありません。明示的な検索と監査からは、これまでどおりすべてが見えます。元に戻すのは、同じ軸上の `Unmute` です。 ## 単一のトークン予算 ビルダーの各セクションの上には、ロード量のゲージが1本だけあり、現在のスコープの予算とぴったり一致します。個人向けの応答は1つの予算で動き(まずピン留め、次にメモリ)、プロジェクト向けの応答は独自の予算を持ちます。そこではプロジェクトのピン留めが先に来て、個人側の下地は残りの枠に収まります。ロードされる量は常に予算以下で、どこが切り詰められたかは項目ごとに見えます。プロジェクトのメモリは最初からロードされるのではなく、求められたときに引き出されます。特定のプロジェクトの事実が毎回必要なら、そのノートをピン留めしてください。 ## 次へ - [検索監査](/docs/agents/audit/) — 実行時におけるビルダーの双子。エージェントが実際に引き出すもの。 - [エージェントメモリ](/docs/agents/memory/) — あなたがミュートするメモリがどう組み立てられるか。 - [エージェントルール](/docs/agents/agent-files/) — もう半分の仕事。そもそも `start_session` を呼ばせること。 - [インテントツール](/docs/agents/intent-tools/) — `start_session` とその他のツール。