Parley

---

インストール

pip install parley-consensus              # zero-dependency core
pip install "parley-consensus[crypto]"    # + Ed25519-signed verdicts

配布パッケージ名は parley-consensus です（PyPI の parley は無関係のプロジェクトです）。インポート名は parley です。

from parley.agent import Agent
from parley.consensus import run_consensus
from parley.preferences import HardConstraint, PreferenceSheet

options = [
    {"venue": "rooftop", "cost": 900},
    {"venue": "garden", "cost": 600},
    {"venue": "diner", "cost": 300},
]
ana = PreferenceSheet(
    "Ana", utility=lambda o: 1.0 if o["venue"] == "rooftop" else 0.4)
# a red line: code, not a preference
bob = PreferenceSheet(
    "Bob",
    hard=[HardConstraint("budget", lambda o: o["cost"] <= 700)],
    utility=lambda o: 1 - o["cost"] / 1000)
cara = PreferenceSheet(
    "Cara", utility=lambda o: 0.9 if o["venue"] == "garden" else 0.5)

agents = [Agent(s.owner, s) for s in (ana, bob, cara)]
result = run_consensus(agents, options)
print(result.status, result.decision)
print("receipt sha256:", result.transcript.hash())
# each owner replays their own private sheet, locally
for sheet in (ana, bob, cara):
    ok = result.transcript.verify_non_betrayal(sheet, result.decision)
    print(sheet.owner, "not betrayed:", ok)

agreed {'venue': 'garden', 'cost': 600}
receipt sha256: 30483303e4d94e22833161d9bb8c292c0effff88c3303d7e195e57d49c88f516
Ana not betrayed: True
Bob not betrayed: True
Cara not betrayed: True

上記のハッシュは、バージョン 0.2.1 以降で出力されるものです。却下された選択肢のスコアは 0 と報告されます。同じスニペットでも、バージョン 0.2.0 では a9cb75c0... と出力されます。決定と判定結果は同じです。

屋上は Ana のお気に入りですが、結局選ばれません。Bob の予算に関する一線を越えるため、スコアを比較する前に却下されます。調整役が目にしたのは red-line だけで、予算も条件表も知りません。

貢献者は、クローンからインストールしてください。pip install -e ".[dev]"（ステータスを参照）。

MCP ホスト（Claude、Cursor）から使う

基本インストールには、stdio 経由で動作する標準ライブラリのみの MCP サーバーが含まれます。ホストから次のように指定してください。

{"mcpServers": {"parley": {"command": "parley-mcp"}}}

コンソールスクリプトがホストの PATH にない場合は、パッケージがインストールされたインタープリターを使って起動します。{"command": "python", "args": ["-m", "parley.mcp"]}。

このサーバーは MCP の両方の世代に対応しています。2026-07-28 リビジョン（initialize なし、各リクエストの _meta にバージョンと機能を記載、検出には server/discover を使用）のホストにはステートレスで応答し、2025-11-25 以前のホストには通常の initialize ハンドシェイクで応答します。どちらでも、ツールもレシートハッシュも同じです。 3 つのツールが表示されます。parley_decide（オプションと各当事者の譲れない条件・希望を入力し、 status、decision、transcript、transcript_sha256 を出力）、parley_verify_receipt （トランスクリプトのハッシュを再計算し、記録された判定から max-min の決定を再計算）、および parley_check_party （1 人の当事者の譲れない条件を決定に照らして再検証）です。parley_decide の返した内容を確認するには、 その transcript と transcript_sha256 を parley_verify_receipt に渡してください。scripts/verify-receipt.py が読み込むのは、examples/real_decision.py が書き込むレシートファイルであり、parley_decide の結果ではないため、後者を渡すと拒否されます。 入力は、examples/demo/ のレシピと同じ JSON で、1 つの spec キーの下に渡します。ホストを介さずに自分でツールを呼び出す場合、3 つの呼び出しは次のようになります（tools/call の arguments）。

{"name": "parley_decide",
 "arguments": {"spec": {"title": "...", "options": [...],
                        "parties": [...]}}}
{"name": "parley_verify_receipt",
 "arguments": {"transcript": {...},
               "sha256": "<transcript_sha256 from parley_decide>"}}
{"name": "parley_check_party",
 "arguments": {"party": {"owner": "Bob", "hard": [...],
                        "utility": [...]},
               "decision": {...}}}

