Particles

linkedparticles

linkedparticles.org · docs.linkedparticles.org · PyPI · Apache-2.0

Particles は、人間と AI エージェントのための共有メモリです。 各パーティクルはひとつの主張であり、それを評価するために必要な情報、つまり誰が、どこで、いつ述べたのか、またどの程度確信していたのかも含みます。事実、意見、記憶はすべて主張であり、パーティクルと同じ方法で記録されます。パーティクルは編集も削除もされません。パーティクルは、公開の場で置き換えられたり、撤回されたり、異議を唱えられたりします。どの程度信頼するかは、クエリ時に適用する視点であり、レコードにあらかじめ組み込まれることはありません。

linkedparticles は Particles リファレンス実装の エンジンです。信念ストアを実際に動かすためにインストールするパッケージです。ドキュメント、ページ、チャットログ、エージェント自身のセッションメモを渡すと、主張単位の信念が返されます。それぞれに、調整済みの確信度、不確実性の種類、解決された対象、そして正確なソースバイト列にまでたどれる来歴が付与されます。質問すると、その回答の根拠となった信念が引用されます。上書きされるものはないため、1年前にストアが何を信じていたのか、そしてなぜ信じなくなったのかを尋ねることができます。

エージェントが間違えたとき、理由を正確に把握し、情報源で修正できます。

エンジンは、まずライブラリとして設計されています。HTTP API、CLI、読み取り専用 MCP サーバー、常駐デーモンは、すべてその上に構築された インターフェースです。

インストール

pip install linkedparticles

Python 3.11 以上が必要です。ストアを持たないクライアント層の linkedparticles-core は自動的にインストールされます。

60秒で試す

export ANTHROPIC_API_KEY=sk-ant-...
particles db init

# Deposit a source (file, URL, or literal text) into the append-only corpus
particles deposit https://en.wikipedia.org/wiki/Pluto

# Extract claim-granularity beliefs with confidence, subjects, and provenance
particles extract --all-pending

# Ask in natural language; the answer cites the particles behind it
particles query "Why is Pluto not a planet?"

# Health-check the store: contradictions, staleness, orphaned links
particles lint

何も上書きされないため、ストアは自らの履歴を再生できます。--as-of は主張時点のレンズです。時刻 T にストアが何を信じていたのか、そして なぜ信じなくなったのかを回答するものであり、時刻 T に世界で何が真実だったかを 回答するものではありません：

particles query "How many planets are in the Solar System?" --as-of 2000-01-01
# → the belief as it stood then, and why it no longer stands: SUPERSEDED,
#   retired 2006-08-24, superseded by "Pluto is a dwarf planet."

信念の履歴は、フロントページでクリックして確認することもできます。順を追って進めるには、スタートガイド、 続いて指定時点へのタイムトラベルをご覧ください。

エージェントに組み込む

particles mcp serve                 # read-only MCP server (stdio), any MCP client
particles init claude-code          # session-start digest, session-end harvest
particles engine serve              # HTTP API, for a shared or remote engine
particles export obsidian ./vault   # also: anki, wiki, logseq, notion, graph, jsonl

リファレンスのメモリサーバーの代わりとしても使用でき、LangChain ではリトリーバーおよびツールセットとして組み込めます。Claude Code のメモリ、 リファレンスのメモリサーバーとの置き換え、 LangChain からの使用をご覧ください。

実際に機能するのか？

同じハーネスでフルコンテキストのオラクルとメモリなしの下限を対照条件として実行し、マルチセッションのエージェントメモリベンチマークである LongMemEval で測定しました：

	Recall@40	エンドツーエンド QA
Particles メモリ（同梱のデフォルト、top_k 40）	0.969	0.804
フルコンテキストのオラクル（ベースライン、n=148）	—	0.878
メモリなし（下限）	—	0.047

手法、質問タイプ別の内訳、比較対象のメモリ、予算を一致させた条件（Particles が 劣る条件も含む）は、記録用のレポート JSON とともにベンチマークページで公開しています。

セキュリティ態勢

メモリレイヤーは、入力を形作る攻撃対象領域です。単にデータを保持するだけでなく、エージェントが次に何を信じ、何をするかを形作るため、汚染された主張は遅延タイマー付きの指示となります。このコードを公開する前に、パッケージ全体を対象とした敵対的なアプリケーションセキュリティ監査を実施しました。対象は HTTP、CLI、MCP の各インターフェース、ファイルシステムへの書き込み処理、外部通信レイヤー、ビルドパイプラインです。監査結果は、原文のまま GO-WITH-FIXES で、**33 件の指摘（High 2 件、Medium 7 件、Low 20 件、Info 4 件）**でした。優先度の高い修正必須項目は翌日に統合され、最後に残った未解決の指摘は v1.128.0 で解消しました。

