Vulcanus について
Vulcanusは、コーディングエージェントと運用者向けのローカルなGit管理Markdownメモリーボルトです。プロジェクト情報をリンクされた階層に整理し、構造を検証して、MCP経由で想起機能を提供します。
主な機能
- 01階層化されたMarkdownプロジェクトメモリー
- 02MCPによる想起と検索ツール
- 03ボルト構造の検証と修復
- 04AI履歴やノートからのインポート
- 05Git対応の同期とコミットフック
活用シーン
- 01セッション開始時にプロジェクト情報を渡す
- 02セッションをまたいで決定事項やルールを記録
- 03チャット履歴からプロジェクトの手掛かりを抽出
- 04コミット前にボルト内のリンクを確認
MCP 対応
`vulcanus serve` MCPサーバーは、想起、検索、決定事項の追記などのボルト操作をMCPクライアントに提供します。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
8掲載時のツール一覧 · 2 週間前に更新
| パラメーター | 型 | 必須 | 説明 |
|---|---|---|---|
| project | string | はい | プロジェクト名、ID、またはトリガーワード |
詳細
Vulcanus
コーディングエージェントは、セッションのたびに何も知らない状態から始まります。 アーキテクチャを説明し直し、すでに決めたことを繰り返し、先週設定したルールを破る様子を見守ることになります。コンテキストはあなたの頭の中と、すでに消えてしまったスクロールバックバッファーの中にあります。
Vulcanus は、その問題を根本から解決します。あなたとエージェントの両方が読める、リンクされた Markdown を Git でバージョン管理する「AI が読み取れるセカンドブレイン」を構築し、MCP 経由で提供するため、エージェントはプロジェクトについて推測する代わりに recall できます。
npm install -g @sunsato/vulcanus
vulcanus
グローバルにインストールしてください。MCP サーバー(vulcanus serve)、スキル、コミットフックはすべて vulcanus コマンドを実行するため、PATH に登録されている必要があります。ちょっと試すだけなら npx @sunsato/vulcanus でも使えますが、エージェントに接続するものからはアクセスできません。

