共通コア上の人間とエージェント

Notariumの核心的な主張は、同じナレッジベースが人間にもAIエージェントにも等しく使えるということだ。人間はWebインターフェース(REST)を通じて、エージェントは組み込みのMCPエンドポイントを通じて作業し、両者は1つの可搬なコアの上で同じノートのグラフを見ている。これは脇に取って付けた「ボットモード」ではなく、設計思想としての機能パリティである。

1つのコア、複数のトランスポート

このアーキテクチャは1つの原則の上に成り立っている。ドメインロジックは1つのコアに宿り、トランスポートはそのコアへのアクセスを橋渡しするだけだ。

flowchart LR
  human([人間]) -->|REST · Webエディタ| core
  agent([AIエージェント]) -->|MCP · POST /mcp| core
  core[Notariumコア] --> files[(Markdownファイル)]

判断を下すのは常にコアであって、トランスポートではない。だから、エージェントが作成したノートは、エディタからの編集とまったく同じ道筋をたどる。同じ.mdファイルに書き込まれ、ログでバージョン管理され、同じアクセス権で境界を定められ、来歴が記録される。

「パリティ」の意味

エージェントの編集と人間の編集は、処理のされ方において区別がつかない。

• バージョン管理。 すべての編集はnotarium-idに紐づいた、ログ上のリビジョンになる。バージョン履歴を参照。
• スコープ。 エージェントのトークンが与える権限は、プリンシパルのメンバーシップを超えない。読み取り専用トークンからは書き込み系ツールそのものが見えない。アクセスモデルを参照。
• 来歴。 どのリビジョンにも、その編集がどこから来たのかが表示される。人間(user:<name>)、特定のエージェント(pat:<name>:<id>)、あるいは外部のファイルエディタ。誰が何をどう編集したのかは、常に透明だ。

エージェントの働き方

エージェントはPOST /mcpという単一のエンドポイントを通じてナレッジベースにアクセスする。それはストレージへの低レベルな操作ではなく、21個の既製コマンド(ノートを作る、コンテキストを思い出す、検索する、メモリを書き込む)からなる絞り込まれたセットだ。ツールは意図を表現し、配置とノートのクラスはシステムが強制する。エージェントはプロジェクトを名前で指定するが、スペースやノートのクラスは選ばない(誤りを防ぐガードレール)。

作業への典型的な入り口はstart_sessionの呼び出しだ。エージェントはプロフィール、自分のプロジェクト一覧、関連するコンテキストを受け取る。接続方法とツールの全容はエージェントとMCPで解説している。最初の実践的な一歩はエージェントを接続するだ。

意図的に引かれた境界

共通コアであっても、エージェントが何でもできるわけではない。

• エージェントに不可逆な削除はない。 上書きは可能だ(ログを通じて元に戻せる)。だが、コンテナの完全な削除はできない。
• スペースをまたぐ操作はない。 エージェントは、到達できるスペースの内側だけで厳密に作業する。
• ツールには外の世界へ通じるチャネルがなく、信頼できないコンテンツがツールの説明文に混ぜ込まれることも決してない。これによって「プライベートなデータ × 信頼できない入力 × 外部への出口」という連鎖が断ち切られる。
• Notariumは意図的にE2EE製品ではない。 検索・セマンティクス・エージェントを提供するには、賢いサーバーが内容を見る必要がある。プライバシーは、エンドツーエンド暗号化ではなく、セルフホストと自分のファイルを所有することによって担保される。

エージェントの防御境界を守る方法の詳細はセキュリティと可視性へ。