myc

myc

コーディングエージェント向けのローカルで高速なタスク・メモリレイヤーです。タスクキュー、事実や決定事項を記録する oplog、プロジェクトのメモリを対象としたハイブリッド（語句＋ベクトル）検索、組み込みのコードインデックスを備えています。独自のネットワーク通信は行わず、LLM キーも必須ではありません。ネットワークに接続するのは、要求されたときだけです。たとえば、myc models fetch、myc code fetch、myc version --check（または MYC_UPDATE_CHECK=1 を設定した場合の、init と wire からのバックグラウンドバージョンチェック。1 日に最大 1 回）です。

エージェントは忘れます。myc は忘れません。決定事項はコンテキストの圧縮後も残り、作業はプロセスの終了後も残ります。また、どちらも通常の git を使ってマシン間で移動できます。

設計ドキュメントは docs/design/ にあります（まずは 00-brief.md をご覧ください）。以下に記載した測定値は、bench/ と scripts/ から再現できます。

サイト：https://aistastudio.github.io/myc/ — 各機能について、搭載されたリリースとその機能を表示するコマンド、ロードマップ、グラフ化された測定値を掲載しています。英語とロシア語に対応し、それぞれの数値の横に再現用コマンドを記載しています。数値の唯一の参照元です。bun run site/build.ts は、サイト上のすべての数値と、このリポジトリの測定成果物との整合性、README とロシア語版に記載された数値とサイトの site/measurements.json との整合性、さらにサイトおよび両方の README にあるすべての myc コマンドとフラグと、このビルドの --help との整合性を検証します。不一致があるとビルドは失敗します。

ネイティブバイナリ — Bun はフォールバックとして利用

myc の内部エンジンは引き続き Bun です（bun:sqlite を使用し、Node 側にネイティブバインディングはありません）。ただし、0.6.0 以降は実行に Bun をインストールする必要がありません。npm install -g @aistastudio/myc で、お使いのプラットフォーム向けのネイティブバイナリ（Windows x64、macOS arm64/x64、Linux x64/arm64）がインストールされ、ランチャーに必要なのは Node ≥ 18 だけです。Windows では、実機での確認が済むまでバイナリは実験的です。Windows では引き続き WSL が完全にサポートされている方法です。

Bun が引き続き必要な場合。 パッケージには、myc 全体をまとめた 1 つの JS バンドルも含まれています。プラットフォーム用バイナリがインストールされなかった場合、ランチャーは Bun でバンドルを実行します。重要な保護機能は、どちらの実行方法にも適用されます。ネイティブバイナリは自動ロードを無効にしてビルドされ（--no-compile-autoload-dotenv／--no-compile-autoload-bunfig）、バンドルには argv で --no-env-file／--config が渡されます。myc が起動元プロジェクトの .env や bunfig.toml を読み込むことはありません（cherry incident では、myc run がワークツリーの .env から EXPO_PUBLIC_* を 20 個テストに渡していました）。

SQLite ≥ 3.50.4。 最低バージョンを定めている理由は 2 つあります。3.44.0 より古いバージョンでは、trusted_schema = OFF の状態で FTS5 にトリガーから書き込めないため、すべての書き込みが失敗します。また、3.43.2 と 3.46.0 では、並行して動作する myc プロセスが 1 つのバックグラウンドジョブを 2、3 回実行し、ジョブが失敗した際に「database disk image is malformed」と報告することが測定で確認されています。原因は不明なため、myc はサポート対象の環境で提供されるバージョンより古いライブラリをすべて拒否します。サポート対象の環境で機能が損なわれることはありません。Linux では Bun が同梱する SQLite（Bun 1.3.0 では 3.50.4、engines.bun の最低バージョン、Bun 1.3.14 では 3.53.0）を使用します。macOS では Bun がシステムの SQLite（macOS 14 では 3.43.2）を使用するため、パッケージに独自のものを同梱しています。arm64 と x86_64 向けに公式の amalgamation からビルドした SQLite 3.53.4、vendor/sqlite/libmyc-sqlite3.dylib です（scripts/build-sqlite.ts）。明示的に MYC_SQLITE=/path/to/libsqlite3.dylib が指定された場合を除き、ほかのものより優先して選択されます。使用中の SQLite が 3.50.4 より古い場合（インストールの破損、未サポートの Bun、または古いライブラリを指す MYC_SQLITE など）、myc init を含むすべてのコマンドは、書き込みできないワークスペースを作成する代わりに precond.sqlite_unsupported を返して、対処方法を示します。3.50.4 以上 3.51.2 以下では myc は動作しますが、警告（WARN degraded.sqlite_old）を表示します。この範囲がキューに対して安全だとは証明されていません。Linux では bun upgrade で解決できます。myc doctor では、使用中の SQLite とその入手元を確認できます。

Bun をインストールする：https://bun.sh

インストール

