server-noonien - shared memory MCP

server-noonien

AI エージェント向けの、共有可能でサーバーレス、競合のないメモリ — ピアツーピア同期に対応。

server-noonien は、公式の @modelcontextprotocol/server-memory ナレッジグラフ（同じエンティティ、観察、関係）をそのまま置き換えるもので、中央サーバーもデータベースもマージ競合もなく、複数のマシン間で収束します。

主な機能はピアツーピア同期です。nooniend デーモンが各ノードのシャードを他のノードに直接複製するため、共有フォルダーを使わずに、複数のマシンで1つのメモリを共有できます。必要なのは、VPNまたはLAN経由でIPアドレスに到達できることだけです。

目次

• server-noonien を選ぶ理由
  • 課題
  • server-noonien の解決方法
• 比較
• 3つのコマンド
• マシン間で共有する
  • ピアツーピア — nooniend（推奨）
    • デーモン HTTP API
  • 共有領域 — file と s3
• 設定
  • 共通変数
  • サーバー変数
  • デーモン変数
• 仕組み
  • 圧縮
  • 削除と収集
• ツール
• そのまま置き換え可能な互換性
• セキュリティ
• 開発
• 名前が noonien である理由
• ドキュメント
• ライセンスと免責事項
  • プロジェクトを支援する

server-noonien を選ぶ理由

課題

現在、エージェントのメモリはローカルに保存されます。公式のメモリサーバーは単一の JSONL ファイルで、変更のたびにファイル全体を読み込んで書き直します。マシンが複数になると、すぐに問題が発生します。

• 1台のホスト上にしかありません。 マシンを切り替えると、エージェントはすべてを忘れてしまいます。
• 同期フォルダーで共有すると、書き込みが失われます。 サーバーは変更をプロセス内でのみ直列化します。2台のホストがそれぞれグラフ全体を読み込み、各自のコピーを変更して書き戻すため、後から書き込んだ側が、もう一方の変更をひそかに上書きします。さらに同期ツールはファイルをマージせず、競合コピーに分岐させます。
• 代替製品はサーバー、データベース、またはクラウドを必要とします。 主流の「共有メモリ」製品は、自分でホストする必要があるか、メモリをマシンの外部に送信します。

server-noonien による解決方法

server-noonien は共有ファイルと中央サーバーを根本から取り除き、ドロップインで使えるツールのインターフェースを維持します。

• 各ノードが独自のメモリを保持します。 各マシンは自身の追記専用シャード（<node>.jsonl）にのみ書き込みます。設計上、シャードへの書き込みは常に単一のノードが行うため、複数のノードが同じファイルに書き込むことはなく、noonien 自体がシャードを分岐させることもありません。ただし、共有エリアの同期ツールが分岐させることはあり、その場合の競合コピーも、統合対象となる別のシャードにすぎません。
• シャードは上書きせず、マージされます。 グラフは CRDT であり、(HLC, node, sequence) の順で並ぶ LWW-Element-Set です。マージは冪等、可換、結合的で、収束します。同じ操作を確認した2台のマシンは、順序にかかわらず同一のグラフを保持するため、「最後の書き込みを優先」によるデータ損失はありません。
• 共有エリアも中央サーバーも不要です。 シャードは nooniend デーモンを使ってマシン間で直接転送されます。必要なのは、VPN または LAN 経由の IP 到達性だけです。そのため、共有フォルダーもホストするサービスもなく、複数のマシンで1つのメモリを共有できます。すでに利用しているフォルダーやバケットを使いたい場合は、file と s3 も利用できます。転送方式は選択でき、特定の方式に縛られません。
• ローカルファーストで、オフラインでも使いやすい設計です。 各ノードは自身のシャードをディスク上で読み書きし、完全なローカルレプリカを保持するため、オフラインでも動作し続けます。ネットワークが復旧すると、メッシュは再び収束します。
• 公式サーバーとドロップインで置き換えられます。 ツール、入力、出力は同じ9種類なので、エージェントを変更せずに memory サーバー名で組み込めます。

比較

server-noonien と公式のメモリサーバー、ホスト型メモリサービスの比較：

	server-noonien	公式の server-memory	ホスト型メモリサービス
複数マシンでの利用	はい — ノードごとのシャードで1つのグラフを構成	いいえ — ローカルファイル1つ	はい — サービス経由
同期フォルダーの共有	安全 — 追記専用で競合なし	安全ではない — ファイル全体の読み取り・変更・書き込み	該当なし
サーバー／データベースが必要	いいえ	いいえ	はい
クラウドアカウントが必要	いいえ	いいえ	はい
オフラインでの動作	はい（file バックエンド）	はい	いいえ
ストレージ	フォルダーまたは S3 互換バケットを選択	JSONL ファイル1つ	サービス提供元のクラウド
公式ツールとのドロップイン互換性	はい — 同じ9種類のツール	—	いいえ
移行	noonien import memory.jsonl	—	エクスポート／インポートが必要
モデル	明示的なナレッジグラフ	明示的なナレッジグラフ	多くの場合、ベクトル型／セマンティック型
ライセンス	MPL-2.0	MIT	プロプライエタリ

ホスト型は製品ではなくカテゴリです。メモリをホストするサービスがこれに該当します。server-noonien はその対極にあるローカルファーストの方式です。ストレージは利用者自身が所有し、アカウントも不要です。

file／s3 バックエンドには共有エリアが必要です。すべてのノードからアクセスできるフォルダーまたはオブジェクトストアを用意する必要があります。nooniend を使えば、この要件は不要になり、シャードをノード間で直接複製できます。

3つのコマンド

1つの npm パッケージ server-noonien には、3つのコマンドが含まれています（Node.js ≥ 22）。一度インストールすれば、3つすべてが PATH に追加されます。

npm install -g server-noonien

コマンド	役割	実行方法
server-noonien	MCP メモリサーバー	短時間の実行で、stdio 経由でMCP クライアントが起動
noonien	メンテナンス用 CLI	1回限りの実行。手動で実行
nooniend	ピアツーピア複製デーモン	長時間実行。マシンごとに1つ

パッケージ名と一致するのは server-noonien だけなので、npx がパッケージ名で実行できるコマンドもこれだけです。他の2つは --package を使うか、上記のグローバルインストールから実行してください。

npx -y server-noonien                       # the MCP server (no argument serves over stdio)
npx -y -p server-noonien noonien help       # the maintenance CLI
npx -y -p server-noonien nooniend           # the replication daemon