この対策で実現できたことと、できなかったことは次のとおりです。

• プロンプトインジェクションは封じ込めていますが、排除はしていません。 攻撃者が制御できるテキストを扱うすべての LLM 呼び出し箇所では、信頼できる指示をシステムターンに保持し、信頼できない内容を呼び出しごとに生成する 128 ビットのノンス付きデータフェンスで囲んでいます。さらに、パーサーで強制する JSON コントラクトや、生成された文章に含まれる引用 ID の有効性を確認するゲートなど、構造的な安全策も設けています。これにより、攻撃の難易度は大幅に上がります。これは強化策であり、免疫ではありません。
• モデルにツールを与えることはなく、モデルの出力を実行することもありません。 関数呼び出しはなく、モデルが出力した内容がシェルコマンド、SQL の断片、フェッチ処理になることもありません。インジェクションが引き起こせるのは、せいぜい主張を歪めることだけで、動作を引き起こすことはできません。
• 外部へのフェッチは、ホップごとに検証します。 ホストを解決し、アドレスをブロックリストと照合したうえで、検証済みのそのアドレスに接続します。リダイレクトのたびに再解決と再検証を行います。これにより、最初の名前解決だけでなく、DNS リバインディングやリダイレクトを利用した SSRF も防ぎます。サブプロセスとして実行される 2 つのフェッチも、このプロセスが検証したアドレスに固定することで、同じ保証を実現しています。
• 認証はフェイルクローズで、raw SQL は使用しません。 API は、実際のベアラーキーがない状態でループバック以外にバインドしようとすると起動を拒否し、トークンの比較には定時間比較を使用します。データレイヤーのすべてのクエリは、バインドパラメーターを用いた型付き ORM です。text()、文字列から組み立てた SQL、動的な ORDER BY は使用しません。
• デフォルトではローカル優先です。 ループバックへのバインド、ローカルの SQLite ファイル、テレメトリーの無効化、ネットワークサービスではなくローカルで起動する stdio の子プロセスとしての MCP サーバーを採用しています。デフォルトの設定で外部に送信される通信は、ユーザーが設定したものだけです。

残るリスクへの本質的な対策は、技術的なものではなく認識論的なものです。すべての粒子には出所情報が含まれ、ソースの信頼度は読み取り時の視点として適用されるため、信頼できないソースの内容を改変せずに重みを下げられます。また、lint / review を使えば、矛盾に対する判断を再利用可能な信頼ポリシーにできます。このストアは、どのソースが何を述べたかを、ソースへの信頼度に応じて重み付けした記録であり、絶対的な情報源ではありません。そのため、汚染されたソースも監査証跡を保ったまま確認し、重みを下げ、撤回できます。

これらの機能を頼りにする前にお読みいただきたい制限事項は、SECURITY.md に記載されています。認証なしでの読み取りが可能な範囲、登録した内容（秘密情報を含む）がそのまま保存されること、単一の運用者を前提とした信頼モデル、MCP の書き込み境界について説明しています。脆弱性の報告先も SECURITY.md に記載されています。報告は非公開でお願いします。

なぜ Particles なのか？

ほとんどの検索拡張生成システムは、クエリのたびに知識を一から導き直します。何を学習したのか、どの程度の確信を持っていたのか、どこから得たのかを記録に残さず、生のテキストチャンクを扱います。Particles は異なるアプローチを取ります。文章を検索するのではなく、引用や修正が可能な個別の主張（自然言語の文と、確信度、来歴、不確実性に関する構造化メタデータを組み合わせたもの）を保存することで、エージェントの知識をセッション間で失われることなく、監査可能な台帳として蓄積します。Core ではコーパスエントリーレベルの来歴が必須です。つまり、あらゆる信念を、それを生み出したソースまでたどれます。また、パーティクルストア自体は派生ビューであり、抽出器を再実行すればコーパスから再構築できるため、システムの耐久性と再現性の両方が確保されます。

Particles 標準では、パーティクルのスキーマ、ソースコーパスのモデル、抽出プロトコル、および一連の操作（登録、抽出、クエリ、リント、レビュー、再インデックス）を定義しています。これらが一体となって、エージェントの知識を一つずつ構築、検索、監査、修正するための基盤を形成します。このサイクルに取り組む開発者は、追記専用コーパスにソースを登録し、主語を解決した主張粒度のパーティクルを抽出し、実効確信度の順位付けに基づいてクエリを実行し、矛盾や古さをリントし、不整合を再利用可能な信頼ポリシーに反映します。パーティクルには確信度と来歴が明示されているため、Particles は、認識論的な位置付けが不透明なチャンクの順位付きリストを返すのではなく、対象に関する関連する主張を見つけ、来歴を保ったまま統合する必要があるクエリにも回答できます。