インストールは1つのコマンドで完了します。

bun install -g @aistastudio/myc   # 5.11 MB compressed, 15.83 MB unpacked, 16 files; no models pulled
myc --version                     # myc 0.6.7 (schema 1)

Windows。 npm install -g @aistastudio/myc を実行すると、ネイティブの x64 バイナリがインストールされます（ランチャーには Node ≥ 18 が必要です）。実機で確認されるまでは実験的な対応です。WSL は引き続き完全にサポートされている方法です。WSL 内では Linux と同じようにすべて動作します。

埋め込みモデルはインストール時にはダウンロードされません。セマンティック検索はオプトインで、明示的に有効化します。myc models fetch（129 MB、約7秒）を実行してください。それまでは検索は語彙ベースで行われ、すべての回答でその旨が示されます（WARN degraded.embeddings）。コードインデックス用の文法も同じ方法で一度だけ取得します。myc code fetch を実行してください。

公開済みリリースではなく最新のコードを実行するには、ソースからビルドします。

git clone https://github.com/aistastudio/myc && cd myc
bun install
bun run build          # produces a single binary: dist/myc
./dist/myc --version

バイナリは、myc wire が見つけられる場所に配置してください。MYC_BIN、node_modules/.bin、~/.myc/bin/myc、または PATH が該当します。見つからない場合、wire は起動できない設定を黙って書き込まず、その旨をはっきり通知します。

クイックスタート

2つのコマンドでプロジェクトをセットアップできます。それ以降は、エージェントが日々実行する一連の作業です。（ソースからビルドした場合は、myc の代わりに ./dist/myc を使います。）

myc init                     # .myc/ + SQLite + migrations in this repo
myc wire                     # hooks + MCP for Claude Code, Codex, opencode, Kimi, mcode and mimo
myc ready --claim            # take the next task
myc show <id>                # all that is known about it
myc close <id>
myc remember "why X, not Y"  # record a fact or decision
myc recall "how retrieval works"
myc prime                    # session context packet (agents call it)
myc code fetch               # grammars for this repo's languages, once
myc code index               # symbols, callers, code search
myc doctor                   # schema, counters, hooks — says "don't know" where it doesn't

コマンドの一覧は myc --help、各コマンドの詳細は myc <command> --help で確認できます。

エージェントの接続

myc wire は自身のファイルのみを完全に書き込み、JSON 設定はノード単位でマージして、隣に .myc.bak を作成します。CLAUDE.md には触れません。2 回実行しても変更はありません。プレーンな wire より先のすべてはオプトインです。

myc wire --dry-run              # show every change, write nothing
myc wire --agents claude,codex  # only some of the agents
myc wire --status-line          # + myc's status line under Claude Code's prompt
myc wire --queue-hook           # + heavy commands take turns (below)
myc wire --agents-md            # + the myc block in AGENTS.md
myc wire --scope user           # the same for agents in git worktrees (Claude Code's user layer)
myc wire --scope user --agents claude,opencode  # + opencode's global config
myc unwire                      # remove what wire put in

git worktree 内のエージェント。 myc wire はプロジェクトに次のファイルを書き込みます。 .claude/settings.json、.mcp.json。orca がネストされたリポジトリの git worktree（~/orca/workspaces/<repo>/<branch>）内で起動するエージェントはチームのツリー内にありますが、そこにはこれらのファイルがありません。一方、myc 自体はそこからメインコピーのワークスペースを見つけられます。myc wire --scope user を指定すると、Claude Code のユーザーレイヤーに同じ設定を書き込み、すべてのセッションから読み込まれるようになります。 ~/.claude/helpers/myc-hooks.mjs、~/.claude/settings.json 内の SessionStart/PreCompact/PostToolUse フックと Bash(myc <command>:*) ルール（ノード単位でマージされます。orca、herdr、その他のツールのフックはバイト単位でそのまま維持されます）、~/.claude/skills/myc のスキル、および claude mcp add --scope user による MCP サーバーです。ヘルパーは何よりも先に、myc を起動せずに、ここにワークスペースがあるかどうかを確認します（git worktree の場合はメインコピーをたどって解決します）。ワークスペースがない場合、またはプロジェクト自体が myc を設定している場合は、何も出力しません。myc のないプロジェクトではフックによるノードの起動は 1 回だけで、prime が二重に届くことはありません。ワークスペースの外では、MCP サーバーはツールも指示も一切提供しません。ここでは --hook-mode replace は拒否されます。ジャーナルは ~/.myc/wire-user.json です。myc unwire --scope user は設定をノード単位で復元し、MCP サーバーを削除します。