クローンから実行する場合（開発用、またはまだ npm に公開されていないコードを実行する場合）：

git clone https://github.com/sequico/server-noonien.git
cd server-noonien && npm install && npm run build

node dist/index.js      # server-noonien — the MCP server
node dist/noonien.js   # noonien    — the maintenance CLI
node dist/gossip.js     # nooniend   — the replication daemon

server-noonien — MCP サーバー

すべての MCP クライアントが使用するエントリです。引数なし（または serve）で起動すると、stdio 経由で MCP を使用するため、自分で実行する必要はありません。クライアントが起動し、セッション中はそのまま動作します。

npx -y server-noonien                          # the stdio command the client runs
claude mcp add memory -- npx -y server-noonien # register it with Claude Code as the `memory` server

クライアントから接続してください。1 台のマシンではそのまま動作し、次のステップはマシン間での共有です。OpenCode（V2）では次のように設定します。

{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "servers": {
      "memory": {
        "type": "local",
        "command": ["npx", "-y", "server-noonien"],
        "environment": { "NOONIEN_DIR": "~/.noonien" }
      }
    }
  }
}

ほかのクライアントでは、同じコマンドと環境変数をそれぞれの形式でラップします。クローンから実行する場合、コマンドは ["node", "/path/to/server-noonien/dist/index.js"] です。ツールの構成は同一なので、memory サーバーのエントリを server-noonien に置き換えるだけで、ほかは変更する必要がありません。

noonien — メンテナンス CLI

コマンド	内容
noonien serve	stdio 経由で MCP メモリーサーバーを実行します（server-noonien と同じです）
noonien import <file>	公式の server-memory JSONL ファイルをインポートします（独自の <node>-import シャードに書き込むため、オンラインで動作します）
noonien export	統合されたナレッジグラフを JSON として出力します
noonien merge	すべてのシャードを統合し、統合後の状態を報告します
noonien compact	このノードのシャードをすぐにメンテナンスします。上書きされた操作を整理し、安全な場合に限りトゥームストーンを物理的に削除します。これはサーバーと同じルールです（NOONIEN_GC。ディレクトリを管理するデーモンがある場合は、全体のビューを保持し、シャードの管理はデーモンに任せます）。削除しない場合は、その理由も報告します
noonien query <text>	エンティティを検索し、一致するサブグラフを出力します
noonien help	コマンド一覧を表示します。noonien --version はバージョンを出力します

nooniend — デーモン

シャードディレクトリをピアツーピアで複製する、マシンごとに 1 つの長時間稼働サービスです。引数は不要で、環境変数だけで設定できます。共通の NOONIEN_DIR と NOONIEN_NODE_ID（共通変数）、およびデーモンの NOONIEND_*（デーモン変数）を使います。セットアップについてはピアツーピアを参照してください。

マシン間で共有する

noonien はシャードを統合しますが、それ自体でシャードを移動することはありません。マシン間でシャードを転送する方法は自由に選べます。ピアツーピア（推奨されるデフォルトの、付属デーモンを使用する方法）または、既存の共有領域（フォルダーやバケット）を使います。MCP サーバーは常に自身のローカルシャードを読み書きし、異なるのは転送方法だけです。

ピアツーピア — nooniend（推奨）

共有ストレージを使わずに、マシン間で 1 つのメモリーを共有するための推奨方法です。 nooniend は、ローカルのシャードディレクトリをピアツーピアで複製する長時間稼働のデーモンです。必要なのは IP 経由で到達できることだけなので、あらゆる VPN（WireGuard、Tailscale、OpenVPN、Netbird、ZeroTier など）や通常の LAN 上で実行できます。

各マシンに一意のノード ID を設定し、マシンごとに nooniend を 1 つ実行してください。各デーモンは、MCP サーバーが使うのと同じローカルディレクトリに、自身のシャードとともにほかのマシンのシャードの完全なレプリカを保持します。共有フォルダーは不要です。

# on a tailnet
NOONIEN_DIR=~/.noonien \
NOONIEND_TAILSCALE=true \
nooniend

# or, with no self-listing underlay, seed one reachable peer
NOONIEN_DIR=~/.noonien \
NOONIEND_PEERS=ai.example:27878 \
nooniend

ピアは互いを検出するため、マシンを列挙する必要はありません。検出元を1 つ設定してください。NOONIEND_TAILSCALE（tailscale status の出力）、NOONIEND_DNS_SRV（_nooniend._tcp SRV レコード）、または NOONIEND_PEERS（静的シード。1 つあれば十分で、以降はメンバーシップが自動的に伝播します）を使えます。検出元が返すのは候補であり、メンバーではありません。候補は /info に応答した場合にのみ参加するため、ネットワーク上にあっても nooniend を実行していないマシンが採用されることはありません。NOONIEND_ADVERTISE は任意で、デフォルトではリッスンホストが使われます。

動作の概要：

