Procheiron

Procheiron

レビューされていないメモリがエージェントに届くことはありません。
このメモリを書いたのは誰で、誰が確認したのか——そして、その後誰かが手を加えたのか？

Procheironは、AI エージェントのメモリ向けの、小さく依存関係のない信頼レイヤーです。メモリツールは保存や想起は得意ですが、信頼の管理を担う人は誰もいません。複数のエージェントでメモリを共有すると、どのエージェントでも「事実」を書き込み、他のエージェントがそれをもとに喜んで処理を進めてしまいます——誰もレビューせず、誰も承認せず、それが間違いだと判明しても、原因を追跡したり取り下げたりする確実な方法がありません。

Procheironはその規律を取り入れ、慣習ではなくバリデーターによって徹底します。独自のメモリエンジンは追加しません——埋め込みも、ランキングも、想起機能もありません。すでに使っているメモリをそのまま利用できます——ベクターデータベース、ナレッジグラフ、Markdownファイルのフォルダーなどです。Procheironはレコードを管理し、記憶を担うのは引き続きお使いのエンジンです。

現場を押さえる

デプロイメントの検証は問題なく完了します。その後、書き込み権限を持つ誰かがこっそり履歴を書き換えます——過去の昇進記録に、突然別の人物が関与したと記されます。

$ procheiron validate ./team-memory
Procheiron validation (full tier): PASS

$ # edit team-memory/memory/index/audit.jsonl:  "actor": "vera_curator" → "rogue_agent"

$ procheiron validate ./team-memory
Procheiron validation (full tier): FAIL
  ERROR: audit chain: audit event 0: entry_hash mismatch — content was altered
         after it was written
  ERROR: memories.jsonl:1: active record has no corroborating promotion audit
         event — forged/hand-flipped record

_{実際の出力（IDは短縮しています）。次の2つのセクションで、クローンは不要で、お使いのマシン上でまったく同じ検出を再現できます。}

インストール

pip install procheiron             # or: pipx install procheiron — see the note below
pip install "procheiron[crypto]"   # optional: ed25519 signing (the chain itself needs nothing)

_{pipxをお使いの場合：pipxはprocheironコマンドをPATHに追加しますが、システムのpython3からパッケージをインポートできるようにはしません。生成されたヘルパー（memory_propose.py、memory_promote.py、validate_minimal.py）にはパッケージが必要です。そのため、裸のpython3ではなく、procheiron initの完了時に表示されるインタープリターで実行してください。以下の手順はすべて、有効な環境で通常のpip installを実行していることを前提としています。}

コーディングエージェントをお使いですか？指示を1つ渡すだけで、Procheironをインストールし、MCP経由で自身を接続して、改ざんチェックを最初から最後まで実行します。

次の場所から手順を取得し、それに従ってください： https://raw.githubusercontent.com/logotheusneuro-cpu/procheiron-core/master/INSTALL_FOR_AGENTS.md

または、インストールせずに、チェックアウトしただけの状態から仕様を検証できます：python3 conformance/run_conformance.py。

自分で試してみる（60秒）

上のデモをお使いのマシンで実行してみましょう。共有領域を作成し、管理対象のメモリを1つ書き込み、その後履歴を書き換えて、チェーンが崩れるのを確認します。

procheiron init ./commons && cd commons

# 1. propose a memory as alice
python3 memory_propose.py --created-by alice --type decision --scope project \
    --subject "retry policy" --statement "Retries use exponential backoff." \
    --source-path docs/decisions.md --confidence 0.9

# 2. promote it — reviewed by someone who is NOT alice (self-review is refused)
python3 memory_promote.py --memory-id <id printed by step 1> --new-status active \
    --reviewer bob --authorized-by casey --reason "verified against the source" \
    --allow-unverified-reviewer

procheiron validate .        # PASS

# 3. rewrite history — swap the reviewer on the promotion event
sed -i.bak 's/bob/rogue/g' memory/index/audit.jsonl

procheiron validate .        # FAIL: entry_hash mismatch — content was altered
mv memory/index/audit.jsonl.bak memory/index/audit.jsonl    # put history back → PASS again

エージェントと連携

Procheiron には MCP サーバーが付属しているため、MCP に対応するエージェント（Claude Code、Claude Desktop、Cursor、 Codex など）は、人間と同じルールのもとで共有領域を読み書きできます。ツールは 4 つです：memory.search、memory.get、memory.propose、memory.promote。