このような worktree 内の opencode も同じ状況です。--agents opencode （または claude,opencode。--agents を指定しない場合、ユーザーレイヤーは Claude Code のみです）を指定すると、グローバル設定（$XDG_CONFIG_HOME/opencode または ~/.config/opencode）が接続されます。 myc サーバーは opencode 自身が独自の設定として扱う opencode.json[c] の mcp に、1 つのノードとして追加されます。ファイルは JSONC で、その他のエントリー、コメント、末尾のカンマはバイト単位でそのまま維持されます。また、plugin/myc.ts がその隣に配置されます。opencode は開かれたディレクトリでそのサーバーを起動するため、myc mcp は worktree からワークスペースを自動的に見つけます。プラグインはヘルパーと同じ確認を、プロジェクトごとに 1 回、myc を起動せずに行います。ここにワークスペースがない場合、またはプロジェクトが opencode 自体を設定している場合（mcp.myc を含む opencode.json、または .opencode/plugin/myc.ts。opencode は両方のレイヤーのプラグインを読み込み、プロジェクトの mcp.myc がこちらを上書きします）は、フックを一切登録しません。myc unwire --scope user はそのノードとプラグインだけを削除します。

--status-line を指定すると、ユーザーレイヤーには myc のステータスライン myc statusline --scope user も追加されます。myc のワークスペース内（git worktree も含む）では完全な行を出力し、ワークスペースの外では何も出力しません。既存の行（何も出力せず、入力を orca に送る orca の行）は、コマンドには含めずジャーナルに保存され、再描画のたびに同じ標準入力が渡されますが、完了を待つことはありません。orca は自身の行として、コマンドに agent-hooks/claude-statusline.sh が含まれる行を認識してアンインストール時に削除するため（他のツールの行はそのまま残します）、こちらには claude-statusline という語が含まれることはありません。プロジェクトに独自の myc の行がある場合はそれを維持し、その行から同じ記録済みの行に入力が渡されます。wire 後に別のツールがユーザーの行を置き換えた場合、myc doctor --hooks が通知します。myc wire --scope user --status-line を実行するとこちらの行が復元され、新しい行が以前の行になります。また、myc unwire --scope user を実行すると、以前の行がバイト単位でそのまま復元されます。myc doctor --hooks はジャーナルと照合してユーザーレイヤー全体を確認します。具体的には、~/.claude/settings.json に myc のフックエントリーとルールが残っていること、ヘルパーがこのビルドによる書き込み内容と完全に一致すること（古いものには書き込み元のビルド名が示されます）、ステータスライン、MCP サーバー、さらに opencode が接続されている場合はそのプラグインと mcp.myc を確認します。

重いコマンドを順番に実行する

同じマシン上の複数のエージェントが、同じツリー内または隣接するプロジェクトで、それぞれ重い処理、つまりテストスイート全体の実行、ビルド、ベンチマークを行います。同時に実行すると互いに干渉し、実行時間が倍になったり、コードではなく隣の処理が原因でレイテンシの予算を超えたりします。myc run は、マシンユーザーのすべてのリポジトリで共有される 1 つのキュー（~/.myc/queue.db）にそのようなコマンドを入れ、空きスロットができるまで（先着順で）待ってから、ターミナルと終了コードをそのままにして実行します。

myc run -- bun test              # waits its turn (--max-wait 5m by default), then runs
myc run --max-wait 15m -- make   # a longer wait for a longer tool timeout
myc queue                        # who is running, who is waiting, for how long

$ myc queue
heavy · slots 1 · 1 running · 1 waiting · ~/.myc/queue.db
  running #1      4s  bun test  ~/src/api  session 6468c59d · orca term_efe4850f · pid 44815 · command pid 44827
  waiting #2      3s  bun run build  ~/src/web  session 6468c59d · orca term_efe4850f · pid 44850 (#1 in line)

待機中のコマンドは、誰を待っているかを標準エラー出力に表示します。--max-wait を過ぎると、終了コード 9 で諦め、前に何があるかを表示します。

myc run: waiting for a 'heavy' slot (1/1 busy, 1 waiting ahead), waited 0.0s of max 3s — held by 'bun test' in ~/src/api, session 6468c59d, orca term_efe4850f, pid 44815, running 13s

ホルダーが終了すると、たとえ SIGKILL による終了でも、スロットは解放されます。別の myc run の中で実行された myc run は、親のスロットで即座に実行されます。デフォルトではレーンごとに 1 スロットで、2 スロットにするには MYC_HEAVY_SLOTS=2 を設定します。myc はプロジェクトの .env や bunfig.toml を読み込まず、コマンドには呼び出し元の環境がそのまま渡されます。