• オーサー操作は行いません。 各ノードの MCP サーバーは自身の <node>.jsonl のみを書き込みます。デーモンはピアのシャードのレプリカを保持し、自身がオーサーであるシャードのみをプッシュするため、シングルライターのルールが守られます。また、ローカルのシャードが遅れている場合は、ピアのレプリカから復元します。
• 変更時のプッシュと定期的なアンチエントロピー。 ローカルで変更があったとき（NOONIEND_PUSH）と、NOONIEND_INTERVAL 秒ごとに、シャードごとの高水位 seq を比較し、遅れている側へ差分を転送します。操作は冪等なので、ベストエフォートで配信できます。コンセンサスも順序保証もなく、最終的な完全性のみを保証します。
• フルメッシュを超えてスケールします。 デフォルトではすべてのピアに接続します。NOONIEND_FANOUT を設定すると、ラウンドごとにランダムなサブセットに制限できます。ただし、これはトゥームストーンの回収を除外します。ラウンドでサンプリングされなかった到達可能なピアが回収を保留させるため、デーモンはこの組み合わせを拒否します。また、NOONIEND_DIGEST_MIN_SHARDS 以上のシャードがある場合、シャード一覧全体の代わりに固定サイズのダイジェストで調整します（NOONIEND_CHANNELS を設定すると、メンバーシップは専用のチャネルに移されます）。小規模なメッシュではフルメッシュとまったく同じように動作し、ダイジェスト機能に対応していないピアには通常の一覧でフォールバックするため、異なる機能を持つピアが混在しても問題は起きません。
• リレー。 ノードは保持しているすべてのレプリカを提供するため、オフラインのノードも、そのシャードを持つ任意のピアを経由して同期し続けます。
• 検出とメンバーシップ。 ブートストラップアダプター（Tailscale、DNS SRV、静的シード）は候補を返し、その後、ピアセット自体がゴシップで伝播します。静的な node@host:port シードは明示的な指定であり、メンバーシップに直接追加されます。アドレスのみ（Tailscale または DNS-SRV の候補）は、/info に応答した場合にのみ参加し、その ID は応答から取得されます。検出元から取得することはありません。そのため、nooniend を実行していないデバイスがメンバーになることも、回収を妨げることもありません。起動したノードは次のプローブで追加され、検出元は NOONIEND_DISCOVER_INTERVAL 秒ごとに再読み込みされるため、再起動しなくても新しい参加ノードが見つかります。稼働状態は交換結果に基づいて判定されます。NOONIEND_SUSPECT_AFTER 回失敗すると疑わしい状態になり、NOONIEND_DEAD_AFTER の後に停止状態となり、NOONIEND_DEAD_RETRY の後に再試行され、NOONIEND_MEMBERSHIP_TTL の後に忘れられます。このノードに到達したピアは稼働中としてマークされます。mTLS を使用する場合は証明書に記載された名前、それ以外の場合はリクエストで通知された ID が使われます。そのため、復旧したピアは NOONIEND_DEAD_RETRY の時間が経過するのを待たず、ただちに再接続されます。このノードがまだ知らないピアは、リクエストで通知されたアドレスから追加されます（ゴシップで伝播されたエントリーと同様に信頼されておらず、次回の同期で確認されます）。そのため、静的シードを使う参加ノードは、接続したシードによって検出され、そのエントリーがほかのノードにも伝播します。ノード自身のエントリーが正として扱われ、異なるノードを提供するアドレスは破棄されます。
• ワイヤープロトコルとセキュリティ。 NOONIEND_LISTEN にバインドされた小規模な HTTP/JSON サービスです（ワイヤープロトコルの仕様全体は PROTOCOL.md を参照してください）。各シャードが受け入れるのは、そのノード自身の操作のみです。ピアごとの証明書を使った mTLS では、証明書のコモンネームがノード IDとなるため、ピアがプッシュできるのは自身がオーサーであるシャードのみです。一方、読み取りは認証済みの任意のピアに許可されるため、ノードがリレーできます。NOONIEND_REVOKED はすべてのルートで特定のノードからのアクセスを拒否します。NOONIEND_DEPARTED はさらに、離脱したノードのレプリカを破棄し、そのノードが残っていても回収を進められるようにします。
• 可観測性。 Prometheus メトリクスとして、稼働状態、ピアの健全性、安定ウォーターマークを確認できます。回収については、各ピアが不在だった時間（noonien_gossip_absent_seconds）と、固定された削除済み要素の数（noonien_gossip_frozen_elements）も確認できます。さらに、シャードごとの安定ウォーターマーク（接続可能なすべてのピアで到達した高水位の最小値であり、保守的な因果安定性の上限）と、プローブおよびオペレーター向けのステータスルートとグラフルートもあります。デーモンの HTTP API を参照してください。

systemd でのユーザーユニット：

[Unit]
Description=nooniend — peer-to-peer shard replication
After=network-online.target

[Service]
EnvironmentFile=%h/.config/noonien/nooniend.env
ExecStart=%h/.local/bin/nooniend
Restart=on-failure

[Install]
WantedBy=default.target

デーモンの HTTP API

nooniend は、NOONIEND_LISTEN（デフォルトは 0.0.0.0:27878）で小規模な HTTP/JSON API を提供します。ルートとペイロード、操作フォーマット、プロトコルのリビジョンと機能、サイズ制限、mTLS モデルなど、ワイヤープロトコルの仕様全体は PROTOCOL.md に記載されています。

curl -s http://127.0.0.1:27878/health
curl -s http://127.0.0.1:27878/status
curl -s http://127.0.0.1:27878/peers
curl -s http://127.0.0.1:27878/graph | jq '{entities: (.entities|length), relations: (.relations|length)}'

共有領域 — file と s3

file と s3 のバックエンドは、noonien の外部ですでに存在し、複製されている共有領域（すべてのノードがアクセスできるフォルダーまたはバケット）を介して連携します。すべてのノードを同じ領域に向けると、各ノードのシャードが相互に共有されます。

NOONIEN_BACKEND=file NOONIEN_DIR=/srv/noonien-shared NOONIEN_NODE_ID=ai server-noonien
# or
NOONIEN_BACKEND=s3 NOONIEN_S3_BUCKET=my-bucket NOONIEN_NODE_ID=ai server-noonien

• file — シャードは NOONIEN_DIR 内の *.jsonl ファイルです。Syncthing、Dropbox、git の作業ツリー、または共有マウントで複製されるフォルダーを指定します。
• s3 — シャードごとに 1 つのオブジェクトを使用し、競合時には条件付き書き込みを再試行します。@aws-sdk/client-s3 を使用します（オプションの依存関係で、選択された場合にのみ読み込まれます）。条件付き書き込みには、PutObject で If-Match／If-None-Match を遵守するストア（AWS S3、Cloudflare R2、MinIO など）が必要です。これらを無視するストアはサポートされていません。また、マルチパート ETag を持つシャードオブジェクトは、決して一致しないトークンで保護する代わりに拒否されます。オブジェクトストアには追記機能がないため、変更のたびにシャードオブジェクト全体を書き換えます（読み取り・変更・書き込み）。正しく動作しますが、書き込みごとに O（シャードサイズ）の処理が必要です。

memory バックエンドはプロセス内だけでシャードを保持します。テストや使い捨てのセッション向けです。変数については設定を参照してください。

共有領域でできないこと：安全な削除。 file／s3 はグラフを共有しますが、ピアがまだ配信していない書き込みを保持しているかどうかは判断できません。そのため、デーモンがない場合、メンテナンスではプルーニングのみを行い、物理削除は、オペレーターがこのノードだけが書き込むディレクトリとして指定した場所（NOONIEN_GC）でのみ発生します。削除と収集を参照してください。収束も同期ツールに委ねられます。noonien は検証も再送信も行わないため、遅延や競合コピーへの対処は同期ツールの責任であり、競合コピーは折り畳み対象となる別のシャードにすぎません。また、デーモンが複製するのはディレクトリです。NOONIEN_BACKEND=s3（または memory）では、サーバーが使用しないローカルフォルダーを複製することになるため、nooniend は起動を拒否します。

