Notariumドキュメント
ドキュメントのバージョン: latest
日

エージェントのルール

MCPエンドポイントをつなぐのは、仕事の半分にすぎません。残りの半分は、「まずNotariumを見て」とあなたが言う前に、エージェントが自分からナレッジベースを起点にすることです。このページは、それを一度きりで仕込む話です。

つないだだけでは足りない理由

どのツールを呼ぶかを決めるのはモデルです。Notariumは自分の側でできることをすべてやっています。初期化時に instructions(「まず start_session を呼べ」)を渡し、ツール自身の説明にも、冪等で呼び直しても安全だとはっきり書いてあります。これで見込みはかなり上がりますが、保証ではありません — プロトコルの構造上、なりようがないのです。

保証はあなたの側、エージェントの常設ルールにあります。効いてくる違いは単純で、エージェントがプロジェクトのコンテキストからセッションを始めるか、あなたが毎回手で念を押し、やり取りがネイティブに感じられなくなるか、そのどちらかです。

呼ばなくても何も壊れない

start_session を飛ばしても作業は壊れません。ほかのツールはそれ単体で完結しますし、アクセスの境界を守るのはエージェントの規律ではなくトークンです。違うのはコンテキストだけ — エージェントはあなたのプロファイルも、変更差分も、合意済みカテゴリの辞書も見ないので、そのぶん重複を作ったり、独自の名前を付けたりしやすくなります。

どこに書くか

エージェントのクライアントには、たいていセッションごとに混ぜ込まれる常設ルールのファイルがあります。

クライアント通常の置き場所
Claude Codeリポジトリ直下の CLAUDE.md(加えてホームディレクトリのグローバル版)
Codexリポジトリ直下の AGENTS.md
Cursor.cursor/rules のプロジェクトルール
自作エージェントやAPI連携システムプロンプト

形式と正確なパスを決めるのはクライアント側で、私たちとは無関係に変わります。そのドキュメントで確認してください。Notariumはこのファイルに何も要求しません。あなたのエージェントが読む、ただのテキストです。

最小限のブロック

主要なシナリオは3つのルールで足ります。コンテキストから始める、重複を作らない、知識をあるべき場所に置く。

## Notarium — プロジェクトのナレッジベース

- 新しいセッションの冒頭で、MCPサーバー `notarium` の
  `start_session(project: "acme/website")` を呼ぶこと。プロファイル、
  利用可能なプロジェクト、このプロジェクトのインデックス、前回の訪問以降の
  変更差分、カテゴリの辞書がまとめて返る。
- **書く前に検索:** `search("<トピック>", project: "acme/website")` —
  検索は自分自身のメモリも対象なので、重複はここで拾える。
- プロジェクトに関する長期的な事実は `remember_about_project`、
  オーナーに関する事実は `remember_about_user`、共有される可視の知識は
  `create_note` で記録すること。

プロジェクトのハンドルは自分のものに置き換えてください。ふつうは space/project の形ですが、スペースのルートプロジェクトでは1セグメントに畳み込まれ、単に space になります。規則から組み立ててはいけません。出来合いの一覧は get_my_projects が返すので、そこから一字一句そのまま取ります。ルールファイルには正確な値をそのまま書き込んでおくほうがよく、そうすればエージェントが毎回探し直さずに済みます。

5回の呼び出しの代わりに1回

start_session はまさにこのために作られています。ほかのやり方なら探索的な呼び出しを何度も重ね、余計なコンテキストを食うところを、1リクエストで返します。冪等なので、コンテキストの圧縮後に呼び直しても安全で、副作用はありません。唯一繰り返されないのは変更差分です。デフォルトでは最初の呼び出しが「前回の訪問」のしおりを進めるため、2回目は空で返ってきます。しおりを動かさずに差分だけ覗きたいときは、acknowledge: false を付けて呼びます。

拡張ブロック: 正典の地図

特定のロールやタスクのときに読むべきノートがプロジェクトにあるなら、毎セッション探し直させるのではなく、地図を渡してください。数本のノートを名指しでロードするほうが、「プロジェクトを丸ごと読む」より安上がりです。

## Notarium

- 最初の呼び出しは `start_session(project: "acme/website")`。
- そのあとはプロジェクト全体を読まず、必要なノートを名指しでロードする:
  - 開発の規約 — `get_note("<id>")`;
  - レビューのチェックリスト — `get_note("<id>")`;
  - トピック周辺のコンテキスト — `recall("<トピック>", project: "acme/website")`。
- 書き込みの前には必ず `search("<トピック>", project: "acme/website")`。
- 作業ログとタスクの決定事項は、リポジトリのファイルではなく
  Notariumに残すこと。

ノートのidは安定しています。リネームや移動を越えて生き残るので、ナレッジベースを再編成しても地図が腐ることはありません。タイトルで張った [[...]] リンクも、リネームでは壊れません。古いタイトルはエイリアス履歴に移ります。

ルールの2つの層

指示は寿命で切り分けましょう。そうすればリポジトリごとに複製せずに済みます。

  • グローバル層(共通のルールファイル、またはシステムプロンプト) — いつでも成り立つこと。まず start_session を呼ぶ、書く前に検索する、オーナーに関する事実はどこへ書くか。プロジェクトのハンドルはここには置きません。
  • プロジェクト層(リポジトリ内のファイル) — その特定のプロジェクトのハンドル、正典の地図、ローカルな取り決め。

こうしておけば、新しいリポジトリをナレッジベースにつなぐのはハンドル1つを含む数行で済み、共通のルールは1か所にまとまります。

ルールに書くべきでないもの

エージェントのルールはセキュリティ機構ではない

ルールファイルはヒントであって、境界ではありません。エージェントに何ができるかを決めるのは、トークンの権限とツールセットです。読み取り専用トークンには書き込み系のツールが物理的に見えず、他人のスペースには原理的に手が届きません。トークンのスコープで押さえるべきところを、テキストで囲おうとしないでください — セキュリティと可視性を参照。

そこに紛れ込ませてはいけないものが、あと2つあります。

  • トークン。 ルールファイルはたいていgitに入ります。個人トークンは指示文ではなく、MCPクライアントの設定に書くものです。
  • ツールリファレンスの写し。 名前も説明も、エージェントには tools/list ですでに見えています。静的で、常に最新です。ルールファイルに複製すると、すぐ実態からずれていきます。ドキュメントのコピーではなく、意図と取り決めを書いてください。

コンテキストのキュレーションとの関係

1つの仕事の両輪で、どちらも互いの代わりにはなりません。

  • ルールファイルは、start_session の呼び出しが起きることを担保します。
  • Agents → Context セクションは、その呼び出しが何を持ち帰るかを決めます。常時ロードのピン留め、コンテキストセット、ノイズの多いメモリカテゴリのミュート — すべて共通のトークン予算の中で。

ですから、エージェントがコンテキストとともに始まっているのに、その中身が違うなら、直すのはルールファイルではなくコンテキストセットとピン留めです。

次へ