Particles は、主張粒度のエージェント知識を実現するための、最小限で相互運用可能な基盤です。RDF/SPARQL のような形式的オントロジーに基づくナレッジグラフよりも対象を絞り、拡張された Markdown よりも構造化されています。各パーティクルを主語に結び付けることで、この精度が実現します。Subject ストアは、この標準が定める実世界のエンティティのカタログであり、パーティクルのインデックス作成に用いられます。信念を正規のエンティティに対応付けることで、原理上、外部のオントロジーへのマッピングも可能になります。したがって、Particles を選ぶ開発者は、それぞれの信念がベクトル空間上の位置ではなく、ID、確信度スコア、ソース、主語を持つ第一級のオブジェクトとなる基盤を選ぶことになります。

設計の根拠

Particles の基盤となるのは、すでに記録されたものが上書きされることは決してないという保証です。Source Corpus は、パーティクルの抽出元となった、あるいは今後抽出元となり得るすべての資料を追記専用のアーカイブとして構成します。つまり、取り込まれたすべてのソースと、そこから導かれたすべての主張は、それ以前の内容を置き換えることなく、その場に蓄積されます。各パーティクルには作成時点からプロベナンスが付与されます。また、ソースを追記専用ではなく変更可能なモードで扱う必要がある場合も、システムは変更をひそかに取り込むことはありません。変更された領域にプロベナンス上の位置が含まれるパーティクルには PROVENANCE_STALE のフラグが付けられ、変更を隠すのではなく、目に見える形で示します。そのため、置き換えや撤回はプロベナンスグラフを通じて決定論的に伝播し、起点に影響を受けるすべての主張に及びます。これにより台帳は、何がいつ主張されたかを忠実に記録し、過去をひそかに書き換えたものになることはありません。

Particles における信頼性は、保存されたレコードに組み込まれた性質ではなく、読み取り時に適用される視点です。生の信頼度の値は不変のまま保存され、パーティクルの作成時に調整され、その後変更されることはありません。クエリごとに変化するのは有効信頼度であり、保存されるのではなくクエリ時に計算されます。信頼度の重み付け、経時的な減衰、および as-of 時点はすべて、レコードに書き戻されることなく、クエリ時に各閲覧者に応じて適用されます。つまり、ソースが古くなったり、生成した抽出器の信頼性が低下したりしても、ランキングを下げるために信念を撤回したり書き換えたりする必要はありません。保存されたパーティクルはそのまま保たれ、そのパーティクルに対して計算される有効信頼度が下がるため、基盤となる台帳に変更を加えずに、古くなった信念を自然に後退させられます。as_of に過去の時点 T を設定すると、クエリは世界時間上の有効性の次元ではなく、主張時点の軸（時点 T にストアが何を信じていたか）に沿ってストアを評価します。そのため、同じ不変のコーパスを使って、現在の信念と過去の信念に関する質問に曖昧さなく答えられます。

Particles では、矛盾は抑制すべき異常ではなく、ナレッジグラフの第一級の要素として扱われます。2 つのソースまたはプリンシパルの間で意見が異なる場合、競合解決の手順はどちらか一方をひそかに上書きするのではなく、確認用の INCONSISTENCY レコードを提示します。これにより、競合する両方の主張が台帳に保持され、後続のあらゆる利用者が不一致を把握できます。複数のパーティクルとの緊張関係を示す性質である競合状態は、読み取り時に計算する必要があり、保存されることはありません。有効信頼度と同様に、これは永続的な注釈ではなく読み取り時の視点です。つまり、新しいパーティクルが追加されたり、古いパーティクルが置き換えられたりするたびに、個々の主張の競合状態は、以前の時点で書き込まれた古いフラグではなく、グラフの現在の状態から常に新たに導出されます。

Particles のメモリは、定期的に自動実行される健全性管理によって維持されます。Lint 操作は、矛盾、古くなった主張、孤立したページ、相互参照の欠落について健全性チェックを実行し、定期的にコーパスをスキャンします。これにより、問題がひそかに信念ストアの品質を低下させるのではなく、目に見える検出事項として蓄積されます。何も上書きされず、矛盾も一方的に解消されるのではなく提示されるため、Lint は安定した基盤上で動作します。クエリが読み取るのと同じ不変のレコードをたどり、その検出事項を信頼ポリシーのレビューサイクルに反映することで、取り込み、クエリ、そして台帳の完全性を継続的に維持する取り組みの間に循環を作ります。