設定

すべての設定は環境変数から読み取られます。NOONIEN_DIR と NOONIEN_NODE_ID は共通ですが、それ以外の変数は MCP サーバー、CLI、デーモンでそれぞれ異なります。サーバーでは NOONIEN_*、デーモンでは NOONIEND_* を使用します。

共通変数

すべてのコマンドで使用します。

変数	デフォルト	意味
NOONIEN_NODE_ID	hostname	このノードのシャード名です。MCP サーバーが書き込み、デーモンが複製する際の識別子です。マシンごとに一意でなければならず、同時に書き込めるサーバーは 1 つだけです。
NOONIEN_DIR	~/.noonien	このマシンのシャードを格納するディレクトリです。file バックエンドのストアとデーモンのレプリカストアを兼ねます。先頭の ~ は展開されます。

この 2 つは共有領域ではなく、各マシン内にローカルで存在する設定です。MCP サーバーとデーモンは、同じホスト上の同じディレクトリを共有し、各マシンはすべてのシャードの独自のコピーを保持します。nooniend を使ったピアツーピア同期には共有フォルダーやバケットは不要です。共有領域は file／s3 の代替転送手段に限られます。

ノード ID は単一ライターのシャードです。一度に追記するサーバープロセスは 1 つだけにしてください。通常は、マシンごとに memory サーバーを 1 つ実行します。同じストアに対して複数のサーバーを同時に実行する場合は、それぞれに独自の NOONIEN_NODE_ID を設定してください。このツールはこれを強制しません。ノード ID を共有する 2 つのライターが同じミリ秒に書き込むと、同じ ID を持つ操作が生成され、読み取り時に明示的なエラーになります。一方、異なるクロックを使うライターは通常、異なる ID になるため、シャード内で気付かないうちに操作が混在し、折り畳み時にどちらか一方が選ばれることがあります。一意のノード ID は必須ですが、ツールで確認することはできません。

サーバー変数

MCP サーバー（および同じシャードを読み書きする noonien CLI）で使用します。

変数	デフォルト	意味
NOONIEN_BACKEND	file	file、memory、または s3 です。
NOONIEN_S3_BUCKET	—	バケットです（s3 バックエンドでは必須です）。
NOONIEN_S3_PREFIX	""	すべてのシャードオブジェクトが格納されるキーのプレフィックスです。
NOONIEN_S3_REGION	us-east-1	S3 クライアントに渡されるリージョンです。
NOONIEN_S3_ENDPOINT	—	MinIO／R2／Contabo などのカスタムエンドポイントです。
NOONIEN_S3_FORCE_PATH_STYLE	エンドポイント設定時はオン	パス形式のリクエストです。
NOONIEN_COMPACT_AFTER	1000	追記された操作がこの数に達した後、ローカルシャードをオンラインでコンパクト化します（0 で無効）。
NOONIEN_GC	オフ	デーモンなしでトゥームストーンを削除します。このノードがディレクトリの唯一の書き込み元である場合に限ります。これは、そのディレクトリ内の情報だけでは証明できない約束です。デーモンがディレクトリを管理している場合（起動時にナレッジファイルで自身の存在を通知します）は、効果がありません。デーモンが回収します。

NOONIEN_GC（サーバー側、デフォルトはオフ）と、デーモン側の NOONIEND_GC（デフォルトはオン）は別々のスイッチです。memory バックエンドでは何も共有されないため、NOONIEN_GC の設定に関係なくサーバーが回収します。

S3 の認証情報は標準の AWS 認証情報チェーン（AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_REGION、プロファイル、インスタンスロールなど）から取得されます。

ローカルシャードはオンラインでコンパクト化されます。NOONIEN_COMPACT_AFTER 件の操作が追記されると（デフォルトは 1000、0 で無効）、サーバーは書き込みと同じ変更キュー内で自身のシャードを書き換えます。書き換えは読み込んだ内容に対する比較交換で行われ、追記や、シャードを復旧する nooniend デーモンによる同時書き込みが発生すると、再読み込みして再試行するため、データが失われることはありません。noonien compact を実行すれば、同じコンパクト化を手動で行えます。noonien import は独自の <node>-import シャードを作成するため、ノードのサーバーが稼働中でも実行でき、再インポートも冪等です。このシャードは追加のみを行うため、ピアのナレッジも NOONIEN_GC に関する約束も必要ありません。noonien import は終了時にこのシャードを整理し、noonien compact も同様に整理します。後続の操作によってシャドー化された操作を除去し、すべてのトゥームストーンを保持します。また、削除対象がある場合にのみ書き換えるため、メンテナンスを繰り返してもコストはかからず、ピアにシャードの再取得を求めることもありません。file バックエンドでは、append と compact はシャードごとのロックを取得するため、プロセス間でも競合せず直列化されます。デーモンも同じロックを取得します。

ノード内のタイムスタンプは単調増加します。システム時刻が戻った場合（NTP、スナップショットの復元、手動の date など）、新しい操作には前のタイムスタンプが引き継がれるため、同じノードの後続操作が先行操作に負けることはありません。

デーモン変数

デーモンのみで使用します。メッシュに接続するには、少なくとも1つの検出ソース — NOONIEND_TAILSCALE、 NOONIEND_DNS_SRV、または NOONIEND_PEERS — が必要です。それ以外は任意です。VPN またはファイアウォールの内側で実行し、mTLS を有効にしてください。セキュリティを参照してください。

