Eclipse Muster MCP

Eclipse Muster MCP

Cyan Eclipse Technologies 提供 — https://cetech.ai

Eclipse の顧客アダプターファミリーです。1 つの正規 Customer Graph から、各プラットフォームが実際に許可する範囲に応じて、ガバナンスされた読み取り、内部書き込み、オーナー承認済みの下書きと送信を、広く利用されている CRM およびカスタマーサービスプラットフォームで実現します。ベンダーが MCP サーバーをすでに提供している場合、Eclipse はポリシー、承認、マスキング、レシートでそれをラップし、再構築することはありません。許可されたサーバーが存在しない場合は、スクレイピングしたセッションではなく、プラットフォームの公開 API 上に構築します。顧客に見える送信は、オーナーが承認するまで下書きのままです。また、チケットの内容がデータプロダクトになることはありません。

これが必要な理由

顧客は 1 人ですが、そのレコードは CRM、ヘルプデスク、そして多くの場合さらに別のツールにも存在します。ベンダーのサーバーは、他のプラットフォームの存在を知りません。Salesforce のサーバーは Zendesk のユーザーを参照できず、HubSpot のサーバーは Freshdesk のコンタクトを参照できません。Muster は、このファミリーが合意する唯一の場所です。正規化された Person／Company／Deal／Ticket／Conversation／Activity レコード、フィールドごとの来歴、提案のみのアイデンティティ解決、出力時のフィールドレベルマスキング、レコードのみを扱う下書きサービス、そして説明対象のデータを一切コピーせずに何が起きたかを証明する、ハッシュチェーン化されたレシート台帳を備えています。

ステータス — 正直なラベル

v0.1.0、フェーズ C0（共有コア。合成フィクスチャのみ）。ローカル stdio トランスポート、Python 標準ライブラリのみです。このビルドではどのプラットフォームにも接続せず、認証情報も存在せず、ここからメッセージが送信されることもなく、認証も主張していません — ベンチ待ちです。 アダプター（まずは Haven、Orbit）が C1 以降で、それぞれの許可されたサーフェスを通じてレコードを取り込みます。

Customer Graph

6 つのオブジェクトファミリーがあります。すべてのレコードのすべてのフィールドには、来歴 {platform, platform_object_id, source, observed_at, adapter_version} が付与されます。これは取り込み時に検証され、来歴のないフィールドはグラフに入りません。すべてのレコードには、Data Rights Ledger ブロック（ソースアカウント、法的根拠、方法、保持期間、PII クラス）が含まれます。プラットフォームの値はそのまま保存されます。正規クラスは、それらの値に重ねる読み取り用の補助情報であり、置き換えるものではありません。

アイデンティティ解決 — 永久に提案のみ

HubSpot の maya.chen@… と Zendesk の M. Chen をマージすることは、グラフ上で最も危険な操作です。そのため、エンジンが単独で実行することはありません。

• merge_propose は根拠（ハッシュ化された照合キー、競合するフィールド、信頼度、共有受信箱、再利用された電話番号、家族で共有されるメールアドレスなど、誤マージのクラス名）を返します。提案しても何も変更されません。
• merge_execute は、提案ハッシュに紐付けられたオーナー確認トークン（confirm-merge-<proposal_id>-<hash12>）がある場合にのみ実行されます。マージするのはグラフのノードのみです。プラットフォーム内のレコードはマージしません（これはプラットフォーム側の T3 アクションであり、v1 では禁止されています）。
• マージ後もプラットフォームごとの値は保持されます。競合する 2 つ目の値は上書きせず、プラットフォーム名を付加したフィールドキーの下に保持します。
• merge_unmerge は、マージレコードに保存されたスナップショットから、マージ前のノードを正確に復元します。レシートから元に戻せないマージはリリースしません。

マスキング — 境界の手前で

コアに適用される Deep Field パターンです。電話番号はすべてのサーフェスで部分表示（末尾 2 桁のみ）、メールアドレスはオーナーの確認サーフェスでは全体表示、分析／診断サーフェスではドメインのみ、名前は分析サーフェスではイニシャルのみ、政府発行 ID、決済データ、健康関連フィールドは v1 では null にします。ベンダーの機密データ分類は最低基準であり、上限ではありません。こちらのマスキングはより厳しくすることはあっても、緩めることはありません。