アーキテクチャ

Particles のデプロイメントは、ソースコーパスストアとパーティクルストアという、2 つの異なるストレージサブシステムを中心に構成されています。ソースコーパスストアは追記専用のオブジェクトストアで、ローカルファイルシステム、S3 互換バックエンド、またはコンテンツアドレス方式のストアに対応しています。一方、コーパスエントリーとスナップショットのメタデータは、リレーショナル形式またはドキュメントストア形式でクエリー可能な状態で保持されます。この 2 つのサブシステムが、すべての操作の基盤となる永続的な基盤を形成します。

Core SDK は、使いやすい Python API と CLI の両方を公開します。また、6 つのコア操作（Deposit、Extract、Query、Lint、Reindex、Review）はそれぞれ、参照 SDK の CLI サブコマンドと POST API エンドポイントに対応しています。そのため、開発者はすべての操作について、パイプラインに適したスクリプト可能なコマンドラインと、アプリケーション統合に適したプログラム用エンドポイントという、対称的な 2 つのインターフェースを利用できます。

未加工のソースからパーティクルの集合に至る流れは、Deposit でソースを追記専用コーパスに書き込み、Extract で抽出パイプラインを実行することから始まります。このパイプラインは、登録済みの抽出器のうち、適用仕様が登録されたソースに一致するものから、最も具体的な抽出器を選択します。ドメイン固有の抽出器が適用されない場合に限り、汎用抽出器が使用されます。パーティクルストアにパーティクルが格納されると、Query は有効信頼度の高い順にパーティクルを取得し、Lint は矛盾や陳腐化を確認し、Reindex は派生インデックスを再構築し、Review は不整合を再利用可能な信頼ポリシーに統合します。この一連の各ステップは、暗黙の副作用ではなく、個別の名前付き操作です。そのため、開発者は任意の段階を単独で呼び出し、入力と出力を個別に確認できます。

Why Particles?、Design rationale、Architecture の各セクションは、 手書きの文章ではなく、パーティクルストアから引用された投影です。 各マーク付きブロックは docs/projection/readme.yaml と、その隣にコミットされたコーパスバンドルから生成され、各ブロックの 下にある末尾部分には、元になった正確な主張が記されています。マニフェスト または基盤となるパーティクルを編集して再生成してください。センチネル間の文章は 編集しないでください。ご自身で確認するには、python scripts/projection_drift.py を 実行してください。このスクリプトは、一時ストアにバンドルを復元して決定的な レンダリングを再導出し、引用している主張とブロックにずれがある場合は失敗します。

これは、プロジェクト自身が自らの仕組みを実践している例です。README は、 来歴を伴う主張単位のナレッジを推奨しており、自身も同じ方法で組み立てられています。

ドキュメント

以下のすべてのドキュメントは、 docs.linkedparticles.org で公開されています。

ガイド	内容
ユーザーガイド	デポジット、抽出、クエリー、時点指定のタイムトラベル、エクスポート、エージェント統合
オペレーターガイド	設定、調整、lint と review、リモートエンジン、コンテナー、オブザーバビリティ、トラブルシューティング
プラグイン作成者向けガイド	抽出器、エクスポーター、ベンチマークスイートの作成
CLI リファレンス	すべての動詞とフラグ
HTTP API	OpenAPI コントラクト
ベンチマーク	LongMemEval の結果、手法、比較対象

標準そのもの（ホワイトペーパー、技術仕様、規範となるスキーマ、コンテキスト、 語彙の各アーティファクト）は linkedparticles.org にあります。

3つのリポジトリ

リポジトリ	内容
particles-standard	標準：ホワイトペーパー、技術仕様、規範的なスキーマと SHACL アーティファクト、適合性テスト用フィクスチャ
particles-core-py	Python クライアント層（linkedparticles-core）
particles-engine-py	このリポジトリ：Python エンジン層と各種インターフェース（linkedparticles）

デプロイ

コンテナおよびチャートのアーティファクトは deploy/ にあります。 エンジンは単一ライターサービスとして提供されます。詳しくは コンテナでの実行 をご覧ください。

コントリビュート

CONTRIBUTING.md および ARCHITECTURE.md をご覧ください。 コントリビュートは Developer Certificate of Origin への署名を条件に受け付けています。 CLA はありません。

ライセンス

Apache-2.0。LICENSE および NOTICE をご覧ください。