エージェントがこれを覚えておく必要はありません。 myc wire --queue-hook は、実行前に重い Bash コマンドを myc run -- <the same command> に書き換える Claude Code PreToolUse フックをインストールします。重いコマンドとは、テスト全体の実行やビルドを指します。具体的には、パス指定のない bun test、bun run build ／ typecheck、npm ／ pnpm ／ yarn の test と build、cargo test ／ build、go test ./...、パス指定のない pytest、make です。対象を絞った bun test <path>、すでに myc run の下で実行されているコマンド、バックグラウンドコマンド、ネストしたコマンドは変更されずに通過します。MYC_QUEUE_HEAVY でリストを置き換えられます（+… で追加し、off でフックを無効にします）。これはオプトイン方式です。フラグなしで wire を実行してもこのフックは書き込まれず、unwire で削除されます。Bash 呼び出しのたびに実行されるため、処理は軽量です。重くないコマンドは bun や node を起動せず、ホスト独自のシェルから実行されます。2026-09-11 の実行では、中央値で 3.4 ms、p99 で 4.3 ms でした。prime フックの p99 予算 30 ms と比べても短い値です（bun test packages/cli/src/hooks/queue-hook.multiprocess.test.ts）。

myc run は権限を回避する手段ではありません。 渡されたコマンドをそのまま実行するため、キューに入れたコマンドが確認なしで実行されるのは、元のコマンドも自分のルールで許可されている場合に限られます。たとえば Bash(bun test:*) があれば、キュー内の bun test も確認なしで実行されます。それ以外の場合は Claude Code が確認を求め、確認画面にはコマンド全体が表示されます。元のコマンドに対する拒否ルールや確認ルールも引き続き適用されます。エージェントが自分で入力した myc run -- <cmd> にも同じことが当てはまります。同じ理由から、wire は広範な Bash(myc:*) を書き込みません。代わりに myc のサブコマンドを 1 つずつ許可し、run、statusline --then、wire、unwire では確認を求めます。

コードインテリジェンス

コードインテリジェンスは組み込みで、代替ツールと同じエンジンを使用しています： オンデマンドで文法を取得する tree-sitter です。シンボル、呼び出し元、コード検索は、myc に定義ルールがある TypeScript、TSX、JavaScript（js、jsx、mjs、cjs）、Python、C#、Java で機能します。文法パッケージには36個の文法が含まれます。言語はルールとカタログエントリのペアとして追加されるため、シンボルを生成できない文法が提示されることはありません。それ以外のすべてのファイルでも、code grep、アンカー、鮮度確認を利用できます。

myc code fetch は、このリポジトリ内のファイルに必要な文法だけをダウンロードし、sha256 で検証します。ネットワークに接続するのはこの手順だけです。インデックス作成ではネットワークに接続せず、文法が不足している言語はスキップされ、その名前が表示されます。myc code index はインデックスを段階的に作成します。変更のないツリーに対して再実行しても何も読み込まず、その後インデックスはバックグラウンドで更新されます。以下は CLI からも MCP 経由でも読み取れます：

myc code symbol <name>   where it is defined, and what knowledge is anchored there
myc callers <name>       who calls it; --direction out, --depth all
myc code search "…"      by meaning, when you do not know the name
myc code grep "<lit>"    exhaustive, every occurrence; --in <path> narrows it
myc code map             orientation: directory clusters, their hubs, who depends on them
myc skeleton <file>      the file's API, and how many times cheaper that was than reading it

ファイル一覧には git 独自の一覧（git ls-files）を使用するため、.gitignore が適用されます。git のないツリーは走査され、その旨がコマンドに表示されます。どの一覧を使う場合でも、.gitignore の設定にかかわらず、秘密情報を含む名前のファイルはインデックスに登録されません：.env と .env.*（.env.example などのテンプレートはインデックスに登録されます）、*.pem、*.key、キーストア、SSH の秘密鍵、.npmrc、.netrc などの認証情報ファイルです。code index はこれらの数を名前を表示せずに数え、code grep は読み取りを拒否します。

ネストされたリポジトリと git worktree。 ワークスペースは、独立したリポジトリ（サブモジュールではありません）を内部に含む git リポジトリのルートという、エコシステムを構成できます。コードインデックスは1つで、ルートから作成されます。ファイルごとに1行で、messaging-server/server/src/x.ts のようなパスになります。ネストされたリポジトリ内から実行したコードコマンドは、ルートインデックスのうちそのリポジトリに該当する部分を基に回答し、パスは現在のリポジトリからの相対パスになります。ルートからの回答は変わりません。ネストされたリポジトリ内で実行した myc code index は、同じファイルの別コピーを作成するのではなく、ルートインデックス内のその部分を更新します。インデックスは自動的に最新状態も保ちます。myc のコマンド実行後、最後の実行から15分以上経過している場合（MYC_CODE_INDEX_PERIOD_MS）、ワークスペースごとにバックグラウンドの code index が1つだけキューに登録され、コマンドを遅らせることなく、低優先度でデタッチ実行されます。ステータス行とコードコマンドには、更新中、キュー登録済み、または古い状態であることが表示されます。ワークスペースツリーの外にある場合も含め、git worktree への回答にはメインチェックアウトのインデックスを使用します。ブランチごとのインデックスはありません。worktree が別のコミットにある場合、または追跡対象ファイルに未コミットの変更がある場合、行や範囲がファイルと一致しない可能性があるため、すべての回答に両方のブランチ名を含む WARN code_index.worktree_divergent が付与されます。code grep は worktree のファイルを読み取ります（行番号は現在のファイルのもの、所有シンボルはインデックス由来です）。skeleton は、現在のコピーがインデックスで確認した内容と異なる場合、メインコピーの宣言を表示し、その旨を伝えます。リポジトリをカバーするものがない場合、ヒントには重複を作成してしまうコマンドではなく、ワークスペースルートで実行するコマンド（myc -C <root> code index）が示されます。ルートから設定したアンカーとリポジトリ内から設定したアンカーは、別々のキーで保存されます。code symbol は両方を読み取ります。