いくつかの質問に答えると、Vulcanus がルーティングレイヤー、オペレータープロファイル、エージェントプロトコル、プロジェクトごとのメモリークラスターを含む vault 全体を書き込み、グラフが実際につながっていることを検証します。すでに Obsidian vault を使っている場合は、別の vault を作成する代わりに、その vault にメモリー構造を追加します。
Node 22.12 以降が必要です。ローカルで動作し、アカウントは不要です。また、任意の 1 日 1 回のバージョン確認を除き、自動的にネットワークへアクセスすることはありません。npm install -g @sunsato/vulcanus@latest でアップグレードできます。
Sunsato の製品 · vulcanus.sunsato.com
プロンプトではなく vault を使う理由
際限なく肥大化する CLAUDE.md を置き換えるのが、このツールです。タスクのたびに全文が読み込まれ、いつの間にか内容が古くなり、記載されていることが今も正しいかどうかを確認する仕組みもありません。
その代わりに、vault はレイヤー構造になっているため、必要な情報だけを取得できます。エージェントは Recall Map を読み、次にタスクで必要な Capsule を 1 つ読み、根拠や詳細が必要な場合にのみ深掘りします。vulcanus stats で自分の vault を測定できます。上のデモでは、タスクに絞った情報取得により、vault 全体を読む場合と比べて読み取り量が 59% 少なくなっています。続いて vulcanus doctor が、すべてのリンクが解決でき、すべてのプロジェクトにアクセスできることを強制的に確認するため、メモリーが気づかれないまま劣化するのではなく、問題があれば明確に検出されます。
エージェントに接続する
vault の価値は、ツールがどれだけ情報を取得できるかで決まるため、それぞれコマンド 1 つで接続できます。
claude mcp add vulcanus -- vulcanus serve # Claude Code, or any MCP client
vulcanus skills --install # skills that run the real commands, in every repo
vulcanus agents # the block to paste into a tool's global instructions
それぞれが提供する機能については、以下のMCP サーバー、スキル、エージェントに実際に使わせるをご覧ください。
作成されるもの
YourVault
├─ AGENTS.md # the protocol AI agents must follow in this repo
├─ CLAUDE.md # points Claude Code at that protocol
├─ USING-WITH-AI.md # how to make every tool recall this vault
├─ README.md
├─ vulcanus.json # the manifest everything is derived and validated from
├─ .claude/skills/ # invocable skills for Claude Code
├─ .agents/skills/ # the same skills for Codex, Cursor, and Gemini CLI
├─ 00_System/ # Index, Recall Map, Admin Profile, Rules, Update Format …
├─ 02_Projects/ # one cluster per project
└─ _imports/ # raw AI exports, ignored by Git
各プロジェクトクラスターは 5 つのノートと、必要に応じて追加する専門ノートで構成されます。
| ノート | 内容 |
|---|---|
Capsule | エージェントが最初に読む、必ず覚えておくべき情報を圧縮した要約 |
Hub | ナビゲーションとクラスターの境界 |
Context | 識別情報、定義、範囲 |
Decisions | 確定した選択と修正 |
Rules | 今後の動作に関する制約 |
Architecture / Flow / Visual Direction / Content Guidelines | 任意の専門分野の詳細 |
レイヤー構造にする目的は、トークンを節約することです。エージェントは Recall Map を読み、次に Capsule を 1 つ読み、タスクで根拠や詳細が本当に必要な場合にのみ深掘りします。
プロジェクトとは何か、誰に伝えてよいか
vulcanus.json の各プロジェクトに設定できる2つの任意フィールドは、ノートでは強制できない情報を持たせます。
| フィールド | 値 | 回答する内容 |
|---|---|---|
kind | umbrella、product、lab、service-brand、client、client-product | このプロジェクトが何であるか。エージェントが分類し、要約できるようにします |
visibility | public、private | エージェントがこのプロジェクトの名前をボールトの外で出してよいか |
init と add project では両方の入力を求めます。また、visibility はどちらの場合も記録されます。「誰も言及していない」と「オペレーターが public と指定した」は異なる状態であり、安全に処理できるのは一方だけです。recall はマーカーを返し、非公開プロジェクトの場合は、公開される内容で名前を出さないよう指示します。doctor は認識できない値があってもボールトをエラーにせず警告します。そうしないと、privte のような入力ミスがすべてのエージェントに public と解釈されてしまうためです。
これはシグナルであり、アクセス制御ではありません。ここでファイルが暗号化されたり、隠されたりすることはありません。
自分で管理するノート
生成されるシステムレイヤーは固定リストなので、システムディレクトリに自分で書いたノートは管理対象外として扱われ、そのノートをリンクする System Hub はリンク過多として扱われます。つまり、何も悪いことをしていないのに2つの問題が報告されます。vulcanus.json の systemNotes で、こうしたノートを指定します。
{ "systemNotes": ["Release Notes", "Semantic Index Strategy"] }
ほかのシステムノートと同様にブランド名が付くため、ブランド設定済みのボールトでは Release Notes は <Vault> Release Notes として解決されます。宣言によってボールトにそのノートの存在が知らされるだけです。ノートが作成されたり、書き換えられたりすることはなく、update も変更しません。System Hub からリンクでき、リンクがなければ sync が項目を追加します。また、宣言したのにまだ作成されていないシステムノートも報告されるため、宣言が何も指さない状態をそのままにできません。宣言されていないシステムノートは、引き続き管理対象外として報告されます。
最初に尋ねるのはインポートについてです
最初に Vulcanus は、既存の AI 履歴を読み込み、そこからプロジェクトツリーを提案します。
| ソース | 読み込む内容 |
|---|---|
| ChatGPT データエクスポート | conversations-000.json … 分割されたバッチ |
| Claude.ai データエクスポート | conversations.json + projects.json |
| Claude Code | ~/.claude/projects/**/*.jsonl |
| Codex | ~/.codex/**/rollout-*.jsonl |
| Gemini CLI | ~/.gemini/tmp/**/logs.json と保存済みの checkpoint-<tag>.json チャット |
| Cursor | ワークスペースごとのチャット履歴(state.vscdb)。組み込みの node:sqlite を使用して読み込みます |
| Markdown フォルダー | 任意のノートディレクトリ。フォルダー名がプロジェクトのシグナルになります |
場所は自動検出されるため、通常は一覧から1つ選ぶだけです。Markdown フォルダーだけは例外で、自動的には検索されず、パスを指定した場合にのみスキャンされます。
同じソースに対して import を再実行すると、新しい項目だけが提案されます。読み込み済みの会話 ID は、ボールトの状態ディレクトリに記録されます。--all を指定するとすべてを再読み込みします。--json は候補とその根拠を出力しますが、何も書き込みません。
履歴の内容は、同意しない限りボールトにコピーされません。 会話はローカルで読み込まれ、根拠の件数とともに候補となるプロジェクト名に絞り込まれた後、破棄されます。チェックを付けた名前だけがノートになり、Import Log に記録されるのはスキャンした会話の件数のみで、会話の内容は記録されません。
ソース自体が会話をグループ化している名前(Claude のプロジェクトやリポジトリのディレクトリなど)は強いシグナルであり、最初からチェックされています。タイトルの出現頻度だけから推測された名前は提案であり、最初はチェックされていません。
すでに決めたこと
履歴には通常、プロジェクト名以上のものが残っています。固めた選択や、繰り返し守ってきたルールも含まれています。プロジェクトのステップの後、import はそれらを探すかどうかを尋ねます(--memory は最初から「はい」と答え、--no-memory は質問を省略し、--memory-only はプロジェクトがすでに登録されている保管庫向けにプロジェクトの検出を省略します)。
- 読み込まれるのはあなた自身のメッセージのみです。アシスタントの発言は、あなたの決定ではありません。
- 文は、英語、トルコ語、ドイツ語、スペイン語の決定やルールを示すフレーズ(「we decided」「from now on」「karar verdik」「ab sofort」「a partir de ahora」など)と照合され、フレーズの強さ、繰り返し登場する会話の数、そして新しさに基づいて順位付けされます。質問とコードは無視されます。
- 会話がプロジェクトに紐付けられるのは、ソースでそのプロジェクトにグループ化されている場合、またはタイトルにプロジェクト名が含まれている場合です。本文中での言及は対象になりません。
- 保管庫にすでに記録されている内容は除外されます。現行の決定を改訂したものと思われる候補は、置き換え案として提示されるため、古い決定は矛盾するのではなく、置き換え済みとして記録されます(決定が変わった場合を参照)。
- 各候補について、決定として承認、置き換えとして承認、ルールとして承認、文言を編集、スキップ、または停止を選べます。1 回の実行でプロジェクトごとに最大 15 件までです。何も確認なしに承認されることはありません。
--jsonと--memory-onlyの組み合わせでは、件数のみが報告されます。 - 承認した内容は、承認時の文言で書き込まれ、
source:: import · <source> · <date>の行が追加されます。スキップした候補は破棄され、確認済みの会話は再度提案されないよう記録されます(プロジェクト検出とは別に記録されるため、どちらかがもう一方の会話を隠すことはありません)。
--ai-extract [cli] は候補の文(トランスクリプトではありません)をインストール済みの AI CLI に渡し、重複をまとめ、ノイズを取り除き、文言を簡潔にします。渡される内容は事前に表示されます。返された内容のうち、渡した文に由来しないものは破棄されます。
コマンド
vulcanus init # create a vault, or add memory to an existing Obsidian vault (default command)
vulcanus status # one-screen vault health: projects, notes, doctor result, git state
vulcanus stats # token budget: what a cold-start agent reads, what recall saves
vulcanus doctor # validate the vault against its manifest
vulcanus add project # add projects and wire them into the graph
vulcanus project remove "Name" # unlink a project; its notes move to _archive/
vulcanus project rename "Old" "New" # folder, notes, and every link, in one move
vulcanus project archive "Name" # mark it archived (--restore undoes it)
vulcanus import # propose more projects from an AI export or a notes folder
vulcanus serve # serve the vault to MCP clients: recall, search, append_decision, …
vulcanus agents # print the block that makes your AI tools use the vault
vulcanus skills # agent skills that run these commands for you
vulcanus update # bring the vault up to date with a newer CLI
vulcanus sync "topic" # validate, then commit and push
vulcanus sync --watch # regenerate and revalidate on every edit; never commits
vulcanus hooks install # a pre-commit hook that refuses to commit a broken graph
vulcanus completion zsh # completion script for bash | zsh | fish | pwsh
init は --lang en|tr|de|es、--ai [cli]、およびターゲットディレクトリを受け付けます。add project と import は --ai [cli] を受け付けます。status と stats は --json を受け付けます。doctor は --repair と --json を受け付けます。import は --source、--path、--ai-group [cli]、--memory、--no-memory、--memory-only、--ai-extract [cli]、--json、および --all を受け付けます。update は --dry-run、--force、--profile core|full、および --json を受け付けます。sync は --dry-run、--json、および --watch を受け付けます。skills は --raw、--install、および --force を受け付けます。
--verbose と --quiet はすべてのコマンドで使えます。--json を指定すると自動的に quiet が有効になり、標準出力は機械可読な出力専用になります。
終了コードは仕様の一部です。0 はコマンドが指示どおりに処理されたこと、1 は保管庫または操作の検証に失敗したこと、2 はコマンドの使い方が誤っていること(保管庫がない、不正なフラグ)、130 はプロンプトでキャンセルされたことを示します。失敗時には必ず、何が起きたか、なぜ起きたか、次に何をすべきかが表示されます。
init のスクリプト実行
ウィザードのすべての質問にはフラグで回答できるため、init は TTY がない環境(CI、コンテナ、エージェントのシェルなど)でも実行できます。フラグを指定すると、対応する質問のみが省略されます。--defaults を指定すると、それ以外の質問にはすべてデフォルトで回答し、--dry-run を指定すると、書き込みを行わずに作成予定のツリーを表示します。
vulcanus init ./vault --name ATLAS --operator Ada --projects "Meridian, Harbor" --defaults -y
vulcanus init ./vault --name ATLAS --defaults --dry-run # look before you leap
すべてのフラグ:--name、--full-name、--tagline、--naming branded|generic、--profile core|full、--operator、--role、--aliases、--projects、--no-import、--git / --no-git、--defaults、--dry-run。
プロジェクトノートの作成
init、add project、importによってプロジェクトを追加するたびに、Vulcanusはノートの内容をどのように作成するかを尋ねます。ここで質問に回答する、自分で後から書くためにスキップする、またはマシンにすでにインストールされているAI CLIに任せる、のいずれかを選べます。
AIを使う場合は、PATHを調べてclaude、codex、cursor-agent(agentとしてインストールされている場合もあります)、geminiを確認し、実際に利用できるものだけを提示します。また、各プロジェクトのソースコードの場所を尋ね、過去にClaude CodeとCodexのセッションを実行したディレクトリを候補として提示します。処理を開始する前に、どのCLIがターミナルを引き継ぐのか、どのディレクトリで実行するのか、どのノートの作成を指示されているのかを正確に伝えます。確認なしに何かが起動することはなく、フラグでその確認を抑制することもできません。
階層、グループ化、作成する専門ノートといった構造に関する簡単な質問は、どちらの方法でもターミナルで尋ねられます。これらの回答によってフォルダー構成と生成されるシステムノートが決まります。ファイルが1つでも作成される前に決める必要がありますが、AIセッションが始まるのはノートが作成されてからです。AIに任せるのは、実際の作業が行われるノート本文の作成です。
CLIには、コードベースを調べ、コードだけでは答えられないことについてあなたに質問し、クラスターのノートをボールトの規約に沿って作成するよう依頼します。セッションが終了すると、すぐにdoctorが実行されます。そのため、グラフを壊す編集があれば、後になってからではなく、その場で報告されます。
エージェントに実際に使わせる
誰にも読まれないボールトはただのフォルダーです。そのため、強制適用レイヤーも同梱されています。
ボールト内で作業するエージェントは、すでに対象になっています。AGENTS.mdにはプロトコル全体が記載され、CLAUDE.mdはClaude Codeにそのファイルを参照するよう指示し、.cursor/rules/vault.mdcも同様にCursorへ指示します。
それ以外の場所(他のリポジトリや通常のチャットなど)では、vulcanus agentsを実行してください。ボールトの名前、パス、管理者を記載したブロックが出力されるので、ツールのグローバル指示に貼り付けます。
| ツール | 設定場所 |
|---|---|
| Claude Code | ~/.claude/CLAUDE.md |
| Codex | ~/.codex/AGENTS.md |
| Cursor | 設定 → ルール → ユーザールール |
| ChatGPT | 設定 → パーソナライズ → カスタム指示 |
| Gemini CLI | ~/.gemini/GEMINI.md |
vulcanus agents --rawを実行するとスニペットだけが出力されるため、そのままファイルに追記できます。生成されるすべてのボールトには、同じガイダンスを記載したUSING-WITH-AI.mdも含まれています。
スキル
指示は文章であり、モデルが従う場合もしない場合もあります。スキルは呼び出せる機能なので、「vault を同期して」と指示すると、モデルが同等の処理を即興で行うのではなく、実際に vulcanus sync を実行します。Vulcanus は、各 vault の操作ごとに 1 つのスキルを作成し、Recall Map → Capsule → Hub → Context/Decisions/Rules のルーティングを備えた recall スキルも作成します。
| スキル | 実行内容 |
|---|---|
<vault>-recall | 何も実行しません — 読み進める順序と、どの情報を優先するかのルールを説明します |
<vault>-doctor | vulcanus doctor を実行し、構造が欠けている場合は --repair も実行します |
<vault>-sync | vulcanus sync --dry-run を実行してから、vulcanus sync "topic" を実行します |
<vault>-add-project | vulcanus add project "Name" を実行します |
<vault>-import | vulcanus import を実行します |
<vault>-update | vulcanus update --dry-run を実行してから、vulcanus update を実行します |
スキルは Agent Skills 形式に準拠しています。各スキルのディレクトリに、name と description のフロントマターを持つ SKILL.md が格納されます。モデルがスキルを使うかどうかは description によって決まるため、それぞれに vault、オペレーター、スキルを呼び出すべき表現が記載されています。
各 vault には、スキルが 2 か所に配置されています。Claude Code 用の .claude/skills/ と、Codex、Cursor、Gemini CLI 用の .agents/skills/ です。これらはすべて、ベンダーに依存しない後者のディレクトリを読み込みます。同じテキストのコピーを 2 つ、vault とともにバージョン管理することで、リポジトリを開いたエージェントは初日から操作できます。スキルの仕組みを持たないツールでは、引き続き文章による手順を使います。これは置き換えではなく、経路を追加するものです。
これは vault の内部で動作するエージェントのみを対象としています。セカンドブレインの目的は、ほかの場所からも情報を想起できるようにすることです。そのためには、スキルをホーム設定に配置する必要がありますが、Vulcanus が許可なくそれを行うことはありません。
vulcanus skills --install
これにより、~/.claude/skills/ と ~/.agents/skills/ にスキルが書き込まれます。また、vault の実際のパスが埋め込まれるため、別のリポジトリにいるエージェントも実行場所を把握できます。Vulcanus が vault の外部に書き込むのはこれだけであり、init の実行中に書き込まれることはありません。また、--force を渡さない限り、既存のファイルはそのまま残ります。vulcanus skills を単独で実行すると、インストールされる内容が説明され、--raw を指定するとファイルが出力されます。
sync はリモートにプッシュし、update はファイルを書き換えます。チャットでの一言に伴う影響としては大きなものです。そのため、どちらのスキルでも、エージェントはまず --dry-run の出力を表示し、その会話内で確認を得るよう指示されています。また、すべてのスキルに、成功を報告するのではなく、コマンドの実際の出力と終了コードを報告するよう指示されています。スキルは管理対象のファイルなので、doctor --repair と update を実行すると、既存の vault にテンプレートの改善が反映されます。
MCP サーバー
vulcanus serve は、場当たり的にファイルを読み取る代わりに、Vault をあらゆる MCP クライアント(Claude Code、Cursor、自作のエージェント実行環境など)向けの構造化されたメモリにします。
| ツール | 内容 |
|---|---|
recall | プロジェクトの Capsule と、プロトコルのエントリーポイントとなる次に読む項目のリストを返し、置き換えられた、または期限切れの決定事項やルールを示します |
search | レイヤーを考慮したテキスト検索です。Capsule と Recall Map の検索結果が上位に表示され、置き換えられたセクションや期限切れのセクションの検索結果は下位に表示され、その旨が示されます |
list_projects | ルーティングテーブルです。名前、ステータス、トリガーワード、Capsule のパスを示します |
append_decision | 確定した決定事項を Decision/Details 形式で記録します。supersedes を指定すると、置き換えられる決定事項にもその旨を記録します |
append_rule | 継続的に適用するルールをプロジェクトの Rules ノートに記録します。supersedes を指定すると、置き換えられるルールにもその旨を記録します |
update_capsule | Capsule のセクションを1つ置き換えます。ファイル全体を無条件に書き換えることはありません |
vault_status | vulcanus status の概要を JSON 形式で返します |
doctor | すべての検出事項を含む、完全な構造検証を行います |
次のように、クライアントに応じた方法で登録します。Claude Code の場合:
claude mcp add vulcanus -- vulcanus serve
Vault 内(または任意のサブディレクトリ)から実行するか、クライアントが別の場所で起動する場合は --cwd を指定します。グローバルに登録しても問題ありません。サーバーはどこからでも起動し、Vault がないディレクトリではサーバーの起動に失敗する代わりに、ツールがその旨を伝えます。マニフェストと Vault の場所は呼び出しのたびに解決されるため、サーバーの稼働中に作成または編集された Vault もすぐに反映されます。
recall は、自身の情報が最新かどうかも正確に伝えます。Capsule がその下位にある Decisions、Rules、または Context より古い場合、古い概要を最新の情報として提示するのではなく、回答に古さを示す警告を付けます。
Obsidian
Vault は作成された時点で有効な Obsidian Vault です。プラグインもインポートも必要ありません。フォルダーを開けば、最短パスの Wiki リンクと、名前の変更に対応するリンクがすでに設定されたグラフが表示されます。
すでに Obsidian Vault を使っていますか?その中で init を実行すると、Vulcanus はその Vault にメモリ構造を追加し、隣に別の Vault を作成しません。現在のディレクトリ、またはその直下のサブディレクトリに .obsidian フォルダーがあれば、自動的に検出されます。検出された Vault が1つなら確認なしで使用され、そのフォルダー名が Vault の識別名になるため、Vault 名を入力する必要はありません。複数の Vault がある場合にのみ、選択を求められます。既存のノートが上書きされることはありません。生成ファイルは何も存在しない場所にのみ書き込まれます。また、フォルダーがすでに Vulcanus Vault である場合、init は停止して add project または update を案内します。
グラフビューはヘルスチェックも兼ねています。プロジェクトはクラスターとして、その中心にはハブとして表示され、リンクされていないノートはすぐに見つかります。Obsidian での編集内容はプレーンな Markdown なので、CLI とエージェントにすぐ反映されます。また、vulcanus doctor によって、手動編集、エージェントによる編集、生成された構造の整合性が保たれます。
最新の状態を保つ
vulcanus.json には、最後に Vault を書き込んだ CLI のバージョンが記録されます。新しい CLI を古い Vault に対して実行すると、doctor が警告し、vulcanus update は次の処理を行います。
- マニフェストのスキーマ移行を実行します
- CLI が管理するファイルを更新し、テンプレートの改善を既存の Vault に反映します
- 新しいバージョンで追加されたノートを作成します(
--profile fullへのアップグレードを含みます) - ジェネレーターのバージョンを再記録し、結果を検証します
ユーザー自身のノートが書き換えられることはありません。update は変更せずに残したノートの数を報告します。これには Index、ハブ、Import Log が含まれます。これらにはユーザーが書いた内容が保存されているため、新しいプロジェクトや、より深いシステムレイヤーは再生成されず、リンクとして追加されます。AGENTS.md はマージされるため、ユーザーが追加したセクションはそのまま残り、プロトコルが追加するセクションも取り込まれます。--dry-run でまず実行計画を確認できます。また、マニフェストに記載されなくなったノートは削除されず、一覧表示されます。より新しい CLI で書き込まれた Vault は、ダウングレードされるのではなく、実行を拒否されます。
コマンドの実行後、CLI は 1 日に最大 1 回 npm を確認し、新しいリリースがある場合は 1 行の通知を表示します。VULCANUS_NO_UPDATE_CHECK=1(または NO_UPDATE_NOTIFIER)を設定するか、CI で実行すると無効になります。オフラインの場合は何も通知せずに失敗します。
検証
vulcanus doctor は、増え続ける Vault の整合性を保つための機能です。各チェックは vulcanus.json から導出されるため、ツリーが変更されても正しく機能します。
- フロントマターの完全性(
type、project、status、tags)と、キーの重複または空欄 - すべての Wiki リンクが解決され、リンク先が必ず 1 つのノートであること
- すべてのハブが、マニフェストで所有すると定められたノートにリンクしていること
- すべてのプロジェクトノートが、それぞれのハブにリンクしていること
- すべてのプロジェクトに、Recall Map からたどれる Capsule があること
- ノート名の重複や、大文字・小文字の違いによる衝突がないこと
- 生のエクスポートと生成された状態が、実際に Git の管理対象から除外されていること
AGENTS.mdが、この CLI が書き込むエージェントプロトコルについて記述しており、以前のものについて記述していないこと.claude/skills/と.agents/skills/にあるスキルのコピーが互いに食い違っていないこと- すべての
supersedes::/superseded-by::リンクが実在する見出しを指し、両側の記述が一致し、循環によって自分自身を置き換えるものがないこと valid-until::の日付を過ぎた決定が、現在も有効なものとして提示されていないこと。また、いずれの Capsule もそのような決定にリンクしていないこと
構造の不足はエラーです。手動で追加された余分なリンクは警告です。Vault は書き加えていくためのものだからです。
決定が変わったとき
正しくなくなった決定は削除しません。それは履歴であり、「なぜ X をやめたのか」という問いには答える価値があります。代わりに、その見出しの下にフィールドを付けて印を付けます。
## Usage-Based Pricing
supersedes:: [[Acme Decisions#Flat Pricing]]
### Decision
Price per active seat.
## Flat Pricing
superseded-by:: [[Acme Decisions#Usage-Based Pricing]]
superseded-on:: 2026-10-05
ある日付までのみ有効な決定には、valid-until:: 2026-12-31 を付けます。キーは Vault の言語にかかわらず英語です。これは文章ではなくフィールドです。同じフィールドはルールにも使用できます。
片方を記述すると、vulcanus doctor --repair がもう片方を追加します。つまり、不足している逆参照を挿入し、それ以外には手を加えません。append_decision と append_rule は、supersedes を指定すると 1 回の呼び出しで両側を書き込みます。対象が存在しない場合、またはすでに置き換えられている場合は、何も書き込まずに拒否します。recall は現在有効でない項目を一覧表示するため、エージェントはそれをスキップできます。search はそれらを最後に順位付けし、vulcanus status はその数を集計します。
vulcanus sync は、エラーが残っている間はコミットを拒否し、プッシュの結果を発生したとおりに正確に報告します。
編集時の安全性
生成ファイルは、次の3種類に分かれます。
- seed — 書き込んだ内容を保持できるすべてのファイルです。各プロジェクトのメモ、Recall Map、Index、すべてのハブ、Import Log が含まれます。一度書き込まれた後は、上書きされません。プロジェクトを追加したり、システムレイヤーを深めたりする場合も、ファイル全体を再生成するのではなく、不足しているリンクだけを適切に挿入します。
- managed — CLI が完全に管理するファイルです。
CLAUDE.md、Cursor ルール、生成されたスキルが含まれます。doctor --repairを実行すると、これらが書き換えられます。 - merge —
AGENTS.mdだけが該当します。これは両方の役割を担う必要があります。すべてのエージェントが読むプロトコルであり、新しいステップを既存の vault にも反映する必要がある一方で、独自の指示を追加できるファイルでもあります。更新時には、既存のすべてのセクションを保持し、プロトコルで追加されたセクションを挿入して、バージョンの記録を更新します。カスタマイズしたセクションの文言の変更は反映されません。カスタマイズが失われるより、そのほうが望ましいためです。
--force は、自分のメモも含め、すべてを書き換えます。そうするのはこのフラグだけです。
Vault の命名
選んだ vault 名が、その vault の識別名になります。デフォルトの branded 命名では、システムメモは ATLAS Index.md、ATLAS Recall Map.md などとなり、vault フォルダーもその名前になります。そのため、Obsidian ではその名前で開きます。持ち運びやすい Index.md / Recall Map.md というファイル名にするには、generic 命名を選んでください。
生成される vault は Obsidian ですぐに使える状態です。最短形式の Wiki リンク、名前変更に追従するリンクが使われ、ワークスペースファイルは Git の対象外に保たれます。
開発
npm install && npm run build && npm test
npm run dev -- doctor
ソースの構成:manifest/ はすべてのパスとリンク要件を導出し、generate/ はその計画を Markdown に変換し、doctor/ は同じ計画に照らして結果を検証します。importers/ は AI のエクスポートを正規化し、mcp/ は serve が公開するトランスポートに依存しない vault 操作を格納し、commands/ はそれらを CLI に接続します。
CONTRIBUTING.md では、チェック項目、レビューの基準、インポーターや言語の追加方法について説明しています。docs/token-budget.md では、レイヤー構造によって実際にどれだけ節約できるかと、その測定方法を説明しています。
vulcanus.sunsato.com のランディングページは site/ にあります。Cloudflare Workers が静的アセット(wrangler.jsonc)として配信する、単一の静的ファイルです。リリースは段階的な昇格フローを経て本番環境に反映されます。各リリースを一度だけパッケージ化し、検索エンジンから除外した webtest 用コピーでテストした後、承認を得て、そのテスト済みパッケージだけを公開します。リリースでは公開前に CI マトリックス全体を実行し、公開後にはスモークテストを実施します。詳細はCONTRIBUTING.mdをご覧ください。
ライセンス
MIT © Sunsato
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。