変数	デフォルト	意味
NOONIEND_LISTEN	0.0.0.0:27878	ゴシップサービスがバインドする host:port です。
NOONIEND_ADVERTISE	リッスンホスト（ワイルドカードの場合はホスト名）	任意です。 このノードがピアに通知する host:port です。デフォルト値が他のノードから解決できない場合にのみ設定してください。
NOONIEND_PEERS	—	検出：静的シード — カンマ区切りの node@host:port または host:port です。1つあれば十分です。その後、メンバーシップは自動的に伝播します。
NOONIEND_DNS_SRV	—	検出： _nooniend._tcp SRV レコードをシードとして使用するドメインです。
NOONIEND_TAILSCALE	オフ	検出： tailscale status から候補アドレスを取得します（/info に応答すると、ピアが参加します）。
NOONIEND_DISCOVER_INTERVAL	300	検出情報を更新する間隔（秒）です。0 の場合、起動時にソースを1回だけ読み込みます。更新では候補の追加のみ行われます。
NOONIEND_INTERVAL	30	アンチエントロピーの間隔（秒）です。
NOONIEND_PUSH	オン	ローカルシャードが変更されるとすぐに同期します。
NOONIEND_FANOUT	0	1ラウンドで接続するピア数です。0 の場合、到達可能なすべてのピアが対象になります。上限を設定すると NOONIEND_GC を併用できません：そのラウンドでサンプルされなかった到達可能なピアがあると、コレクションは保留されるため、デーモンは両方を同時に有効にすることを拒否します。
NOONIEND_DIGEST_MIN_SHARDS	32	シャード数がこの値以上の場合、完全なリストの代わりにダイジェストを使用します（0 = サポートされている場合は常に使用）。
NOONIEND_CHANNELS	オフ	メンバーシップ情報を各交換に便乗させる代わりに、専用チャンネルでゴシップします。
NOONIEND_RELAY	—	常にサンプリングするノード ID のカンマ区切りリストです（リレー／スーパーピア）。
NOONIEND_GC	オン	作成したシャードを収集します。影響を受けた操作を刈り込みます（メッシュ外のピアがゲートの証拠としてまだ折り込んでいる可能性のある操作は保持します）。また、その要素を折り込んだメッシュ外のピアが異議を唱えられなくなった時点で、トゥームストーンを削除します（物理削除）。つまり、そのピアの知識フロンティアがこのノードの保持する情報のサブセットであり、その要素の操作を含まない場合です。
NOONIEND_FORGET_AFTER	15552000（180日）	ピアが退役するまでの無通信時間（秒）です。退役すると、その保護情報は永続化され（統合されたしきい値、またはこのノードにない操作を保持している場合は包括的な保護）、アクティブな記録は削除されます。これにより、依存するメタデータコレクションのサイズが一定の範囲内に保たれます。0 の場合、退役しません。
NOONIEND_SUSPECT_AFTER	3	ピアを疑わしい状態としてマークするまでの交換失敗回数です。
NOONIEND_DEAD_AFTER	6	ピアをデッドとしてマークするまでの交換失敗回数です。
NOONIEND_DEAD_RETRY	300	デッドのピアを再度プローブするまで放置する時間（秒）です。
NOONIEND_MEMBERSHIP_TTL	604800	デッドのピアを忘却するまで保持する時間（秒）です。
NOONIEND_REVOKED	—	デーモンが同期を行わず、受け入れも拒否するノード ID のカンマ区切りリストです。
NOONIEND_DEPARTED	—	明示的に離脱したノード ID のカンマ区切りリストです。NOONIEND_REVOKED と同様ですが、そのレプリカも破棄され、コレクションを妨げなくなります。
NOONIEND_TLS_CERT / NOONIEND_TLS_KEY	—	この証明書とキーを使用して TLS でサービスを提供します。
NOONIEND_TLS_CA	—	ピアの証明書に署名する CA です。双方向の検証に使用します。
NOONIEND_TLS_REQUIRE_CLIENT	オン	クライアント証明書（mTLS）を必須にします。

動作の仕組み

すべての変更は操作として追記専用ログに記録され、ノードごとのシャードに分割されます。

• create_entities ／ add_observations ／ create_relations は要素を追加します。
• delete_entities ／ delete_observations ／ delete_relations は墓標を書き込みます（エンティティを削除すると、その観察結果と関連するリレーションにも墓標が付けられます）。

読み取りでは、すべてのシャードを折りたたんで統合します。各要素（エンティティ、観察結果の出現、リレーション）は、(HLC, node, sequence) によって決まる LWW レジスターです。観察結果の削除は内容単位で行われ、削除操作より古い同一内容の出現をすべて取り除きます。観察結果はそのエンティティが存在するときに、リレーションは両方の端点が存在するときに表示されます。統合結果は、シャードや行を読み取った順序には依存せず、操作の集合だけで決まります。操作はハイブリッド論理クロックで順序付けられます。時計のずれがあっても順序は保たれ、あるノードが主張を確認した後なら、それより後に順序付けられる訂正を書き込めます。観測されたタイムスタンプが許容範囲を超えて未来にある場合は補正されるため、誤った時計によってノードのタイムスタンプが未来に引きずられることはありません。読み取りは増分的です。各シャードは一度だけデコードされ、低コストのフィンガープリントと照合してキャッシュされます。また、統合済みのグラフもメモ化されるため、変更がない場合の読み取りで必要なのは、シャードごとのフィンガープリントの確認だけです。

プロパティテストですべて確認されている結果は、次のとおりです。

• 冪等性 — 同じ操作を2回適用しても、何も変わりません。
• 可換性 — シャード間の操作順序は関係ありません。
• 結合性 — シャードをどのようにグループ化して統合しても、同じグラフになります。
• 収束性 — 同じ操作を持つ2つのノードは、同一のグラフを生成します。

順序は決定的です。エンティティは名前順、リレーションは (from, to, relationType) 順、観察結果は操作順（HLC、node、sequence）です。

圧縮

ログは変更のたびに増加します。圧縮では、このノードのシャードを書き換え、要素ごとに、それより後の操作によって上書きされていない操作だけを残します。上書き判定用のインデックスは統合済みのログから構築されるため、別のノードによる後続の操作に置き換えられた操作も削除されます。また、墓標も含め、すべての要素の勝者は必ず残ります。圧縮はオンラインで実行されます。サーバーは NOONIEN_COMPACT_AFTER 回の追記後に自身のシャードを圧縮し、noonien compact を実行すると手動で同じ処理を行います。墓標を物理的に削除するタイミングについては、削除と回収を参照してください。書き換えは比較とスワップで行われます（file バックエンドでは一時ファイルをシャードに名前変更し、s3 では条件付き書き込みを行います）。そのため、途中でクラッシュしてもシャードが切り詰められることはありません。また、同時書き込み（追記またはゴシップによる復旧）が発生した場合は、圧縮処理全体を再読み込みして再試行するため、データが失われることはありません。

圧縮のたびに、shard.compact メタデータ操作（グラフ要素ではありません）が記録されます。その generation は毎回増加し、seq はシャードの永続的な高水位マークになるため、シーケンスが後退することはなく、圧縮がシャードの消失と誤認されることもありません。ピアは /shards から generation を読み取り、古いレプリカを圧縮済みシャードで置き換えるため、すべてのコピーが圧縮済みの内容に収束します。書き換えられるのはローカルシャードだけで、他のシャードには触れません。そのため、圧縮によって競合が発生することはなく、他のノードにも影響しません。