アンカーは知識をコードの範囲に結び付け、コードの移動に追従します。この部分は言語に依存せず、TypeScript と同様に Python でも検証されています。

コードがアンカーの示す場所になくなっても、知識は削除されず、順位が下がり、その理由が示されます。recall は行に [code moved ×0.64]、[code unverified ×0.5]、または [code gone ×0.2] のマークを付けます。乗数はスコアが下げられた倍率です（ずれ × 類似度、古い状態 × 0.5、消失 × 0.2）。すべてのアンカーが失われた知識は prime に含まれず、フッターにその件数が表示されます：N with code gone hidden。

beads からの移行

cd <beads-project>
myc init
myc import-beads --dry-run   # count what would come over, change nothing
myc import-beads             # collects the snapshot itself: bd export --include-memories

後で再度実行すると、2つ目のコピーを作るのではなく同期されます。beads で変更されたフィールド（ステータス、優先度、ラベル、クローズ理由、親、ブロッカー）は通常のグラフ変更として適用され、ローカルの myc の編集が黙って上書きされることはありません。片側だけのローカル変更は保持され、名前が付けられます。両側で変更されたものは競合として名前が付けられ、そのまま残されます。スナップショットファイルはマシン間で同じように移動できます。 bd export --include-memories > snapshot.json を実行し、続けて myc import-beads snapshot.json を実行します。

これはデモではなく、実際に動作します。 空のワークスペースに実際のプロジェクトをインポートしたところ、889 ms で完了しました。タスク 796 件、依存関係 972 件、メモ 265 件、メモリー 41 件が対象でした。未知の課題タイプはそのまま引き継いで名前が付けられ、範囲外の優先度はクランプされて名前が付けられるため、異常な行が1つあってもインポート全体が中断されることはありません。これらの数値は最初のリリース（0.1.1、2026-09-07）のものです。その実行ではエクスポートのコメントが黙って破棄され、すべてのメモがインポート済みと報告されていました。実際のプロジェクトで翌日に発見され、0.2.0 で修正されました（git show aac5d1f）。現在のインポートで引き継がれるものは次のとおりです。

• コメントは作成者とともにノードのスレッドに取り込まれます。未知のトップレベルフィールドは破棄されず、名前が付けられます（0.2.0）。
• 受け入れ条件と設計は、管理対象マーカーの間のタスク本文に取り込まれます。また、ソース独自の日付、作成者、担当者も引き継がれます（0.3.3）。
• deferred のように myc に名前がないステータスは、元の語を保持したまま blocked として扱われます。open として扱われることはありません（0.3.3）。
• 共有ワークスペースのサブリポジトリは、それぞれ独自のリポジトリ範囲を持ちます。空のソースの場合は、何もせずにゼロ件として扱うのではなく、ヒント付きで拒否されます（0.3.3）。

同じグラフで、現在はどちらのレディーキューも同じ 152 件のタスクを返します。以前はそうではありませんでした。beads では親の階層をたどってブロッカーが引き継がれていましたが、myc はタスク自身のブロッカーだけを見ていたため、myc は 195 件を提示し、beads は 144 件を提示していました。この差の 51 件は、まだブロック中のエピック内にあり、beads が正しく非表示にしていました。memory-atcm254ry6c7 はクローズされ、anc_blockers はトリガーによって具体化されます。キューは今では、提示を黙って行うのではなく、281 blocked (51 through an ancestor) と表示します。

異なる点

速度は最適化ではなく、制約です。 すべてのホットパスに予算があり、予算テストでは3種類の条件を検証します。構造的な条件（クエリプラン、プリフィルター）、相対的な条件（意図的に劣化させた対照との健全な経路の比較。ハードウェアの影響を相殺するため交互に測定）、絶対的な条件です。すべてのプッシュで、CI は最初の2つをチェックします。絶対予算と p95 の15％回帰ラインは darwin-arm64-14 で調整され、同環境に適用されます。CI と夜間実行では GitHub の4コアランナーを使用しますが、これはそのマシンではなく、未調整と宣言されています（MYC_BENCH_ABSOLUTE=0）。そのため、そこでの絶対値は出力・記録されますが、強制されません。2026-09-11 に darwin-arm64-14、myc 0.3.6 でノード 100,000 件を使用して測定した値です。それ以降は再測定されていません（bun run scripts/bench-latency.ts）。