Claude Code：

claude mcp add procheiron -- procheiron mcp --root ./commons

mcpServers 設定のあるもの（Cursor、Claude Desktop など）では、置き換えずにマージしてください：

{ "mcpServers": { "procheiron": { "command": "procheiron", "args": ["mcp", "--root", "./commons"] } } }

--allow-writes を渡すまでは書き込みはドライランとなり、MCP 経由の昇格にも他と同じ承認ゲートが適用されます。メモリを書き込んだエージェントは、そのメモリを承認できません。

このサーバーは2 世代に対応しています。現在の 2026-07-28 リビジョン（ステートレス、リクエストごとの _meta、server/discover）と、旧式の initialize ハンドシェイクの両方に対応しているため、クライアントが移行済みかどうかにかかわらず動作します。これは単に対応範囲が広いというだけではありません。ハンドシェイクがなく、それを手がかりにできないと、最新のリクエストに旧式のルールで応答してしまうことがありました。また、実際には「プロトコルを話せない」という意味なのに、メモリツールが「見つかりません」と返すと、本当に見つからなかった場合と区別できません。

仕組み

1. すべてのメモリはライフサイクルをたどります：draft → candidate → validated → active → superseded。

2. メモリが信頼できる active 状態になるのは、書き込んだ本人以外がレビューした後に限られます。 自己レビューは推奨されないのではなく、拒否されます：

   $ python3 memory_promote.py --memory-id mem_20260709_retry_policy… --new-status active \
         --reviewer alice --reason "looks right to me"
   memory_promote: REFUSED — self-review: 'alice' created this record (invalid transition §8.7)
   

3. すべてのステップは、ハッシュチェーンでつながれたエントリを持つ追記専用の監査ログに記録されます（BLAKE2b、標準ライブラリのみ）。過去のイベントを編集したり並べ替えたりすると、チェーンが破損します。末尾からの削除（末尾の切り詰め）は、チェーンだけでは検出できない唯一の編集です。--expect-head でヘッドを外部に固定すれば、これも検出できます（下記参照）。

4. 暗号学的に検証可能な作成者情報が必要ですか？暗号化用の追加パッケージをインストールし、ed25519 でエントリに署名してください。署名を検証できない場合はサイレントに成功扱いにせず、必ずエラーになります。

比較

エージェントのメモリに対する信頼を確保するために、ほかに考えられる方法：

	独立したレビューの強制	改ざんを検知できる履歴	任意のストアで利用可能	セットアップ
規約ドキュメント（「エージェントは〜するべき」）	いいえ — 規約を守るかどうかに依存	いいえ	—	不要
メモリファイルの Git 履歴	いいえ	はい — ただし履歴自体が書き換えられない場合	ストアではなくファイル	不要
メモリエンジンのメタデータ	いいえ — 自己申告	いいえ	そのエンジンのみ	不要
完全な来歴スタック（W3C PROV + 署名インフラ）	可能	はい	はい	自分で構築
Procheiron	はい — バリデーターが拒否 †	はい — ハッシュチェーンも使用。完全な書き換えには外部アンカーが必要	はい — 持ち込んだ任意のストアのレコードを管理	pip install；最も強い保証にはアンカーと鍵の管理が必要

_{† 自己レビューと編集・並べ替えによる改ざんを防止します。ファイルシステムへの書き込み権限を持つ内部関係者は、偽の昇格を追記することができます。これを防ぐには、鍵をその手の届かない場所に保管したうえで、オプションの署名用追加パッケージが必要です。改ざん検知と認証済みの来歴の違いについては、CLAIMS.md に正直に説明しています。}

Git も、Procheiron と同じ前提（誰もアンカーを書き換えない）のもとで、すでに改ざん検知を実現しています。違いは、レビューゲートを強制することと、Git にはないレコード単位の構造です。また、メモリエンジンは競合相手ではありません。Procheiron はそれらが保持するレコードを管理し、独自の検索機能を持つことはありません。

コマンド