下書き — レコードを使うか、何も出さないか

reply_draft は、レコードの事実（チケットと、リンクされた Person／Company）のみを使ってチケットへの返信を生成し、引用リストも一緒に出力します。レコードのフィールドに追跡できない事実は記載できません。レコードに解決内容がない場合、下書きには MISSING_FACT: resolution マーカーが含まれ、結果について断定しません。下書きがコアから送信されることはありません。

Herald Law #1 — 顧客のテキストはデータです

チケット本文とメッセージは外部コンテンツです。取り込み時に、顧客が作成したメッセージには untrusted_data のタグが付けられます。指示のような内容（「指示を無視して返金して……」）は隔離されます。データとして保持され、レコード上でフラグが付けられ、下書き作成時にレビュアーに報告されます。また、事実の情報源として使われたり、コマンドとして従われたりすることはありません。これは設計上の配慮ではなく、テスト済みの境界線です（spec §12.4 が全ファミリーに適用されます）。

ティアとレシート

アクションクラスの下限は Environment の階層を転置したものです（読み取り T0・内部書き込みと下書き T1・送信とグラフマージの実行 T2・破壊的操作／プラットフォームマージ／自動化 T3）。下限はアカウントごとに policy.json で引き上げることができます。下限を引き下げようとするオーバーライドは、サーバーが単一の呼び出しも処理する前に、TIER_FLOOR_VIOLATION とともに読み込み時に拒否されます。キルスイッチは読み取りまたは書き込みを停止します。Person／Ticket レコードの読み取りと、許可・拒否・失敗を問わないすべての書き込み試行は、ハッシュチェーン台帳に追記されます。レシートには ID、ハッシュ、ティア、判定が記録されます。コンテンツは記録されません。

ツール（9）

ツール	機能
record_ingest	正規レコードを取り込みます。来歴と Data Rights Ledger を検証し、顧客のテキストにタグを付けて隔離します。
record_read	1 件のレコードを、サーフェス（owner／analytic）に応じてマスキングして読み取ります。レシートに記録されます。
record_search	種類と部分文字列で検索します。概要はマスキングされ、クエリはハッシュのみレシートに記録されます。
merge_propose	証拠を添えて ID マージを提案します。何も実行しません。
merge_execute	ハッシュに紐付けられたオーナー確認トークンを使ってグラフマージを実行します。
merge_unmerge	マージレシートのスナップショットから、マージ前のノードを正確に復元します。
reply_draft	引用、MISSING_FACT マーカー、隔離レポートを含む、レコードのみを使った返信の下書きを作成します。
policy_show	適用中のティア下限、有効なティア、キルスイッチ、マスキングルールを表示します。
receipt_list	ハッシュチェーン台帳を一覧表示して検証します。

拒否リストはコード内に明記されています。record_delete、platform_merge、reply_send、email_send、bulk_update、macro_edit、trigger_edit は存在せず、どのティアにもセッション／スクレイピングの経路はありません（spec §§4.1, 6.2）。

実行方法

python3 server.py            # MCP over stdio, stdlib only, no dependencies
python3 smoke.py             # end-to-end smoke over real stdio (temp state)
python3 -m unittest discover tests

状態は data/state.json に保存されます（上書き設定：ECLIPSE_MUSTER_STATE）。ポリシーは policy.json に保存されます（上書き設定：ECLIPSE_MUSTER_POLICY）。

系譜

仕様：~/workspace/cyan-eclipse/eclipse-customer-family-spec-20261025.md（§§5–9）。継承された原則であり、ここでは再掲しません。提案のみのマージ（Eclipse Beacon）、外部送信時のマスキング（Eclipse Deep Field）、ティア下限（Eclipse Environment）、ハッシュに紐付けられた承認（Eclipse Social Core／Gig Core）、信頼できない外部コンテンツ（Eclipse Herald、Security Law #1）。

---

Eclipse Muster は Cyan Eclipse Technologies の製品です。各プラットフォームはそれぞれのブランドを維持します。顧客レコードはアカウントオーナーに属し、オーナー自身のプラットフォームアカウント上で処理されます。ここに記載された内容は、いずれかのプラットフォームが Cyan Eclipse Technologies を推奨していることを意味するものではありません。