操作	p99	予算
prime（セッションコンテキスト）	0.608 ms	30 ms
読み取り	0.010 ms	3 ms
検索	8.215 ms	25 ms
書き込み	0.327 ms	5 ms
コールドスタート	21.337 ms	60 ms

ランキングは主張ではなく、測定によって評価します。 関連度に段階を設けたラベル付きコーパスを2つ使用し、それぞれに、機能が有効な場合に悪化する対照群を含めています。これにより、コーパスを調整して性能向上を作り出すことはできません（どちらも 2026-09-10 に再測定済みです）。

• ブースト（優先度、新しさ、レイヤー）：MRR@10 0.520 → 0.867（bench/boost-eval.ts）
• 2ホップまでのグラフ展開：MRR@10 0.193 → 0.422（bench/graph-eval.ts）。さらに、1ホップでは到達できないクエリグループは 0.000 → 0.333 になります。

気付かないうちに古くなることのないキャッシュ。 結果、埋め込み、ハイドレーションのキャッシュは、データベースから読み取った MAX(oplog.seq) によって無効化されるため、別プロセスによる書き込みもキャッシュを無効化します。キャッシュヒットはミスより2桁も低コストです。2026-09-07 の実行では252倍、埋め込みでは約27,000倍でした。この比率は実時間に基づくため、マシンによって変わります。ランキングは変わりません。小数第3位まで同じ MRR で、順位の差はゼロです。 コンテキストの圧縮後もメモリは保持されます。 myc wire は圧縮前フックをインストールします。エージェントのコンテキストが圧縮される直前に、セッションのエピソードがディスクに書き込まれます。生のまま、L0、acl private の状態で、シークレットはマスクされます。そして、圧縮後も残るコンテキストにレスキューパケットが出力されます。蒸留はキューに追加されますが、書き込み処理中には行われません。ほかの処理を試みる前にエピソードはディスクに保存されるため、フックのタイムアウトを超過しても失われるのは要約だけで、記録は残ります。

$ myc absorb-session --reason manual --transcript … --agent claude
# myc: context is being compacted — here is what must not be lost
episode sess-5jh8je4g050m saved (265 B)
NEXT     myc show sess-5jh8je4g050m · myc ready --claim

圧縮から抽出された決定事項は事実ではなく、候補です。 同じフックが、トランスクリプトから「we decided / because」の行を取り出して候補として保存します（state pending_review）。誰かが確認するまで、recall、search、prime、MCP は候補を返しません。prime はフッターに候補を表示します — N pending review hidden — myc review。また、myc review はこのセッションの候補を先頭にして一覧表示し、人またはエージェントが判断できるようにします。確認すると、新しいノートが作成されるときと同じように候補がナレッジになります（埋め込みと分類処理がキューに追加されます）。却下すると、理由をノードに残したまま候補が取り消されます。エージェントも MCP 経由で同じ操作ができます。review を指定した myc_ready で一覧表示し、confirm または reject を指定した myc_update で判断します。ウェブのナレッジベースでは、候補の行にこの2つのボタンが表示されます。

$ myc review
PENDING REVIEW 2 · 1 in this session's prime · 1 from other sessions · session 3f9c21aa
$ myc review confirm memory-6k2x…
$ myc review reject memory-9x1q… --reason "restates the task, not a decision"

取り消されたノート（却下された候補を含みます）は、置き換えられたバージョンだけでなく、あらゆる検索経路から除外されます。superseded、retracted、cancelled は、recall、prime、ステータス行で共有される1つのリストです。

エージェントには見えない情報を表示するステータス行です。 myc wire --status-line は、Claude Code のプロンプトの下に1行を表示します。コンテキストの使用状況、タスクキュー、コードインデックス、プロジェクトのメモリ、そしてこのセッションで myc を呼び出した回数のうち、実際に結果が返された回数を示します。

myc │ ctx 42% │ 61 ready · 34 blocked │ 612 files · 4268 symbols · 1h ago │ 101 notes │ 600/653 useful calls

「有用」かどうかは推測ではなく、ホスト自身のトランスクリプトに基づいて数えられます。エラー、拒否、空の回答は呼び出しではありますが、有用な呼び出しではありません。これはオプトイン方式です。フラグを付けずに wire を実行した場合、statusLine には一切触れません。また、以前からある行を置き換えることもありません。以前のコマンド（別のツールが利用しているステータス行）には、引き続き同じ入力が渡され、待機や強制終了もされません。2026-09-10 の実行では、レンダリング時間の中央値は34ミリ秒でした。