parley_decide の結果は scripts/verify-receipt.py 用のレシートファイルではありません。parley_verify_receipt で確認してください。プロンプトの例：

私たち 3 人で会場を選んでいます。屋上（900）、庭園（600）、食堂（300）です。Bob は 700 を超える金額は出せません。Ana は屋上、Cara は庭園、Bob は最も安い場所を希望しています。parley_decide を使ってから、レシートのハッシュを検証し、Bob の譲れない条件が守られたことを確認してください。

このモードでできること、できないこと。 ホストはすべての当事者の仕様を保持し、1 回の呼び出しですべてを渡すため、当事者間にも、ホストに対してもプライバシーはありません。それでも、エンジンがコードで強制する内容は維持されます。譲れない条件に反するオプションは決定論的に拒否され、すべての当事者にとって実行可能なオプションの中から max-min ルールで選ばれ、レシートのハッシュによってトランスクリプトへの後からの変更が明らかになります。ただし、ハッシュはトランスクリプトを編集する可能性のある人以外が保持している必要があります。ハッシュには署名がなく、サーバーにも保存されないため、同じ人が用意したハッシュとトランスクリプトでは、相互に何も証明できません。max_min_verified はハッシュには依存せず、記録された判定から勝者を再計算します。プライベートなシートを使う場合は、所有者ごとに 1 つのプロセスを HTTP 経由で実行してください （examples/run_env.py）。その場合、コーディネーターに見えるのはマスクされた判定のみです。

---

2026 年のエージェント向けツールの多くは、トランスポート／ID（A2A、MCP）、1 対 1 のエージェント型商取引（エージェントがユーザーに代わって購入・予約する）、または同じ所有者のエージェント間の協調的な議論のいずれかを解決します。Parley が対象とするのは、製品化されていない空白領域です。すなわち、それぞれが異なる本人を代表し、利害が対立していて、かつ非公開の情報を持つ代表者たちが、全員が信頼できる決定に至り、自分たちのエージェントが裏切らなかったことを証明できるようにすることです。

対象ユーザー。 いずれの当事者の譲れない条件にも反しない決定に複数の当事者が合意する必要があり、各当事者が事後にそれを証明できるチームやプラットフォーム向けです。まずは規制対象の複数当事者ワークフロー向けに構築されました。コンプライアンスとオンボーディングの決定（KYC/AML、制裁に関する譲れない条件）、マーケットプレイスと P2P の紛争、委任型ガバナンス（委員会、パネル）が対象です。

差別化の軸は、LLM の判断に委ねず、コードで強制される 3 つの特性です。

1. 決定論的な譲れない条件。 各所有者の厳格な制約は、コードでチェックする述語です。これに反する提案は拒否され、交渉で覆されることはありません。「自分のエージェントは自分を裏切らない」が、単なる期待ではなく、証明可能な特性になります。
2. 利害の対立を考慮した合意形成。 コーディネーターに見えるのは、マスクされた判定、実行可能性フラグ、ソフトスコア、マスクされた理由（ok／red-line）のみです。プライベートなシートや、どの制約が問題になったかは見えません。決定はすべてのエージェントにとって実行可能でなければなりません。その中から、最も満足度の低い参加者の満足度を高める公平な max-min ルールで選び、同点の場合は社会的選択として総合的な福祉を基準に決定します。多数決ではありません。実行可能なオプションがない場合は、行き詰まりを率直に示します。
3. 検証可能なトランスクリプト。 すべてのマスクされた判定を記録した、改ざん検知可能な SHA-256 の記録です。各所有者は、シートを誰にも開示することなく、自分のプライベートなシートをローカルで再検証し、譲れない条件に反していないことを証明できます。

なぜこれが必要なのか（そして構築を通じて学んだこと）

エージェントが、予約、交渉、オンボーディング、割り当てなど、私たちに代わって行動し始めています。 2つのエージェントが異なる所有者に仕えるようになった瞬間、「自分のエージェントに裏切られたのではないか？」という疑念は、単なる取り越し苦労ではなく、現実的な問いになります。エージェントへの信頼に対する暗号資産の答え（ブロックチェーンに載せ、トークンを追加する）は89〜99.7％崩壊しました。長く残るニーズは、トークンから切り離された信頼の基本要素そのものです。