削除と回収

削除は除去ではなく操作です。delete_entities、delete_observations、delete_relations は墓標を追記し、墓標がその要素の最新の操作である間、統合処理ではその要素を非表示にします。墓標があるからこそ、同時書き込みに対して削除が優先されます。その書き込みがまだ存在するうちに墓標を削除すると、要素が復活してしまいます。したがって、誰も墓標を保持していない状態になって初めて、削除は物理的に完了します。 nooniend は、メッシュが安全なときに、自身が作成したシャードを要素ごとに収集します。まず、後続の操作によってシャドウされ、かつ保持されているメッシュ外のピアが今後必要とする可能性もない操作を削除します。次に、メッシュ外のピアがその要素に異議を唱えられない場合、残ったトゥームストーンを削除することがあります。ピアごとに、これを許可する条件は2つあります。ピアの知識フロンティアが、このノードがすでに保持しているもののサブセットであること — このノードにない操作を保持しているピアは、その要素に関する中継された操作を保持している可能性があるため、ブロッカーとして扱われます — そして、そのフロンティアがその要素の操作を一切含まないことです。つまり、その要素をフォールドしたピアだけが異議を唱えられます。その要素を一度もフォールドしていないピアも、偶然一致する要素を生成できます（独立した名前や、認識しているエンティティ上の観測など）が、フォールドではそれは復活ではなく、並行するジェネシスとして処理されます。そのため、ピアがすでに不在の間に現れた要素は、そのピアの復帰を待たずにすぐ収集できます。一方、ピアが認識していた要素は、ピアが戻るか、明示的に離脱させられるまで固定されたままです。別のシャードに残存操作がある場合もトゥームストーンは保持されるため、フォールドは常に保たれます。ピアがある要素に異議を唱えられる場合、そのピアが知っていた操作は、次のラウンドで再び読み取る証拠として保持されます。そして、その操作を保持するのは削除者だけではなく、作成者です。メッシュ外のピアがまだ異議を唱えられる要素では、ノードがシャドウされた操作を削除することはありません。そのため、トゥームストーンが別のシャードにあっても証拠は残ります（あるノードが別のノードの作成した要素を削除した場合）。

主張を一言で言えば、収集に履歴全体にわたるバリアは不要です。要素を一度もフォールドしていないピアは、どれだけ長く不在でも、因果的にそれに異議を唱えることはできません。また、グローバルな確認応答ラウンドも、データに対するタイマーも必要ありません。必要なのは、稼働中のメンバー全体で安定したラウンドです。到達可能な保持対象ピアとは、そのラウンドで必ず同期している必要があります（そうでない場合、そのピアがこのノードに取り込まれていない書き込みを保持している可能性があるため、ラウンドは一時停止します）。また、保持対象のピアが、このノードにない情報を保持していてはなりません。これが、NOONIEND_FANOUT と NOONIEND_GC が互いに排他的である理由です。可用性は自律的に保たれるわけではありません。到達不能かつ検証不能なピア（これまで到達できたことがない、またはこのノードが読み取れない操作を保持しているピア）は、オペレーターが離脱させる（NOONIEND_REVOKED / NOONIEND_DEPARTED）まで収集をブロックします。保持期間はメタデータの量を制限するものであり、データを失わせるものではありませんが、この判断を不要にするものではありません。

各ピアの知識フロンティア（各作成者のシャードについて、そのピアが保持していることが確認された最大シーケンス）は永続化され、シャードとともに .nooniend-peers.json に保存されます。そのため、1年間オフラインだったマシンも、実際に認識していた要素だけをブロックします。ラウンド中に到達できるのに同期されなかったピアがいる場合、そのピアがこのノードに取り込まれていない書き込みを保持している可能性があるため、収集は全面的に一時停止します。ピアを忘れても（メンバーシップ TTL）、ブロックは解除されません。そのピアは、有効な未送信の書き込みを持ったままメッシュ外で稼働している可能性があるためです。一方、NOONIEND_REVOKED と NOONIEND_DEPARTED を設定すると解除されます。これは、その書き込みを破棄してよいというオペレーターの判断です。離脱したピアのレプリカは完全に破棄されます。書き込みを放棄されたノードは、ゲートの対象から作成者としても外されるため、そのレプリカを保持するピアを介して収集を妨げることもなくなります。取り消されたノードの操作は、このノードにすでに存在する限り、そのノードが離脱させられるまで要素を固定します。離脱させると、それらの操作は破棄されます。NOONIEND_GC=false を設定すると、デーモンの収集を無効にできます。 ピアごとのレコードには上限があります。NOONIEND_FORGET_AFTER 秒間（デフォルトでは180 日）通信がないと、そのピアは退役します。退役は意味的に不可視であり、保護の所在を移すだけで、 保護される要素は変わりません。計上済みのピア、つまりそのフロンティアがこのノードの 保持するデータの部分集合であるピアは、永続的な退役済みフロンティアに統合されます。これは 作成者ごとに要素単位の最大値を1つ保持します。この最大値は、ピアが行っていた要素ごとの判断の 和集合そのものなので、退役後に発生した削除も含め、ピアが取り込めたすべての要素に対する ゲートを維持します。ピアごとにマップを1つ保持するのではなく、このノードが保持するシャードで 上限が決まる1つのマップにまとめられます。（期限切れ時に計算した要素ごとの一覧では、 正しく機能しません。後から作成されたトゥームストーンは、その一覧に含まれないためです。） 未計上のピア、つまりこのノードが読み取れない操作を持っていると主張するピアは、代わりに 永続的な包括ゲートを残します。これは、稼働中にそのピアをゲートしていた「何でも持っている 可能性がある」という状態を、検証できないマップとして持ち続けるのではなく、1つの記録として 残すものです。退役によって何も放棄されないため、この期間はデフォルトで有効にできます。 放棄に該当するのは、引き続き NOONIEND_REVOKED と NOONIEND_DEPARTED だけです。 最大値は統合を解除できないため、寄与を解除するには、その期間が切れる前にノードを離脱済みに しなければなりません。このノードが提供できない作成者を主張するフロンティアは記録されません。 ピアが裏付けられない主張によってメッシュを停止させることはできません。到達できなかった ノードとして宣言されたものは、これまでどおり保守的にブロックし続けます。