メモリはセッションごとに分離され、その分離が見えるようになっています。 すべてのノートには適用範囲があり、session（この会話）または project（全員）のいずれかです。自動コンテキストパケットの prime に含まれるのは現在のセッションのノートだけです。別のエージェントのセッションが、あなたのセッションに漏れることはありません。明示的に myc recall を実行した場合は引き続き見つけられます。ナレッジを隠すことと、適用範囲を設定することは同じではないためです。また、それぞれの行には適用範囲が示されます。ses は自分のセッション、ses* は他の人のセッション、prj はプロジェクト全体です。

$ MYC_SESSION_ID=s1 myc recall "retries"        $ MYC_SESSION_ID=s2 myc recall "retries"
… prj  project note: retries use jitter          … prj  project note: retries use jitter
… ses  session note: retries back off…           … ses* session note: retries back off…
3 of 3 · bm25 only · …                           3 of 3 · bm25 only · … · 2 from other sessions

メモリには互いに独立した3つの軸があり、何が隠されたかは表示されます。tier（プロジェクトか個人か）、セッションの適用範囲、リポジトリの適用範囲です。prime は結果を黙って絞り込むのではなく、N from other sessions hidden と N notes from other repos hidden を出力します。

劣化は明示されます。 暗黙のフォールバックはありません。ベクトル検索の分岐が利用できない場合はその旨が出力され、回答には語彙検索のみであることが示されます。予算を超過した場合は、超過した数値とともに明示されます。劣化した回答が正常な回答と見分けられなくなってはならない、というのが不変条件です。--strict を指定した場合、劣化した回答は終了コード0ではなく6で終了し、それでも WARN 行は出力されます。

通常の git を使った複数マシン間の同期では、フィールドごとにマージされます。 コミットされるのは oplog だけです。2台のマシンで同じノードを編集した場合も、変更は統合されます。一方がタイトルと優先度を変更し、もう一方がタイトルとタグを変更した場合、同期後は、後から変更されたタイトル、1台目の優先度、2台目のタグが両方のマシンに反映されます。レコード全体に対する最終書き込み優先によって、変更が失われることはありません。 ガードはミューテーションテストで検証します。 すべての拒否動作と不変条件には、それを取り除くミューテーションが付随します。取り除いてもテストが失敗しないガードは、存在しないものとして扱います。テストスイート全体：4312 成功／7 失敗／16 スキップ （bun test、2026-10-18。インストール済みの Orca.app のチャンクに対する orca ステータス行分類器、クリーンな main でも失敗する federation の R3 ファミリー（memory-j4dkmcs2k7y1）、およびテストスイートを最大並列負荷で実行した際に発生するベンチマークとマルチプロセスの不安定なテストが 1、2 件。これらは単独では常に成功します）。

myc でできること

リース、依存関係、親チェーンをたどって継承されるブロッカーを備えたタスク。圧縮後も保持され、セッションとリポジトリのスコープに限定されたメモリ。ランキング付きハイブリッド検索。上記のコードインデックス。4 つのエージェント向けのフックと MCP。負荷の高いコマンド向けのマシン全体のキュー。ステータス行。beads からのインポート。ローカルウェブインターフェース（myc viz：グラフ、キュー、ボード、カード、検索、ヘルス。編集は CLI と同じ書き込み経路を通ります）。Git ワークツリーとネストしたリポジトリ。トークン、ロール、ACL を備えた Postgres 上のチームサーバー（myc serve。下記参照）。git またはそのサーバーを介した同期。そして、申告内容を再集計結果と照合する doctor。

各機能について、導入されたリリースと、お使いのマシンでその機能を確認できるコマンドを記載した全リスト（サイトのビルド時に各コマンドをこのビルドの --help で検証します）は、サイトにあります： https://aistastudio.github.io/myc/#features。

ロードマップ

各マイルストーンの進捗状況（プロジェクト独自のトラッカーにある各エピックのサブタスクの完了数／総数と、その中で未完了のタスクすべて。日付なし）は、サイトにあります：https://aistastudio.github.io/myc/#planned。件数を手入力しているわけではありません。リリース前に bun run site/roadmap.ts が myc から読み取り、サイトのビルド時には、トラッカーで未完了ではなくなったタスクを計画が記載している場合、ビルドを拒否します。

要約すると、コア、メモリ、セマンティクス、人間向けインターフェース（M0～M2、M7）は完了またはほぼ完了しており、すべての CLI と MCP の行を英語で出力する機能も同様です。コードインテリジェンス（graft を置き換える組み込み機能を含む M3）と負荷の高いコマンド向けキューはリリース済みですが、未完了のタスクが残っています。チーム向けマイルストーン（M4：myc serve、ACL、ネットワーク同期、Postgres）は構築済みで稼働中です。15 件中 10 件のタスクが完了しており、残るのは独自の受け入れテスト（1 台のサーバーで 2 人と 4 つのエージェントが 1 週間使うこと）、Postgres でのハイブリッド検索、SSE デルタ、leader と full の MCP プロファイル、大規模な SQLite から Postgres への移行です。群れの自己学習（M5：コストと結果に基づくルーティングと、エージェント統計の共有プール）と蒸留（M6）は未着手です。

