mercury-agent を採用する前に確認すべき権限モデルと常駐運用
Soul-driven AI agent with permission-hardened tools, token budgets, and multi-channel access. Runs 24/7 from CLI or Telegram.
ひと目でわかる
- これは何？
- MIT ライセンスの TypeScript 製 AI エージェント mercury-agent について、README とリリース情報から読み取れる権限設計、SQLite ベースの記憶、デーモン運用の実態を整理する。便利さの裏にある Telegram 依存と設定ファイルの所在を先に押さえておきたい。
- 誰に向いている？
- 導入を検討すべきなのは、CLI か Telegram から常時動くエージェントを自前のマシンで運用し、シェル実行やファイル書き込みの前に承認を挟みたい人だ。逆に、複数人で共有するサーバー上で無人実行させたい場合や、Telegram を社内ポリシーで使えない組織には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
mercury-agent が埋めようとしている穴は「無言で実行するエージェント」
多くの CLI 型エージェントは、ファイルを読み、コマンドを走らせ、URL を取得する。README はこの一般像を認めたうえで、Mercury は実行前に確認を取る点が違うと述べている。対象読者は、自分の端末や常時起動のマシンでエージェントを動かし、何をされたか把握できない状態を避けたい個人開発者や小規模チームだ。31 個の組み込みツール、Kanban ボード、拡張可能なスキル、SQLite で支える Second Brain メモリという構成が README には列挙されている。つまり汎用のチャットボットではなく、ローカル権限と記憶を持った常駐アシスタントという位置づけになる。MIT ライセンスで、既定ブランチは main、最終 push は 2026-09-09 と記録されている。
権限ハードニングはブロックリストとスコープの二段構え
README が挙げる権限機構は具体的だ。シェルのブロックリストにより sudo や rm -rf / などは実行されない。加えてフォルダ単位の読み書きスコープが設定され、保留承認フローを通る。セッションごとに Ask Me か Allow All を選ぶ方式で、初回起動のセットアップ後にこのモードを聞かれると README は説明している。ここで注意したいのは、Allow All を選んだセッションでは承認フローが素通りになる点だ。ブロックリストとスコープは残るが、個別の確認は消える。常駐運用を前提とするツールでこのモードを常用するのは、権限ハードニングの利点を自分で外す行為になる。README はこのトレードオフを明示していない。運用側が自覚して選ぶ必要がある。
Second Brain は SQLite と FTS5 で記憶を検索可能にする
記憶の実装は SQLite に FTS5 全文検索を組み合わせる形だと README に書かれている。10 種類のメモリ型、自動抽出、競合解決、自動統合という処理が並ぶ。ポイントは、記憶が単なる会話ログではなく構造化されたレコードとして保存され、全文検索で引き出される設計だという点だ。エージェントが利用者の好みや目標を手入力なしに学習する、というのが README の主張である。ただし自動抽出と自動統合が何を基準に動くのか、README の抜粋からは読み取れない。誤った記憶が統合されて残るリスクは、この種の設計では避けにくい。導入時には保存先の SQLite ファイルを直接確認し、意図しないレコードが増えていないかを見る価値がある。
常駐運用は mercury up に集約され、CLI はログ専用になる
デーモン化の入口は mercury up の一発だ。サービスが未インストールなら導入し、バックグラウンドのデーモンを起動して稼働を保証する。すでに動いていれば PID を示して終わる。クラッシュ時は指数バックオフで再起動し、1 分あたり最大 10 回まで、と README は記載している。OS ごとのサービス方式も明快で、macOS は LaunchAgent、Linux は systemd のユーザーユニット、Windows は Task Scheduler を使う。いずれも管理者権限は不要と表に書かれている。ここで見落としやすいのが、デーモンモードでは Telegram が主チャネルになり、CLI は入力端末がないためログ専用になるという記述だ。つまり常駐させるほど Telegram への依存度が上がる。Telegram を使えない環境では、この運用形態自体が成立しない。
導入は curl 一発か npm 経由かで前提が変わる
インストール経路は 3 つ示されている。Node.js 不要のスタンドアロンバイナリを取る curl -fsSL https://mercuryagent.sh/install.sh | sh、Windows 向けの irm https://mercuryagent.sh/install.ps1 | iex、そして Node.js 20 以上がある場合の npx @cosmicstack/mercury-agent だ。グローバル導入なら npm i -g @cosmicstack/mercury-agent の後に mercury を打つ。初回起動で名前、プロバイダ、任意の Telegram を尋ねるセットアップウィザードが走り、その後 Ink の TUI 起動画面を経て権限モードの選択に進む。設定をやり直すなら mercury doctor、環境の互換性診断は mercury doctor --platform を使う。curl でシェルスクリプトを直接流す経路は、実行内容を確認しないまま権限の強い常駐プロセスを入れることになる。バイナリ経路を選ぶなら、先にスクリプトの中身を読むか、npm 経由でバージョンを固定する方が監査しやすい。
トークン予算とチャネル管理は設定より運用コマンドで回す
トークン管理は日次予算の強制で、70% を超えると自動的に簡潔モードへ切り替わると README は述べている。確認とリセット、上書きは /budget 系のコマンドで行う。これらのチャット内コマンドは API トークンを消費しないと明記されており、CLI と Telegram の両方で動く。Telegram 側のアクセス制御はコマンド群で管理する。mercury telegram list で承認済みと保留中のユーザーを一覧し、approve でペアリングコードか保留要求を承認、reject と remove で除外、promote と demote で管理者とメンバーを切り替える。reset は全アクセスを消してやり直す。常駐エージェントを Telegram に繋ぐ場合、この承認リストが実質のアクセス境界になる。誰が承認済みかを定期的に list で確認できる状態にしておかないと、境界が曖昧になる。
スキルは Agent Skills 仕様に乗るが、中身の確認は利用者の責任
拡張はコミュニティスキルを 1 コマンドで入れる方式で、Agent Skills 仕様に基づくと README は説明している。初回実行時には既定の web-search スキルが ~/.mercury/skills/web-search/SKILL.md に配置される。スキルは定期タスクとしてスケジュールできる。ここで気をつけたいのは、スキルがエージェントに新しい行動を与えるという性質だ。権限ハードニングは組み込みツールに対して効くが、スキルが何を呼ぶかは SKILL.md の記述次第になる。README の抜粋にはスキル定義の検証機構についての言及がない。コミュニティスキルを入れる前に SKILL.md を読む運用は、この構成では省略できない工程だ。
向かない場面と、代わりに検討できる選択肢
Mercury が向かないのは、複数人が同じマシンやサーバーを共有し、誰の承認で何が実行されたかを追跡する必要がある場面だ。承認フローは対話者个人の操作を前提にしており、共有環境での監査には設計が合っていない。もう一つ、Telegram を組織的に使えない場合は常駐運用の主チャネルを失う。代替として、権限承認を挟まずコンテナ内で完結させる実行方式のエージェントがある。違いは隔離の層だ。Mercury はホスト側でブロックリストとスコープにより危険な操作を止める。コンテナ型はそもそもホストのファイルやシェルに触れない場所で動かし、承認の代わりに境界で守る。どちらが優れているかではなく、危険を承認で抑えるか隔離で断つかという設計思想の差である。ローカルの作業を細かく制御したいなら Mercury、実行内容を問わず被害範囲を限定したいならコンテナ型が噛み合う。
維持コストとライセンスの確認点
MIT ライセンスなので、改変と再配布の条件は比較的緩い。ただしライセンス文の解釈はここでは扱わない。実務上の維持コストは更新経路にある。mercury upgrade が用意されている一方、リリースは v1.1.13 から v1.2.2、v1.2.3 と短期間に続いており、v1.2.2 では Mercury Cloud とクロスプラットフォーム修正が入ったと記録されている。常駐デーモンとして動かす以上、この更新を放置すると修正が反映されないまま稼働し続ける。アップグレード後は mercury status と mercury logs で稼働とログを確認する流れになる。設定の再構成は mercury doctor、環境診断は mercury doctor --platform で行う。これらはすべて README に記載されたコマンドであり、独自の監視基盤を組む必要はない。
編集部の結論
導入を検討すべきなのは、CLI か Telegram から常時動くエージェントを自前のマシンで運用し、シェル実行やファイル書き込みの前に承認を挟みたい人だ。逆に、複数人で共有するサーバー上で無人実行させたい場合や、Telegram を社内ポリシーで使えない組織には向かない。導入前に確認するのは 3 点。mercury doctor --platform で自分の環境のデーモン互換性を見ること、~/.mercury/skills/web-search/SKILL.md をはじめとするスキル定義の中身を読むこと、そして mercury telegram list で承認済みユーザーを把握できる状態にしておくことだ。この 3 つが確認できないまま mercury up を打つと、権限モードの選択が後追いになる。
コミュニティノート