デーモンがない場合、物理的な削除には明示的な約束が必要です。ディレクトリを所有する デーモン（.nooniend-peers.json が存在する場合）は、ピアの情報を保持して収集を行います。また、 シャードを維持する唯一の書き込み元です。サーバーと noonien compact は、そこで全体像を保持します。 シャドウ化された操作は、デーモンのゲートが読み取る証拠そのものなので、削除してはなりません。 シャードの管理はデーモンに任せます。デーモンがなければ、ゲートに必要な情報はなく、ディレクトリ だけではピアが単に不在なのかどうかを判断できません。オフラインのマシンや、まだ同期されて いない設定済みのマシンは、何も残さずに存在します。その未同期の書き込みは、収集によって失われます。 これは公式サーバーが実行する即時削除です。そのため、サーバーのオンラインメンテナンスと noonien compact は、運用担当者がディレクトリを書き込むのはこのノードだけだと宣言する （NOONIEN_GC=true）までは、プルーニングのみを行います。この宣言があることで、削除が安全に 行えるようになります。別のノードのシャードによって宣言と矛盾する場合は、宣言を拒否して報告します。

メトリクス

デーモンはすべてのメトリクスを /metrics で公開します（MCP サーバーは stdio で動作し、エンドポイントはありません）。収集と保持の状態は次のとおりです。

メトリクス	意味
noonien_gossip_frozen_elements	メッシュ外のピアが異議を唱える可能性があるため、保持されている削除済み要素
noonien_gossip_absent_nodes	直近のラウンドで交換を行わなかった、保持中のピア
noonien_gossip_absent_seconds{node}	各ピアが不在になってからの時間
noonien_gossip_retained_peers	その知識が引き続き収集の条件となっているピア
noonien_gossip_retired_total	退役フロンティアに移されたピア
noonien_gossip_retired_unaccounted_total	ブランケットを付与されて退役したピア
noonien_gossip_retired_authors	しきい値が退役フロンティアに残っている作成者
noonien_gossip_blankets	適用中の永続的なブランケット

同じエンドポイントでは、トランスポートと稼働状態に関するメトリクスファミリー（noonien_gossip_rounds_total、 noonien_gossip_round_seconds、noonien_gossip_round_bytes、noonien_gossip_links、 noonien_gossip_shards、noonien_gossip_stable_shards、noonien_gossip_membership_size、 noonien_gossip_peers_ok_total、noonien_gossip_peers_failed_total、 noonien_gossip_ops_pulled_total、noonien_gossip_ops_pushed_total、 noonien_gossip_digest_exchanges_total、noonien_gossip_membership_channel_failures_total、 noonien_gossip_bytes_sent_total、noonien_gossip_bytes_received_total、 noonien_gossip_fanout、noonien_gossip_up）も公開されます。また、デーモンがローカルログ自体のメンテナンスを実行する場合は、noonien_mcp_* カウンター（noonien_mcp_folds_total、noonien_mcp_fold_seconds、 noonien_mcp_shards_merged、noonien_mcp_shard_stat_total、noonien_mcp_ops_decoded_total、 noonien_mcp_compacted_total、noonien_mcp_compaction_failed_total）も公開されます。

ツール

MCP のインターフェースは、公式の9つのツールをそのまま提供します。名前、入力、出力、メッセージは @modelcontextprotocol/server-memory と一致します。

ツール	内容
create_entities	ナレッジグラフに複数の新しいエンティティを作成します
create_relations	エンティティ間に複数の新しいリレーションを作成します（能動態）
add_observations	既存のエンティティに新しい観察事項を追加します
delete_entities	エンティティと、それに関連するリレーションを削除します
delete_observations	エンティティから指定した観察事項を削除します
delete_relations	複数のリレーションを削除します
read_graph	ナレッジグラフ全体を読み取ります
search_nodes	エンティティ名、タイプ、観察事項の内容と照合して、クエリに一致するノードを検索します
open_nodes	名前を指定して特定のノードを開きます

ドロップイン互換性

同じ9つのツール（ツール）を備えているため、エージェントを変更せずに memory サーバー名で利用できます。

グラフ全体は memory://knowledge-graph リソースとしても公開されます。このリソースは読み取り専用です。クライアントはこれをサブスクライブし、変更によってグラフが更新されるたびに notifications/resources/updated を受け取れます。2025年のプロトコルでは resources/subscribe を、2026-07-28 の改訂版では subscriptions/listen ストリームを使用します。サーバーは両方に対応しており、2025年版クライアントの initialize ハンドシェイクと、2026-07-28 版クライアントの server/discover に応答します。

エンティティは名前をキーとして扱います。観察事項の動作は公式サーバーと同じです。add_observations は内容がすでに存在する場合は何も行いませんが、単一のリクエスト内で内容が重複している場合はそのまま保持します。create_entities は与えられた重複する内容をそのまま保持し、観察事項を削除すると、その内容の出現箇所がすべて削除されます。リレーションは集合として扱われるため、同じリレーションを2回追加しても何も起きません。delete_entities はエンティティの観察事項と、それに関連するリレーションも削除します。トゥームストーンが対象とするのは、削除を行ったノードが確認できた範囲です。別のノードで同時に追加された観察事項は要素として残るため、後からエンティティが再作成されると、その観察事項も再び現れます。

セキュリティ

