Vnsh について
Vnsh は、AI エージェントや共同作業者が 1 つの暗号化リンクから同じドキュメントを読み書きできるポータブルなワークスペースです。内容はブラウザーで暗号化してからアップロードされ、サーバーは平文を読めません。最後の編集から 24 時間後に削除されます。
主な機能
- 01編集と閲覧専用の 2 種類の権限を持つ固定リンク
- 02URL フラグメントに鍵を置くクライアント側暗号化
- 03バージョン確認による複数エージェント間の上書き防止
- 04バージョン履歴の一覧表示と復元
- 05MCP サーバー、コマンドラインツール、ブラウザー拡張
活用シーン
- 01Claude Code や Cursor などのコーディングエージェント間でコンテキストを受け渡す
- 02ビルド成果物や失敗したテストログをリンクで共有する
- 03CI ジョブから閲覧可能な結果リンクを生成する
MCP 対応
vnsh-mcp は MCP サーバーであり、ワークスペースや一時コンテンツの作成、読み取り、更新、履歴確認、復元などのツールを MCP クライアントに公開します。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
14掲載時のツール一覧 · 3 週間前に更新
| パラメーター | 型 | 必須 | 説明 |
|---|---|---|---|
| url | string | はい | #k=/iv= を含む旧形式の /v/ URL、または公開 /p/{id} URL |
詳細
vnsh
すべての AI エージェントが読み書きできる、ひとつのワークスペース
ウェブサイト • はじめる • リンク • 仕組み • API • セルフホスティング
今は、同じコンテキストを Claude Code に貼り付け、次に Cursor、さらに Slack に貼り付けています。
vnsh なら、そのコンテキストにひとつのアドレスを付けられます。一度置くだけでリンクが作成され、あなたが共有したすべてのエージェントと人が同じ更新され続けるドキュメントを開いて、変更できます。アップロード前にブラウザー内で暗号化されるため、vnsh が内容を見ることはありません。また、最後に編集してから24時間後に削除されます。
kubectl logs pod/app | vn
# https://vnsh.dev/w/k2p9xf...#w=... edit link — read and write
# https://vnsh.dev/w/k2p9xf...#r=... view-only — read, never write
なぜペーストビンではなく、これなのか
ペーストビンで得られるのはスナップショットです。ワークスペースには固定のアドレスとバージョンがあるため、次のエージェントは新しいものを作り始めず、同じ場所に書き戻せます。安全に共有するための特長は2つあります。
- サーバーは内容を読み取れません。 内容はクライアント側で暗号化され、鍵は URL フラグメントに含まれます。HTTP では送信されません。サーバーに保存されるのは暗号文と書き込みトークンの SHA-256 ハッシュであり、トークン自体ではありません。ファイル名も同じ鍵で暗号化されるため、受信者は
analysis.pyをダウンロードできますが、vnsh が保持するのは解読できない文字列です。これは外部から検証できます。トークンを偽造すると403が返されます。 - 2つのエージェントが互いの変更を黙って上書きすることはありません。 書き込みは、読み取ったバージョンを条件として行われます。無条件の書き込みは拒否され、古いバージョンでの書き込みには、再読み込みしてマージするよう伝える412が返されます。5つのライターが同時に書き込む本番環境での測定では、1つが成功し、残りの4つには通知が返され、データは失われませんでした。
はじめる
エージェント向け — これが本来の使い方です
次の内容を Claude Code、Cursor、OpenHands、Cline、Windsurf、Zed など、MCP に対応するものに貼り付けてください。
Set up vnsh workspaces — one link to hand work between people and agents: https://vnsh.dev/llms.txt
エージェントがプロトコルを読み込み、MCP サーバーをインストールし、以降もワークスペースを使い続けられるよう、自身の指示ファイルに常時適用するルールを書き込みます。手動で設定する場合は、次のとおりです。
claude mcp add vnsh -- npx -y [email protected]
サーバーは vnsh_artifact_create、vnsh_artifact_list、vnsh_artifact_read、vnsh_artifact_update、vnsh_workspace_create、vnsh_workspace_read、vnsh_workspace_update、vnsh_workspace_history、vnsh_workspace_restore、vnsh_workspace_renew、vnsh_workspace_open に加えて、一度限りのコンテンツ共有用に vnsh_share、vnsh_share_file、vnsh_read を公開します。
ターミナルから
npx vnsh # or: npm i -g vnsh
# or: curl -sL vnsh.dev/i | sh (one-shot links only)
vn ./report.html # create a workspace from a file
git diff | vn # or from stdin
vn read "<any vnsh url>" # read one back — workspace, public, or legacy blob
vn write "<edit url>" ./new # replace the contents; refuses to clobber
vn history "<workspace url>" # list the latest 20 retained versions
vn restore "<edit url>" 3 # restore v3 as a new latest version
vn init . # teach agents in this project to use vnsh
vn init は、プロジェクトのエージェント指示ファイルに冪等な管理対象セクションを追加します。エージェントベンダーを問わず動作し、その CLI が後でワークスペースを作成する際には、匿名の「プロジェクトを初期化済み」という項目のみを記録します。そのため、プロジェクト名やパスを収集することなく、実験の効果を測定できます。
--public は暗号化せずに公開します(以下を参照)。--blob は明示的に使い捨てリンクを作成します。--ttl はワークスペースでも最大 168 時間まで指定できます。その後の書き込みでも有効期間は維持され、vn renew を使えば編集せずに延長できます。
curl -sL vnsh.dev/i | sh で取得できる、依存関係のないシェル関数は使い捨てリンクのみを扱います。ワークスペースには HKDF-SHA256 と AES-256-GCM が必要ですが、macOS に付属する openssl は LibreSSL で、どちらにも対応していません。そのため、Node が利用可能な場合は /w/ リンクの処理を npx vnsh に引き継ぎ、利用できない場合はその旨を明示します。
ブラウザーから
https://vnsh.dev — ファイルをドロップするかテキストを貼り付けると、2 種類のリンクが返されます。暗号化される前にアップロードされることはありません。
CI から
upload-to-vnsh はビルド出力や失敗したテストのログをアップロードし、ジョブのサマリーにリンクを出力します。
Chrome から
拡張機能 は GitHub、Slack、Discord 上で vnsh リンクをインラインでプレビューします。また、⌘D を使ってスクリーンショット、コンソールエラー、ページ URL を 1 つのリンクにまとめます。
3 種類のリンク
| リンク | 含まれるもの | 読み取れる人 | 書き込める人 |
|---|---|---|---|
vnsh.dev/w/{id}#w=<secret> | ルートシークレット | リンクを知っている人 | リンクを知っている人 |
vnsh.dev/w/{id}#r=<key> | コンテンツキー | リンクを知っている人 | 誰もいません |
vnshcontent.dev/p/{id} | なし | 誰でも | 作成者の #w= リンクを持つ人のみ |
閲覧専用の段階は、サーバーが強制する設定ではなく、数学的な性質によるものです。コンテンツキーは HKDF(secret, "vnsh/enc/v2") という一方向の導出によって生成されます。そのため、キーを持つ人はすべてのバージョンを復号できますが、シークレットを復元して書き込みトークンを導出することはできません。
公開ワークスペースがあるのは、リンクを開く人のブラウザーは復号できますが、エージェントの fetch は復号できないためです。公開ワークスペースは書き込まれた状態のまま保存され、通常のドキュメントとして配信されるため、HTTP に対応するものなら何でもキーや設定なしで読み取れます。その代わり、公開を選択する箇所に明示されています。vnsh は公開ワークスペースを読み取ることができます。 公開はデフォルトではなく、推測によって設定されることもありません。公開範囲は作成時に固定され、変更には引き続き書き込みトークンが必要です。
公開ワークスペースは**vnshcontent.dev**という別の登録可能ドメインから配信されます。これは見た目だけの違いではありません。公開ドキュメントは見知らぬ人によって書き込まれ、トップレベルページとして表示されます。一方、安全性の評価システム(Safe Browsing、メールゲートウェイ、企業プロキシなど)はパスではなくドメインをリストに登録します。vnsh.dev 上の悪意あるページが 1 つでもあれば、API、サイト、インストール済みのすべての CLI、MCP サーバー、拡張機能まで停止しかねません。サブドメインでは解決しません。単位となるのは登録可能ドメインです。サンドボックス化は別の問題で、すでに対処済みです。公開ドキュメントは sandbox CSP ディレクティブ付きで配信されるため、Cookie、ストレージ、ネットワーク、ほかのページへのアクセスがない不透明なオリジンに読み込まれます。/w/ リンクは vnsh.dev に留まります。フラグメント内のキーが実際のゲートとなるため、サーバーはリンクの平文を一度も見ておらず、クローラーも見ることができません。
公開 URL を自分で組み立てないでください。作成すると、レスポンスの url フィールドに正確なリンクが返されます。これにより、単一ドメインでセルフホストするインスタンスも動作します。
仕組み
you ──encrypt──▶ [ vnsh: ciphertext, no key ] ──decrypt──▶ agent / person
│
deleted 24h after the last write
キーのスケジュール
S = random(32) root secret, lives only in the fragment
K = HKDF-SHA256(S, "vnsh/enc/v2") content key — AES-256-GCM
W = HKDF-SHA256(S, "vnsh/write/v2") write token, sent as 64 hex chars
H = SHA-256(W) the only derived value the server stores
ワークスペースでは、使い切りの blob で使われる AES-256-CBC ではなく、AES-256-GCM を使用します。変更可能なコンテンツには完全性の保証が必要だからです。認証タグがなければ、ホストも含め、ストレージを書き換えられる人は誰でも暗号文のビットを検知されることなく反転でき、保証全体が損なわれてしまいます。ノンスは書き込みごとにランダムに生成して先頭に付加し、バージョン番号から導出することはありません。
ビューアーは、sandbox="allow-scripts" を指定し、意図的に allow-same-origin を指定しないフレーム内で HTML と Markdown を表示します。これにより、コンテンツは不透明なオリジンで実行され、location.hash からキーを読み取れません。さらに、挿入された default-src 'none' によってネットワークアクセスも遮断されます。
作成方法も含めたプロトコル全体は /llms.txt に記載されています。暗号ライブラリを使えば、どの言語でも実装でき、vnsh のコードを一切実行する必要はありません。約 200 行で実装した人もいます。
API
| エンドポイント | 目的 |
|---|---|
POST /api/workspace | 作成します。X-Vnsh-Write-Hash が必要です。公開するには X-Vnsh-Public: 1 を指定します。公開時は url を返します。 |
GET /api/workspace/:id | 暗号文を読み取ります。ETag はバージョンです。 |
PUT /api/workspace/:id | 置き換えます。X-Vnsh-Write と If-Match が必要です。 |
GET /w/:id | ビューアーです。クライアント側で復号し、サンドボックス内で表示します。 |
GET /p/:id | 公開ワークスペースを通常のドキュメントとして表示します(vnshcontent.dev 上)。 |
POST /api/drop | 使い切りの blob(v1)です。?ttl= と ?price= を指定します。 |
GET /api/blob/:id | 使い切りの blob を読み取ります。 |
GET /llms.txt | エージェント向けに記述されたプロトコルです。 |
書き込み時、If-Match がない場合は 428、バージョンが古い場合は 412、書き込みトークンが無効な場合は 403 を返します。詳しいリファレンスは docs/api.md をご覧ください。
セキュリティモデル
アカウントと永続アーティファクト
匿名での共有は、引き続きアカウント不要で一時的です。
https://account.vnsh.dev でマジックリンクを使ってサインインすると、新しく作成したワークスペースと /artifact/ ページを、削除するまで保持できます。ブラウザーから作成する場合は、サインイン済みのセッションが自動的に使われます。CLI では vn login を実行し、ブラウザーでデバイスを承認してください。MCP と CI では、VNSH_TOKEN にアカウントトークンを設定できます。ケイパビリティリンクのワークスペースのコンテンツは引き続きローカルで暗号化され、アカウントデータベースに保存されるのは所有権のメタデータのみで、鍵や平文は保存されません。
無料プレビュー期間中、各アカウントは保持されたバージョンを含めて、ドキュメントを 100 件、合計 1 GB まで保持できます。
返されたリンクは保管してください。フラグメントには復号・編集用の秘密情報が唯一含まれているため、アカウントから保持期間や削除は管理できますが、失われた鍵を復元することはできません。
フェーズ 1 のアカウントアーティファクトでは、別のコラボレーションモードが追加されます。認証済みの人間とエージェントトークンは、フラグメントキーを持ち回らずに、非公開のアーティファクトコンテンツを検出し、バージョン管理できます。この利便性には異なるセキュリティ境界があり、vnsh は技術的にアカウントアーティファクトのコンテンツを読み取ることができます。匿名の暗号化ワークスペースの代わりにひそかに使われることはなく、デフォルトでは人間のみが承認または公開できます。
vn login
vn artifact create report.md --title "Release report" --type report
vn artifact list --query release --status draft
vn artifact read <artifact-id>
vn artifact update <artifact-id> report.md --base-version 1 --change-summary "Verified production"
別のプログラムやエージェントが結果を利用する場合は、任意のアーティファクトコマンドに --json を追加してください。
保証されること。 vnsh は暗号化されたコンテンツを読み取ることも、書き込むこともできず、保存している情報から書き込みトークンを復元することもできません。レンダリングされたコンテンツは、同一オリジンへのアクセスもネットワークも許可されない環境で実行されるため、悪意のあるドキュメントが鍵にアクセスしたり、どこかに何かを送信したりすることはできません。
保証されないこと。
- **リンクを誰かに渡すことは、鍵を渡すことと同じです。**そのエージェントのモデルプロバイダーにも鍵が渡ります。これを制限するのは暗号化ではなく 24 時間の期限です。また、書き込みのたびに期限がリセットされるため、毎日編集されるワークスペースは存続し続けます。
- **境界となるのはトランスポートではなくクライアントです。**暗号化するものは、最初に平文を保持します。MCP サーバーも CLI も同様です。
npx -yは起動するたびに公開済みの最新バージョンを再取得します。バージョンを固定する([email protected])、一度グローバルにインストールする、または実行する内容を確認する場合はソースからビルドしてください。 - **公開ワークスペースは設計上、vnsh が読み取れます。**これがそのティアの仕様です。
- **メタデータは非公開ではありません。**ホスト型サービスでは、時刻、サイズ、アドレスが記録されます。非公開なのはコンテンツのみです。
セルフホスティング
Cloudflare Workers と R2 バケットを使用します。データベースも KV も不要です。
git clone https://github.com/raullenchai/vnsh.git
cd vnsh/worker && npm install
wrangler r2 bucket create vnsh-store
wrangler deploy
wrangler.toml では、R2、2 つのネイティブレートリミッター、Analytics Engine データセットをバインドします。以前のバージョンでは、メタデータとカウンターに KV ネームスペースを使っていましたが、無料枠の書き込み上限によってサイト全体がダウンしたため削除されました。現在は必要ありません。作成するよう指示する古いガイドに従っている場合も、作成する必要はありません。docs/self-hosting.md を参照してください。
リポジトリ
| パス | 内容 |
|---|---|
worker/ | Cloudflare Worker:API、ビューアー、ホームページ、llms.txt |
mcp/ | vnsh-mcp — エージェントが使用する MCP サーバー |
cli/npm/ | vnsh — vn コマンド |
cli/ | install.sh と、依存関係のないシェル関数 |
extension/ | Chrome 拡張機能 |
docs/ | アーキテクチャ、API、CLI、MCP、運用、セルフホスティング |
docs/plans/ | v2 ワークスペース計画を含む設計ドキュメント |
npm test # every package
cd worker && npm run dev # local worker
4 つのパッケージは、それぞれ独立して配布されるため、鍵スケジュールのコピーを個別に持っています。各パッケージには同じテストベクトルが設定されています。あるパッケージで作成したリンクが別のパッケージで開けない場合、バージョンの不整合ではなく破損として扱われるため、失敗が表面化しません。導出方法を変更する場合、それがひそかに起きるのを防ぐのがこれらのテストです。
貢献
問題の報告やプルリクエストを歓迎します。私たちが間違っていると指摘するものも歓迎です。これまでで最も有益な貢献は、llms.txt からプロトコルを再実装し、ドキュメントに書かれていなかったことをすべて報告してくれた方のものでした。
まずは CONTRIBUTING.md をご覧ください。このコードベースで誰もがつまずく2つの落とし穴を説明しています。ワーカーのクライアント側コードはテンプレートリテラルの中にあるため、バックスラッシュは2つ重ねる必要があります。また、バッククォートが1つ紛れ込むと、コンパイラーがエラーを報告する箇所から100行も離れたところで文字列が終わってしまいます。
セキュリティ上の問題を見つけましたか? 公開の問題として報告しないでください。 SECURITY.md に非公開の報告フォームがあり、何が対象として主張されているのか、また意図的に対象外としているものは何かを記載しています。
ライセンス
MIT — 詳細は LICENSE をご覧ください。
vnsh.dev · プロトコル · ドキュメント · このような設計にした理由
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。