嘘をつけず、検証できるAI。 2026年のエージェント熱狂のサイクルによって、バイラルな広がりは真実から完全に切り離され得ることが証明されました。Parleyは、検証可能な形で実現します。Parleyでのすべての評決は再ハッシュ可能な証明記録であり、各所有者は自分だけの非公開シートを再実行して、越えてはならない一線が越えられていないことを証明できます。信頼は不要で、確認するだけです。

v0を構築して学んだのは、突破口となる領域は「マルチエージェントの合意形成」よりも狭く、明確だということです。価値は投票ではありません。投票は無料です（Snapshot、投票）。価値は、相反する非公開の利害のもとで、裏切りがなかったことを証明できることです。どの当事者も自分の非公開シートや、どの一線が問題となったかを明かす必要がなく、一線を取引で手放すこともできず、誰もが証明記録を自分で確認できます。これは既製の部品を組み合わせても実現できないことであり、LLMの善意に委ねず、コードで強制可能にした唯一のことです。実証例はこちらです：docs/dogfood-01-p2p-escrow.md。

近接するプロジェクトと、それらが提供しないもの

2026-10-25時点で、各プロジェクトが公開している説明をもとに記載しています。それぞれ異なる目的のツールであり、補完関係にあるものもあります。

近接するプロジェクト	提供するもの	Parleyが追加するもの
MPAC（arXiv、2026年4月）	独立したプリンシパルのエージェントが、共有状態を介して連携できるようにします。宣言された意図、構造化された対立、人間による仲裁を扱います	非公開の制約に基づく意思決定ルールです。一線をコード化し、マスクされた評決に対してmax-minを適用し、ローカルで再実行できます。MPACの概要では、非公開の選好、マスキング、検証可能なトランスクリプトについて説明されていません
Legal Context Protocol（American Arbitration Associationおよびパートナーが2026-06-24に公開）	エージェントが取引する際、法的条件、同意、紛争解決を発見可能かつ検証可能にします	紛争が起きる前の意思決定です。LCPは条件と救済手段を扱い、Parleyは選択肢のなかから選択に至ります。補完関係にあります
Acuerdio（スペイン）	オンライン調停プラットフォームです。「相手方」への招待から始まり、認証付き招待状とMASC証明書を当事者ごとの料金で提供します（同社サイトでは19 EUR）	非公開の制約を持つ3人以上の所有者と、それぞれが再計算できる記録です。ParleyはMASC証明書を発行せず、法的要件を満たすとも主張しません

ステータス：v0（コア機能が動作）

純粋な標準ライブラリによる、依存関係ゼロのコアです。プロセス内トランスポートを採用し、次にA2A（分散ディスカバリー＋署名付きAgent Cards）を差し込める明確な接続点を設けています。LLMで生成する選好シート（parley/elicit.py）と、Ed25519署名付きトランスクリプト（parley/net/identity.py、任意のcrypto extra）はすでに含まれています。このv0では、新規性のある部分である合意形成＋裏切り防止を意図的に切り分け、すでに一般化しているものは再利用していません。

python3 -m venv .venv && .venv/bin/pip install -e ".[dev]"
.venv/bin/pytest -q                     # the full suite, all green
# the money-shot: open http://127.0.0.1:8080 → Run
.venv/bin/python examples/demo/server.py
# three delegates pick a meeting slot
.venv/bin/python examples/meeting.py
# bots as separate processes, consensus over HTTP
.venv/bin/python examples/run_env.py
# run a real decision with real people, each one ratifies
.venv/bin/python examples/real_decision.py \
    --options examples/demo/recipe_committee.json

30秒で確認

examples/demo/server.py は、1つのウェブページを支える実際のエンジンを実行します。 対立する当事者、マックスミン方式の決定、赤い線でBLOCKEDになった選択肢、そして各当事者が個別に検証できる再ハッシュ可能なレシートが表示されます。 一連の手順を示した例として、P2Pエスクロー紛争を最初から最後まで扱い、当事者ごとの「こちらのほうがよい理由……」も記載したものが、docs/dogfood-01-p2p-escrow.md にあります（合成データです）。 実際の匿名化された紛争を題材に、テナントが「こちらのほうがよかった」とする結果を承認した早期賃貸借契約終了の振り返りリプレイは、docs/dogfood-02-early-lease-exit.md にあります（正直な適用範囲として、大家側の見解は推定であり、承認されていません）。 スクリーンショットをそのまま使った証明カードは examples/demo/proofcard_p2p.html です。

Python がなくても、Docker でデモを実行できます：