• シャードごとに書き込みノードは1つです。 NOONIEN_NODE_ID は一意にし、ノード ID ごとにサーバーを1つ実行してください。ノード ID は、長さが制限されパスで安全に使えるシャードファイル名のステムにサニタイズされます。また、ピアから届くすべてのノード ID（/shards/{node}/ops パス、ゴシップされたサマリー、通知されたヘッダー）は、ファイル名として使用されたり、ピアセットに追加されたり、メトリクスのラベルになったりする前に検証されます。
• レプリケーション。 nooniend はネットワークサービスです。VPN またはファイアウォールの内側で実行し、認証済みのピアのみがレプリケーションできるよう、mTLS を有効にしてください（証明書が設定されている場合はデフォルトで有効です）。クライアントは常にピア証明書を検証します。設定済みの CA、または CA が設定されていない場合はシステムの信頼ストアを使用します。検証されていない接続は決して使用されません。TLS を使用しない場合、デーモンはネットワーク基盤を信頼します。ピアが通知するアドレスは引き続き通常の host:port として検証され、実際にリクエストが届いたホストと一致する場合にのみ採用されます（そのため、通知されたヘッダーがダイヤラーを別のホストに誘導することはありません）。拒否（NOONIEND_REVOKED / NOONIEND_DEPARTED）には、mTLS によって提供されるクライアント証明書が必要です。証明書がなければ、ピアの拒否対象となる ID を特定できません。NOONIEND_TLS_REQUIRE_CLIENT=false を設定すると、TLS は未認証のチャネルに戻ります（どのクライアントでも任意のシャードをプッシュできます）。このモードでは、デーモンは起動時に警告をログに記録します。
• 信頼モデル。 mTLS が認証するのはメンバーであり、個々の操作ではありません。ノードは保持しているすべてのシャードを提供するため、リレーは信頼されています。メンバーは別のノードのシャードを第三のノードに運ぶことができ、デーモンはピアのレプリカから自身の失われたシャードを復元します。nooniend は、ピアとして信頼できるマシンでのみ実行してください。fold の最終書き込み優先の順序は操作の HLC タイムスタンプを信頼するため、時計が大幅に進んでいるメンバーは、その要素に関するすべての競合に勝ちます。時計の誤りは正確性に関わる危険であり、権限の境界ではありません。コレクションでは、メンバーからの報告内容も信頼します。/shards から得られるフロンティアと、メンバーがゴシップするピアセットを信頼します。証明書が証明するのはメンバーが誰かであり、報告が真実であることではありません。また、ノードが情報を得る経路はメッシュのみだと想定しています。離脱したノードは、別の場所で操作を受信し続けてはなりません（デーモンと共有の file / s3 領域を同じディレクトリに向けないでください。また、2つのメッシュをつなぐノードは両方のメッシュに属する必要があり、そうでなければ離脱させてください）。
• 脆弱性の報告。 公開の issue は作成しないでください。詳細は SECURITY.md を参照してください。

開発

git clone https://github.com/sequico/server-noonien.git
cd server-noonien
npm install

npm run check       # Biome: lint + format + import order
npm run typecheck   # tsc --noEmit
npm run test        # Vitest, including the CRDT property tests
npm run build       # tsc -> dist/
npm run gate        # all of the above

ワークフローと基本ルールについては、CONTRIBUTING.md を参照してください。

noonienという名前の由来

この名前は、『Star Trek: The Next Generation』へのオマージュです。当初、このプロジェクトは**「Datalore」と名付ける予定でした。これは、Dataと双子の兄弟Lore**が登場するエピソードのタイトルです（シーズン1第13話、1988年1月18日初放送）。2人は、Dr. Noonien Soongが作ったSoong型アンドロイドです。Dataは善良なほうで、Loreは欠陥があり、感情的で悪意のあるプロトタイプです。どちらも同じ俳優、Brent Spinerが演じています。

エピソードのタイトルは2体のアンドロイドの名前を組み合わせたもので、2つの名前はナレッジグラフにあまりにもよく当てはまります。

• Data — datum、つまり1つの事実です。
• Lore — コミュニティで共有される知識と伝統の集積です。

つまり、dataloreは事実と共有された伝承を意味し、まさに共有エージェントメモリそのものです。しかし、「Datalore」は同じソフトウェア分野の無関係な商用製品の名前でもあるため、そのブランドとの競合を避け、プロジェクト名をアンドロイドたちの生みの親であるDr. Noonien Soongにちなんだ**noonienに変更しました。生みの親の名を付けることで、DataとLoreの両方**へのオマージュを保っています。

双子のモチーフは、このプロジェクトの中核的な課題に重なります。異なるマシン上に同じグラフのコピーが多数存在し、それらの一貫性を保つ必要があるという課題です。Dataの善良な双子とLoreの邪悪な双子は、2つの障害モードに当たります。server-noonienでは、マージが設計上コンフリクトフリーであるため、コピー同士が乖離することはありません。このグラフに邪悪な双子はいません。

制作にまつわるちょっとした逸話があります。このエピソードは当初、Dataと女性型アンドロイドとのロマンスとして提案されました。代わりに邪悪な双子の筋書きを提案したのは、Brent Spiner本人でした。つまり、双子の両方を演じた俳優が、エピソードのどんでん返しにも影響を与えたのです。

参考資料：

• Memory Alpha — Datalore (episode)：https://memory-alpha.fandom.com/wiki/Datalore_(episode)
• Memory Alpha — Noonien Soong：https://memory-alpha.fandom.com/wiki/Noonien_Soong
• Memory Alpha — Lore：https://memory-alpha.fandom.com/wiki/Lore

このプロジェクトは独立したファンによるオマージュです。「Star Trek」、「Data」、「Lore」、「Noonien Soong」はそれぞれの権利者に帰属します。このプロジェクトは権利者と提携しておらず、承認も受けていません。

ドキュメント

• PLAN.md — アーキテクチャと設計上の決定事項。
• SCALING.md — 1,000／10,000ノードに向けた将来計画。
• PROTOCOL.md — nooniendのワイヤープロトコル：トランスポート、メッセージ、制限、セキュリティ。
• docs/paper.md — 技術レポート：モデル、トゥームストーン収集に関する貢献、評価。参考文献はdocs/references.bibに記載されています（リリース1.0.0時点で固定。レポートはCC BY 4.0に基づくSequi Companyの著作物です。詳細はNOTICEを参照してください）。
• CONTRIBUTING.md — 貢献方法。
• AGENTS.md — 貢献者とエージェント向けのプロジェクトルール。
• SECURITY.md — セキュリティポリシーと脆弱性の報告方法。
• CODE_OF_CONDUCT.md — コミュニティ行動規範。

ライセンスと免責事項

ソースコードはMozilla Public License 2.0（MPL-2.0）に基づいてライセンスされています。レポートdocs/paper.mdはSequi Companyの著作物であり、CC BY 4.0に基づいてライセンスされています。詳細はNOTICEを参照してください。

⚠️ 保証およびサポートはありません： このソフトウェアは「現状のまま」提供されます。作者は商用サポート、保守の保証、稼働時間に関する支援を一切提供しません。Issueを作成した場合、対応はすべて任意となります。

❤️ プロジェクトを支援する（パッシブな収益化）

このコンポーネントによって、インフラ開発にかかる時間を会社で何百時間も削減できている場合は、 プロジェクトの支援をご検討ください。

• GitHub でスポンサーになる： この README に会社のロゴを掲載して、プロジェクトの継続を支援してください。 👉 今すぐスポンサーになる
• 機能開発を支援する： 特定のバグ修正や新しいプロトコルの追加をご希望ですか？ Polar.sh を利用しています。GitHub Issue に懸賞金を設定して、開発を促進できます。 👉 懸賞金を見る