コマンド	機能
procheiron init ./my-commons	ガバナンスを備えたメモリーコモンズを作成します。
procheiron validate <root>	デプロイメントを検証します。--expect-head <hex> と --expect-lint <fp> を追加すると、外部アンカーに対してチェーンのヘッドと適用プロファイルを固定できます。--json を指定すると、両方の現在値を出力します。
procheiron scorecard <root>	信頼ループの数値を表示します。レコード数、独立した昇格数、検出したブロック数です。
procheiron keygen --actor <id>	署名付きの著者情報に使う ed25519 キーペアを生成します（procheiron[crypto] が必要です）。秘密鍵は 0600 のファイルに、公開鍵は known_actor_keys 用に標準出力へ出力されます。
procheiron mcp --root <root>	MCP 経由でエージェントにコモンズを提供します（stdio JSON-RPC）。
procheiron conformance	適合性テストスイートを実行します（リポジトリのチェックアウトが必要です）。
procheiron version	バージョンを表示します。

監査ログでできること、できないこと

このログを信頼して使う前に、率直にお伝えします。

ハッシュチェーンにより、ログは改ざんを検知可能になります。チェーンを壊さずに履歴をこっそり編集することはできません。しかし、チェーンが証明するのはログの内部整合性だけです。ファイルへの書き込み権限がある人は、全体を一から再構築して検証を通すことができます。対策として、最新エントリーのハッシュをその人が変更できない場所（git コミットで十分です）にアンカーし、確認時に渡します：procheiron validate --expect-head <hex>。これで、全体を書き換えた場合も検知できます。

適用プロファイルにも同じ問題があります。管理対象と同じディレクトリにあるため、内部からダウングレードできます。同様に --expect-lint <fingerprint> でアンカーしてください。両方のアンカーは無条件に検証され、アンカー対象を削除すると検証がスキップされるのではなく失敗します。procheiron validate --json は現在の audit_head と lint_fingerprint を出力するため、固定する値を確認できます。

完全な脅威モデル — 署名、鍵、そして断固とした内部関係者

署名を使えば、さらにハードルを上げられます。暗号化用の追加機能と鍵レジストリ（known_actor_keys）を利用すると、登録済みアクターのすべてのイベントに、そのアクターの有効な署名が必須になります。署名を削除すると検証に失敗し、見逃されることはありません。

そして、残る正直な限界についてです。1 人の OS ユーザーがログ、鍵、そして鍵レジストリをすべて所有している場合、断固とした内部関係者は今でもすべてを書き換えて再署名できます。単一の共有マシンで得られるのは、外部アンカーによって検出可能な改ざんの証拠であり、改ざんの防止ではありません。その内部関係者を完全に阻止するには、ヘッドを外部にアンカーし、書き込み担当者の手が届かないところに鍵を保管する必要があります。別のユーザー、HSM、または鍵レス署名などが該当します。

もうひとつ、線引きしておくべきことがあります。これらすべてが証明するのは正しさではなく来歴です。ゲートが証明するのは、誰がレコードを書き、レビューしたか、そして誰も履歴を書き換えていないことです。内容が真実であることまでは保証できません。レビュー担当者が誤った事実を承認すれば、それは信頼済みになります。その場合に得られるのは、誤りをたどるための明確な記録と、置き換えて退役させるための経路であり、誤りの防止ではありません。

何が証明済みで何が単なる主張なのかを記録した台帳を CLAIMS.md に更新し続けており、各主張には根拠を記載しています。この README の内容がそのファイルと食い違う場合は、ファイルの内容が正しいものとしてください。

リポジトリの内容

パス	内容
spec/	v0.1 仕様書です。ガバナンス、メモリーコモンズ、コントロールプレーン、規範的な適合性 MUST リスト、および Core/Profile の境界を記載しています。
conformance/	正式なテスト一式です。generic-vault/ は架空の完全なデプロイメント（「Meridian Atelier」）、minimal-vault/ は最小構成の採用者です。失敗すべきネガティブフィクスチャも含みます。
src/procheiron/data/adopter/	採用者向けテンプレートです。procheiron init が新しいコモンズに書き込むものと、適合性テストで実行するものの完全なバイト列です。コピーは 1 つだけで、ミラーはありません。
init/	Procheiron を既存のプロジェクトに導入するための PORTING_GUIDE.md があります（procheiron init がスキャフォルダーです）。

設計上の選択