# then open http://127.0.0.1:8080
docker build -t parley . && docker run --rm -p 8080:8080 parley

ライブデモをお試しください：parleyprotocol.com/demo では、インストールも登録も不要で、1つのウェブページを支える実際のエンジンを実行できます。 セルフホストをご希望ですか？リポジトリには Dockerfile（および render.yaml Blueprint）が含まれているため、同じデモを任意の場所で1つのコマンドから実行できます。

エージェントのフリートが構築

このプロダクトが実現するのは、異なるオーナーに属するエージェント間の信頼です。 一方、プロダクトの開発を担ったのは、1人のオーナーが所有するエージェントのフリートです。エージェントたちは計画し、コードを書き、互いにレビューし、厳格なゲートを通してリリースします。人間が指揮を執り、公開やアウトリーチといった取り消せないゲートを担い、フリートがエンジニアリングを担当します。 すべての変更は、誰でも実行できる同じゲートを通過します。scripts/ship-gate.sh を実行し、テストをすべてパスさせ、依存関係ゼロのコアを維持し、サンプルを実行し、Conventional Commits の規律に従います。

セキュリティ（v0.1）

ネットワーク層は、明白な攻撃への対策が強化されています（tests/test_redteam.pyを参照してください）。

• 署名付き判定（Ed25519）。 各ボットは、特定の選択肢に対する判定に署名し、内容を鍵に結び付けます。その後、verify_transcript(require_signed=True)を実行すると、改ざんされた判定や、署名が期待されているのに署名なしで届いた判定が拒否されます。適用範囲（お読みください）： このチェックで証明できるのは、各署名が「そのレコードに含まれる公開鍵」と内部的に整合していることです。公開鍵が所有者の実際の鍵であるという真正性は、まだ証明できません。信頼できるowner → keyの対応表がないため、トランスクリプトを組み立てるコーディネーターが独自の鍵ペアに差し替えられる可能性があります。現時点で署名は、第三者が証明可能な本人確認ではなく、改ざんの検知として扱ってください。
• 認証＋レート制限＋入力検証。 ベアラートークンがない場合、/considerは401を返します。総当たりによる列挙は制限され（429）、サイズ超過または不正なリクエスト本文は拒否されます（413/400）。これにより、認証されていない攻撃者が以前はプローブを通じてボットの非公開の譲れない条件を再構成できた、選好抽出の脆弱性を塞いでいます。
• 結果の検証。 parley.consensusのverify_outcome(transcript)は、記録された判定から最大最小の勝者を再計算し、発表された決定と一致することを確認します。そのため、実行可能ではあっても最大最小ではない選択肢（または実行不可能な選択肢）を最終決定したコーディネーターを検出できます。非公開のシートは必要なく、誰でも公開記録を使って再検証できます。想定する所有者の一覧をexpected_owners=に渡してください。渡さない場合、すべてのエントリーから所有者を1人削除したコーディネーターも検証を通過します。（verify_non_betrayalで引き続き証明できるのは、あなた自身の譲れない条件が守られたことだけです。）

未対応（v0.1での制約。悪意ある参加者に対して本番環境で安全だとは見なさないでください）：

• 真正性のピン留め。 署名は自己申告された鍵に対して検証され、信頼できる対応表に対して検証されるわけではありません（上記参照）。各ボットの検出時に取得したAgent Cardの鍵に対して検証する、対応表をピン留めしたチェックはv0.2で対応予定です。現時点では、コーディネーター側だけが鍵をピン留めします。クライアントはカードの鍵に対応する署名があることを確認しますが、署名の有効性はverify_transcript(require_signed=True)で確認します。examples/run_env.pyではこの検証を実行するようになりましたが、それ以外の呼び出し元は自分で実行する必要があります。
• リプレイの紐付け。 判定にセッションやノンスが含まれないため、署名付き判定を、同じ選択肢を再利用する別の交渉にリプレイできます。
• 範囲を秘匿したスコア。 受理された選択肢すべてのソフトな基数スコアscoreがトランスクリプトで公開されるため、信頼できないコーディネーターが、それらの選択肢間での選好の順序を推測できます。また、acceptableフラグから各参加者の実行可能領域が分かります（拒否された選択肢のスコアは常に0です。理由と非公開のシートは隠されたままです。MPC／範囲秘匿は今後の課題です）。
• TLS/mTLS、およびゲーム理論上の共謀／戦略的な虚偽申告への耐性（研究トラック）。

