実際に入れて動かして分かったこと

実際にインストールして、コマンドを叩いて確かめた記録です。公式ドキュメントに書かれていないことを中心に並べます。

なお本稿では Meta アカウントでの認証は行っていません。したがって「実際のモデルの応答品質」や「実際の課金額」は測っていません。認証しなくても確認できた範囲の話です。

インストールは97MB、実体はホーム配下だけ

Downloading muse 0.1.0-R708.1 (97 MB)
Installed muse to ~/.local/bin/muse

ダウンロードサイズは97MB、配置先は ~/.local/bin/muse の1ファイルです。管理者権限は要求されませんでした。インストーラの詳細は別記事にまとめています。

Claude Code の個人ルールを読み込む

muse: workspace root: /path/to/work (cwd default)
muse: Including your Claude Code personal rules — manage with /settings.

これは空のディレクトリで実行しても出ました。作業中のプロジェクトに何も置いていない状態で出るということは、読まれているのはプロジェクト側のファイルではなく、ホームディレクトリにあるユーザー共通の設定です。

Claude Code の個人ルールには、仕事の進め方や環境の情報を書いている人が多いはずです。そこに社内の事情や取引先の名称が含まれていれば、それが Muse Code のプロンプトに含まれることになります。contributorティアを選んでいる場合、その内容は学習に使われる対象です。

読み込ませない方法

HOME を別のディレクトリに向けて起動すると、この行は出なくなりました。ホーム配下の設定を探しに行かなくなるためです。

mkdir -p /tmp/muse-lab/home /tmp/muse-lab/work
cd /tmp/muse-lab/work
HOME=/tmp/muse-lab/home ~/.local/bin/muse

実際にこの形で実行したところ、Including your Claude Code personal rules の行は出力されませんでした。認証情報も差し替えたHOME側に保存されるため、普段の環境は変わりません。試用や検証のときに使える方法です。

この方法は「ホーム配下の設定を読ませない」だけです。作業ディレクトリに置いてあるファイルは、エージェントが読めば当然プロンプトに含まれます。空のディレクトリで試すのが確実です。

認証なしで動かせる echo プロバイダ

--provider には meta のほかに echo があります（既定は meta）。echo はモデルを呼ばず、入力をそのまま返す決定的なモードです。Metaアカウントの認証をしていなくても動きました。

muse exec --provider echo --json "hello"

課金もアカウントも発生しないので、後述するイベントログの形式や、CLIの挙動そのものを確認するのに使えます。--echo-delay-ms で応答遅延を指定でき、これも echo 専用のオプションです。

イベントログの中身

--json を付けると、JSONL形式でイベントが流れます。「クラッシュしても再開できる」という説明の実体がここに見えます。1件を整形すると次のような形です。

{
  "schema_version": 1,
  "stream": { "kind": "session", "id": "b3880833-..." },
  "sequence": 12,
  "record_type": "event",
  "durability": "durable",
  "causation_id": "7a84409c-...",
  "payload_type": "task.lifecycle.scheduled",
  "payload": {
    "kind": "task_lifecycle",
    "task_id": "ce8ff758-...",
    "event": {
      "kind": "scheduled",
      "idempotency_key": "model:7a84409c-...:ce8ff758-..."
    }
  }
}

読み取れる設計は次のとおりです。

• イベントソーシング型です。session / run / task の3種類のストリームがあり、それぞれに連番（sequence）が振られます。
• 因果関係が記録されます。causation_id によって、どのコマンドが引き起こしたイベントかを辿れます。
• 永続性が区別されています。durability が durable（残す）と ephemeral（残さない）に分かれており、途中経過の表示は残さない設計です。
• 冪等キーがあります。モデル呼び出しには idempotency_key が付きます。中断して再開したときに同じ処理を二重に走らせないための仕組みです。
• 副作用に方針判定が入ります。side_effect_intent というイベントがあり、policy_decision というフィールドを持ちます。外部に影響する操作を、実行前に方針で判定していることが分かります。

タスクは proposed → accepted → scheduled → side_effect_intent → started → completed（失敗時は failed）という順に遷移していました。

内部プラグインが動いている

ログには、こちらが指示していないタスクが2つ現れました。

"task_kind": "reminder.agent.plugin:tbh-reminders:scope-reminder"
"task_kind": "reminder.agent.plugin:tbh-reminders:goal-reminder"

tbh-reminders という名前のプラグインが標準で組み込まれており、「スコープ」と「ゴール」をエージェントに思い出させるタスクを毎回投入しているようです。長い作業で目的から逸れるのを防ぐ仕組みだと考えられます。echo プロバイダでは provider does not support base instructions という理由で失敗していました。

安全機構は既定でオン

ヘルプには「approval and the sandbox are ON by default」と明記されており、既定値は次のようになっていました。

目を引くのは --approval-judge です。既定で on になっており、ツール実行の承認可否をLLMが判定する仕組みが標準で入っています。通信が既定で proxy-only になっている点も、外部への送信を絞る方向の設計です。

--yolo を付けると承認もサンドボックスもまとめて無効になります。--disable-sandbox --disable-write --disable-shell と個別に外すこともできます。

worktree による並列は、既定では限定的

「サブエージェントが隔離された git worktree で並列に動く」と紹介されることの多い機能ですが、ヘルプの記述は次のとおりでした。

• セッション自体の --worktree は既定 off。create か existing を明示する必要があります。
• --subagent-worktree-isolation は互換用のフラグで、機能自体は既定で有効。ただし「子エージェントが明示的に要求したときだけ隔離され、省略時は共有」と書かれています。

つまり「常に全部が隔離されて並列に走る」わけではなく、条件が揃ったときに効く機能だと理解するのが正確です。

そのほか

• muse sandbox のサブコマンドは windows check と windows setup のみでした。macOS と Linux ではOS側の仕組みを使っており、セットアップ操作が要らないためだと思われます。
• muse exec --api-key-stdin で、APIキーを標準入力から渡せます。環境変数に残したくない場合に使えます。
• --preset には native-basic と miniswe の2つが用意されています。
• --image でローカル画像を添付でき、exec では繰り返し指定できます。
• --no-session-log でイベントログをディスクに残さないようにできます。
• サブコマンドは resume exec export trace skills sandbox session-message auth login logout init の11種類です。session-message は「セッション間のメッセージ送信・待受」と説明されており、複数セッションを協調させる用途が想定されているようです。

検証は2026年8月11日、Muse Code 0.1.0（0.1.0-R708.1）で行いました。ベータ版のため、既定値や挙動は変更される可能性があります。