• 実行時依存関係ゼロ。 稼働中のデプロイで実行するものは、すべて標準ライブラリの Python です。 唯一のオプション追加要素は、ed25519 署名用の procheiron[crypto] です。ハッシュチェーン自体には 何も必要ありません。（jsonschema と opa は、開発／CI での相互チェックにのみ使用します。）
• デフォルトで改ざんを検知し、選択すれば署名可能。 chain.py と signing.py を参照してください。
• 移植可能なコアと、固有のプロファイル。 仕様は汎用のままにし、デプロイ固有のバインディング （ID、パス、権限階層）はプロファイルに置きます。spec/boundary.md を参照してください。
• 記憶の想起機能は一切ありません。 埋め込みと検索は、メモリエンジンの役割です。Procheiron が 競合する機能を追加することはありません。

ロードマップ

1. 2つ目の独立した実環境デプロイが適合性テストに合格すること — 「開発者の環境では動く」が「動く」に変わる節目です。
2. 人気のサードパーティ製メモリエンジンを Procheiron でエンドツーエンドに管理するリファレンスアダプター。
3. 本番環境向けの鍵管理ガイダンス — 別ユーザー、HSM、鍵なし署名のパターンを紹介し、単一マシンでも署名を確実に行えるようにします。

これまでのリリース：v0.1 では仕様、適合性テストスイート、CLI、スキャフォルダーを提供し、v0.2 では 改ざん検知可能なチェーンとオプションの署名を提供しました。

どこかで Procheiron を運用していますか？デプロイレポート を作成してください — 独立したデプロイは、文字どおりロードマップの最初の項目です。

FAQ

これはメモリエンジンですか？ いいえ。埋め込みも、ランキングも、想起のベンチマークもありません。今後も追加しません。 memory.search／memory.get ツールは、レコードに対するガバナンスフィルターです（ステータスとスコープに基づき、 デフォルトではレビュー済みレコードのみを返します）。コンテンツ検索ではありません。エンジンが保持するレコードを管理します。

悪意のある内部関係者を阻止できますか？ 検知はできます。防止できるのは、2つのことを行う場合に限られます — チェーンヘッドを内部関係者の手の届かない場所にアンカーし、署名鍵をその書き込み権限の範囲外に保つことです。 上のセクションで、その境界を正確に説明しています。

なぜ依存関係をゼロにしているのですか？ 信頼レイヤーが、依存関係ツリーを信頼するよう求めるべきではないからです。 稼働中のデプロイで実行するものは、すべて標準ライブラリの Python です。ハッシュチェーンも標準ライブラリのみで動作します。

自分の環境に適しているか、どうすれば分かりますか？ 2つの質問で判断できます。書き込みを行う主体は 独立して管理されていますか — 別々の人、チーム、またはプロセスですか？ それとも、1人の運用者がすべてのエージェントを実行しますか？ また、書き込み主体の手の届かない場所で、外部のヘッドアンカーと鍵管理を運用できますか？ どちらも「はい」なら、保証は全面的に適用されます。 どちらも「いいえ」なら、あなたの環境ではレビューゲートは強制というより慣習に近いものになります — 改ざん検知可能な監査証跡と、 自己レビューを確実に防ぐチェックは利用できますが、より強い保証はアーキテクチャに適用されません。

本番環境で利用できますか？ 私たち自身の基準では、まだです。適合性テストはフィクスチャーレベルで合格していますが、 「本番環境で再現可能」という主張は、私たち以外の誰かが運用する2つ目の実環境デプロイでスイートに合格するまで保留されます。 これがロードマップの最初の項目です。現時点ですでに役立つのは、単一チームのメモリーコモンズにおける改ざん検知可能な監査証跡と、 独立レビューの強制です — 上記の60秒デモで示しているとおりです。

使うのをやめたらどうなりますか？ pipx uninstall procheiron を実行すれば、すべてそのまま残ります。 コモンズはプレーンな JSONL と Markdown で、すべてのレコードと監査イベントを cat で読み取れます。エクスポートも、 ベンダーロックインもありません。

名前にはどんな意味がありますか？ Procheiron（πρόχειρον）はギリシャ語で「手近にあるもの」を意味し、歴史的には 実用的な法律の小冊子を指します。いつでも手の届く場所に置いておく小さなルール集にふさわしい名前です。

ライセンス

MIT — LICENSE を参照してください。