実際のところ、これは次の意味です。myc はまずローカルツールであり、チームサーバーはその次です。そして、この 2 つは同じものではありません。 すべての機能は git 内のファイルを使ってローカルで動作します。サーバーは存在し、実際に稼働する Postgres を使ってテスト済みで、以下で説明します。ただし、CLI の一部しかサーバーと通信しません。残りは、別の場所に黙って書き込むのではなく、明示的に拒否します。

チームサーバー

コマンドを1つ実行するだけで、手動の手順なしに実際に使えるサーバーを起動できます。

docker compose -f deploy/compose.yml up -d
docker compose -f deploy/compose.yml logs server | grep 'bootstrap token'

Postgres は空のボリューム上でスキーマを自動的に作成し、サーバーは MYC_BOOTSTRAP_* から最初のテナントを登録して、最初のトークンを生成します。このサンプルデプロイは本番環境向けではありません。パスワードが公開されており、TLS はなく、データベースもサーバーの隣にあるボリュームに置かれます。TLS の設定はデプロイ側の役割です。前段にリバースプロキシを配置し、X-Forwarded-Proto を設定してください。

コンテナを使わない場合も、同じバイナリを使います。

myc serve --pg postgres://myc_app:…@host/myc --apply-schema   # empty db only
myc serve --pg … --add-tenant acme
myc serve --pg … --add-token acme:anna --role owner           # secret printed once
myc serve --pg … --port 8080

稼働状態プローブの /v1/health 以外は、すべてトークンが必要です。トークンには sha256 のみが保存されるため、データベースのコピーがあってもアクセスできず、秘密情報を読み出すこともできません。ロールは owner、maintainer、member、agent、viewer です。権限は read、write、claim、sync、admin で、--scopes によってロールの権限をさらに限定できます。sync は意図的に read に含まれていません。レプリカには可視性述語によるフィルタリングが適用されないため、レプリカを取得する権限があれば、ワークスペース内のすべてが見えてしまうからです。/v1/admin の管理ページでは、ブラウザー上のフォームでトークンの入力を求め、HttpOnly、SameSite=Strict の Cookie に保存します。

クライアントは、コマンドラインではなく環境変数を通じてサーバーを指定します（引数は ps、シェル履歴、フックのログに表示されるためです）。

export MYC_SERVER=https://myc.example/acme   # workspace in the path
export MYC_TOKEN=myc_…
myc ready

現在、CLI の一部だけがサーバーと通信します。ここが重要です。 現在リモートで使用できるのは、create／task／bug／epic／msg、update、claim、list、ready、show、prime、sync です。それ以外の close、remember、recall、comment、link、dep、attempt、search、code は、ローカルデータベースを黙って使うのではなく、precond.no_remote を返して拒否します。他の人のタスクを見て、チームのタスクとして引き受けてしまうのは、エラーになるよりも問題だからです。そのため、現時点でサーバーはレプリカが合流する場所であり、作業の一連の流れすべてが行われる場所ではありません。

そのため、現時点での標準的な使い方は、各マシンがそれぞれローカルワークスペースを持ち、サーバーを通じて情報を交換することです。

myc sync                 # both ways; --push-only, --pull-only, --dry-run

交換されるのは行ではなく操作です。op_id で重複を排除し、git のマージと同じ CRDT パス（フィールドごとの LWW、add-wins エッジ、G カウンター）を通じて再生されます。サイトごとにカーソルがあるため、同じ交換を繰り返しても状態は変わらず、中断した交換も再開できます。

TLS を使う実際のホストのセットアップ、個人ごとのトークン、バックアップ、エラーが発生した場合の対処については、docs/deploy.md を参照してください。

マシン間の同期

git に送るのは oplog のみです（myc export → .myc/graph、クローン時に myc import）。派生したプロジェクションやキャッシュは送りません。.myc/workspace.toml と oplog は意図的にコミットしますが、.myc/myc.db* とローカル状態はコミットしません。

マージドライバーは、クローンごとに一度登録します。

git config merge.myc-oplog.driver "myc merge-driver %O %A %B %L %P"

ライセンス

MIT — LICENSE を参照してください。埋め込みやフォークを行うすべての人ができるだけ手間なく使えるよう、このライセンスを選びました。すべてのランタイム依存関係（Bun、ONNX Runtime、sqlite-vec）もパーミッシブライセンスです。

---

このドキュメントのロシア語版：docs/README.ru.md。 グラフ付きの両言語版：https://aistastudio.github.io/myc/。