ホスト型デモのparleyprotocol.comでは、基本的なトラフィック分析にGA4を使用しています。詳しくは収集されるデータをご覧ください。プロトコルとセルフホスト可能なdocker runの経路では、データを収集しません。

収益源はどこか（オープンコアの考え方）

コンセンサスメカニズム自体はコモディティです（投票／コンセンサスは無料で、Snapshotや投票機能があります）。価値と支払い意欲は、意思決定の重要度 × 関係者の数 × プライバシー／中立性／監査の必要性に応じて高まります。有料レイヤーはアルゴリズムではなく、信頼できる中立的な仲介役です。ホスト型のID／信頼レジストリ、監査対応の署名付きトランスクリプト、セルフホストのマネージド運用を提供します。最初の候補セグメントは、非公開の複数者間B2B交渉（調達／SOW）と、監査可能な委任型ガバナンス（委員会、審査会）です。Fetch.ai / Olas（実際に先行事例があり、レジャーとトークンを中心に構築されたエージェントプラットフォーム）との違いは、両者のページにはレッドラインやコンセンサスメカニズムの説明がなく、Olasはオンチェーンでトークンベースである点です。一方、Parleyは複数者間のグループコンセンサス、裏切りがないことの証明、暗号資産なし、セルフホストに対応しています。

デモでは、エージェントが非公開で相反する制約を持つ3人が、全員のレッドラインを満たす時間枠に合意し、それぞれの所有者が裏切りがなかったことを証明します。さらに2回目の実行では、無理に悪い決定をするのではなく、誠実なデッドロックに至る様子を示します。

アーキテクチャ

レイヤー	v0	次の段階
トランスポート／ディスカバリー／ID	プロセス内	A2A（署名付きAgent Cards、mDNS／レジストリ）、再利用し、作り直さない
エージェントの頭脳	純粋なコード、またはparley/elicit.py（LLMが草案を作成し、参加者が確認）	より幅広い情報引き出しUX
レッドラインの適用	parley/preferences.py（コードによる述語）	中核。決定論的なまま維持
コンセンサス	parley/consensus.py（最大最小）	ナッシュ交渉、重み付きルール
検証可能性	parley/transcript.py（ハッシュ＋ローカルでの再実行）、オプションのEd25519署名	範囲をマスクしたスコア（MPC）
敵対的状況	該当なし	ビザンチン耐性／共謀耐性。研究レベルの貢献

ロードマップ → オープンコア

• 現在： コンセンサスの中核＋レッドラインガード＋検証可能なトランスクリプト（このリポジトリ、Apache-2.0）。
• 次の段階： A2Aトランスポートにより、異なるマシン上のエージェントがLAN経由で互いを検出し、話し合えるようにします。 （LLMで引き出したシートとEd25519署名付きトランスクリプトは、すでに提供されています。）
• 研究： 嘘をつく／共謀するエージェントを投入し、最大最小法＋ビザンチン耐性のある集約がそれに耐えることを示します。これは、フロンティアR&Dにとって興味深い可能性がある部分です。
• 有料（セルフホスト）： LANの外でもエージェントが安全に出会えるホスト型リレー／信頼レジストリに加え、お客様所有のハードウェア上でのエージェントのマネージドホスティングを提供します。オープンソースの中核と、有料のフェデレーションです。

最初のICPは、1人の運用担当者がすべてのエージェントをデプロイする閉じたグループ（チーム／部署／家族）です。これにより、ネットワーク効果のコールドスタートを回避できます。「立場をエージェントに委ね、エージェントが共通の決定を見つける」という形は、まさにこれです。

貢献

中核部分は意図的に小さくしています。現時点で最も歓迎する貢献は、敵対的テストとコンセンサスプロトコルへのセカンドオピニオンです。CONTRIBUTING.mdから始めるか、再現手順を添えてバグを報告するか、ディスカッションを開始してください。型ヒント、テスト、CIチェックなど、1ファイルで完結する小さなタスクが6件、初めての方向けのIssueで公開されています。セキュリティ上の問題は、SECURITY.mdから非公開で報告してください。

スターの推移

Parleyの、裏切りがなかったことを証明するアプローチに興味があれば、スターを付けて他の人にも見つけてもらいやすくしてください。

ライセンス

Apache-2.0。特許の明示的な許諾を含む寛容なライセンスです（企業の法務審査にも対応）。LICENSEとNOTICEをご覧ください。