必要なものは3つです。専用の検証端末、機密情報を含まない試験タスク、データ経路と権限を記録するチェックシートを用意してください。
- 最初の手順：nanoMuse公式リポジトリと1.0.0 Keelのリリースノートを読み、評価対象の版を固定します。
- 次の手順：個人用スマートフォンや業務PCではなく、初期化できる端末とダミーアカウントで、閲覧だけのタスクから試します。
- 最後の手順：モデル事業者、nanoMuse Cloud、自社リレー、端末間通信のどこへ何が流れるかを確認してから、書き込みや送信を伴う操作へ進みます。
2026年10月9日時点：NanoMuseは、スマートフォン、PC、ブラウザをまたいで動くオープンソースのパーソナルAIエージェントです。公式は同日公開の1.0.0 Keelを初の安定版と位置付けています。ただし、公式ロードマップには画面認識の失敗や評価セット未整備などが明記されており、日本企業がそのまま本番導入できると判断する材料にはなりません。現時点の正しい入口は、隔離環境で権限・外向き通信・承認・停止を確かめることです。
2026年10月7日、Hacker Newsに「Show HN: NanoMuse – An open-source AI agent for your phone and computer」が投稿されました。投稿が直接リンクした先は、製品紹介記事ではなくソースコードと文書を置くGitHubリポジトリです。その後、10月9日には1.0.0 Keelが公開されました。つまり、HNで見かけた時点の印象だけで評価すると、現在の公式状態を取り違えます。
注目すべき点は「スマホにも入るAIチャット」ではありません。各端末にエージェントを置き、端末の画面、シェル、ブラウザ、MCP、スキルを仕事の手段にする設計です。便利さと同時に、端末権限、モデル事業者への送信、リレー上の同期、誤操作という運用課題が一つの製品に集まります。日本企業の実務者は、機能一覧より先に境界を読む必要があります。
最初に確定するのは「何が公開されたか」
NanoMuseの公式説明は、質問へ答えて終わるアシスタントではなく、利用者の端末やアカウント上で仕事を進めるパーソナルエージェントです。公式READMEでは、Linuxシェル、ブラウザ、MCPサーバー、スキル、予定されたタスクに加え、許可した場合はスマートフォンやPCの画面を「Hands」として扱うと説明しています。記憶は人が読んで編集できるファイルを中心に構成し、削除・送信・支払いなど元に戻しにくい操作では確認を挟む方針です。
公開物は単一アプリではありません。Androidアプリ、iPhone・iPad向けベータ、macOS・Windows・Linux向けデスクトップアプリ、Webコンソール、端末同士をつなぐリレーが同じリポジトリに含まれています。ライセンスはGPL-3.0-or-laterです。改変版を社外へ共有する、製品に組み込む、といった利用では、自社の配布形態に応じてライセンス条件を法務担当者と確認してください。これは法的助言ではありません。
| 確認項目 | 2026年10月9日時点の公式情報 | 企業検証での読み方 |
|---|---|---|
| 現行版 | 1.0.0 Keel。公式は初の安定版と説明 | プロジェクト自身の成熟度ラベル。第三者保証ではない |
| Android | Android 8.0以上、arm64向けAPK | 日常利用端末ではなく専用端末から始める |
| iPhone・iPad | TestFlightベータ。iOS上の他アプリ画面をHandsで操作する機能はない | Android版と同等と見なさず、機能差を試験表へ記載 |
| macOS・Windows | macOS版は未公証、Windows版は未署名とリリースノートに記載 | MDM、コード署名、配布許可、ハッシュ確認を別途評価 |
| ブラウザ | 模擬スマートフォン上で動くデモ | 製品版アプリの全機能を再現する環境とは扱わない |
端末内で動くエージェントという概念から整理したい場合は、ローカルAIエージェントのプライバシーと自律性もあわせて確認してください。NanoMuseは「ローカルで動く部分がある」ことと「すべてがローカルで閉じる」ことを分けて読む必要がある典型例です。
端末ごとのエージェントがリレーでつながる
公式アーキテクチャ文書では、ユーザーの指示を受けたMuseAgentがモデルへ問い合わせ、モデルが返したツール呼び出しをSentinelが判定し、必要な場合は承認カードを出してから実行する流れが示されています。実行結果は秘匿情報の置換、情報フローの印付け、監査ログへの記録を経て、再びエージェントへ戻ります。
もう一つ重要なのが、端末間の関係です。公式文書によると、スマートフォン、PC、Webのクライアントが単一のクラウド上エージェントを見るだけではありません。端末ごとにエージェントがあり、リレー上のハブを通じて別端末へタスクを委任します。たとえばスマートフォンで依頼し、PC側のエージェントがファイル操作を行い、承認要求を手元の端末へ返す構成です。
この設計は、企業内の責任分界にも影響します。「AI基盤チームが一つのサーバーだけを管理すればよい」とは限りません。端末側の実行ユーザー、OS権限、接続先モデル、リレー、同期設定、MCPや外部サービスの資格情報を一つの台帳で管理する必要があります。別端末へタスクを渡す機能は便利ですが、端末Aで許された操作が端末Bでも許されるのか、承認はどちらに出るのか、失敗時のログはどこに残るのかを検証してください。
日本企業に関係するのは機能よりデータ経路
「オープンソースだからデータは外へ出ない」という理解は誤りです。公式Privacy文書は、会話、記憶、ファイル、設定などを端末に保存する設計を説明する一方、設定したモデル事業者へメッセージ、添付画像、ツール結果が送られると明記しています。外部モデルを使えば、その処理に必要なデータは当該事業者へ届きます。
| 経路 | 公式文書で確認できる主なデータ | 検証前に決めること |
|---|---|---|
| 端末内 | 会話、記憶、生成ファイル、予定タスク、スキル、設定 | 保存先、暗号化、バックアップ、削除、端末管理 |
| モデル事業者 | メッセージ、添付画像、モデルへ渡すツール結果 | 利用規約、保存方針、学習利用、リージョン、契約 |
| nanoMuse Cloud | アカウント識別情報、IPアドレス、User-Agent、利用モデルやトークン数など | サインインの要否、管理者が見られる情報、削除手順 |
| 会話同期 | 主会話のテキスト、タイトル、役割、時刻、端末、添付名とサイズ | 同期スイッチ、サイドチャット同期、保存対象、削除結果 |
| 端末間操作 | 明示的な操作ではファイルやスクリーンショットを転送し得る | 転送上限、暗号化、送信元・送信先、監査ログ |
特に見落とせないのがData controlsです。公式文書では、サインインしたアカウントの会話同期は既定で有効と説明されています。また、コミュニティリレーで新しく作成したアカウントでは、AIモデル改善用に会話テキスト、モデル回答、選択されたツール呼び出しなどを保持する設定が既定で有効になる条件が示されています。検証開始前に、少なくとも会話同期、サイドチャット同期、モデル改善用データ保持、利用モデル、リレー接続先を画面で確認し、判断内容を記録してください。
自前リレーへ切り替えても、外部モデル事業者、Web検索、ブラウザ、MCP、チャット連携を使えば通信は発生します。「セルフホスト」と「完全に閉域」は同義ではありません。閉域性が要件なら、ローカルモデル、外部コネクタの無効化、DNSとegressの制限、パケットの観測まで含めて構成全体で確認します。
Sentinelは承認層だがOS隔離の代替ではない
NanoMuseのSentinelは、ツール呼び出しを許可・確認・拒否に分け、削除や送信、支払い、危険なコマンドなどに承認を挟む仕組みです。1.0.0の公式リリースでは、非公開データを読んだ会話が許可リスト外へ送信しようとした場合や、危険な警告を伴う呼び出しでは、自動実行モードでも確認するよう強化されたと説明されています。
一方、公式Sentinel文書は限界も率直に説明しています。Sentinelはエージェントと同じプロセス内のアプリケーション層です。Linuxでbubblewrapが使える場合はファイルシステムやネットワークを絞れますが、仮想マシンではありません。macOS、Windows、bubblewrapを使えないLinuxでは、承認したシェルやPythonコードがnanoMuseを起動したOSユーザーの権限で動きます。
また、非公開データを読んだことを示すtaintは会話単位でメモリ上に保持され、再起動後には残らず、別会話へファイルや記憶を介して移った情報へ自動追従しないと文書にあります。これは有用な防御ですが、DLPやOSサンドボックスの代わりではありません。APIも既定ではBearerトークンを使う平文HTTPであり、公式Security文書はインターネットへ直接公開せず、必要に応じてTLSリバースプロキシやTailscaleを使うよう求めています。
企業向けの設計へ翻訳すると、承認カードだけに依存せず、専用OSユーザーまたはコンテナ、短い外向き通信許可リスト、読み取り専用資格情報、シークレット管理、ネットワーク境界、ログ回収を重ねる必要があります。承認設計を体系的に見直す際は、AIエージェントのHuman-in-the-loop設計ガイドとAIエージェントのガバナンス・権限設計も参照してください。
評価表では「できる」と「企業で許せる」を分ける
NanoMuseは、端末をまたぐ操作、複数モデルの選択、自前リレー、読める記憶、事前承認という興味深い部品を一つにまとめています。ただし、機能が存在することと、自社の本番データを預けられることは別です。検証会議では、デモの成功率を聞く前に、次の判定表を埋める方が議論が進みます。
| 判定軸 | 確認する質問 | 合格証跡の例 |
|---|---|---|
| データ | 入力、記憶、添付、ツール結果はどこへ送られ、どこに残るか | 通信先一覧、設定画面、削除後の再確認 |
| 権限 | 読み取り・書き込み・送信・削除・支払いを個別に止められるか | 拒否試験、承認範囲、資格情報の権限表 |
| 隔離 | エージェントが侵害された場合に、どの端末・ファイルまで届くか | 専用ユーザー、コンテナ、マウント、egressルール |
| 監査 | 指示、モデル判断、承認、ツール実行、結果を追跡できるか | 監査ログ、時刻、端末、実行者、保管期間 |
| 停止 | 誤動作時に人が止め、権限を失効し、接続を遮断できるか | 停止操作、トークン失効、ネットワーク遮断の再現 |
| 更新 | 新しい版の署名、変更点、互換性、ロールバックを確認できるか | ハッシュ、変更履歴、復元手順、旧版データ |
| ライセンス | 改変・共有・組み込みが自社の配布形態と整合するか | 法務レビュー、依存ライセンス一覧、配布判断 |
公式資料で確認できない企業機能もあります。組織SSO、組織単位のRBAC、集中ポリシー配布、監査ログの外部SIEM連携、管理者による一括失効などは、公式文書だけで充足を断定できません。要件表に「未確認」を残し、存在を推測しないことが大切です。
導入検証は4段階で進める
段階A：画面と文書だけで候補を絞る
最初はブラウザデモ、README、リリースノート、Privacy、Sentinel、Roadmapを読みます。ここでは業務アカウントを接続せず、どの端末が何をできるか、iOSとAndroidの差、Cloudのスイッチ、未署名・未公証の配布物を確認します。デモは操作感を見る場であり、端末権限や社内ネットワーク条件を評価する場ではありません。
段階B：隔離端末で読み取りだけを試す
初期化可能な専用端末、専用OSユーザー、試験用メールボックス、ダミーファイルを用意します。最初のタスクは「ローカルの試験フォルダを一覧表示する」「試験用受信箱の件名だけを読む」のように、書き込みも外部送信も起こらない内容に限定します。通信ログ、承認カード、監査ログ、停止操作を同時に観察してください。
段階C：自前リレーと外向き通信制限を試す
公式Self-hosting文書には、自分のAPIキーを使う方法、自前リレーを動かす方法、自前ランタイムを動かす方法が分けて書かれています。リレーのローカル検証にはDocker、Docker Composeプラグイン、curlが必要です。公式手順は次のとおりです。
動作条件：公式文書に記載されたDocker環境。コマンドは2026年10月9日に公式文書で実在を確認しています。
git clone https://github.com/nano-muse/nanoMuse.git
cd nanoMuse
bash scripts/self-host.sh --localポイント：このコマンドは同じ端末から使うローカル構成です。LAN上の別端末へ公開するオプションも公式文書にありますが、接続範囲が広がるため、ファイアウォール、認証、TLS、接続元制限を決めずに使わないでください。
注意：本番環境で使用する前に、必ずテスト環境で動作確認してください。シークレットをコマンド履歴、記事、チケット、共有ログへ貼り付けないでください。
段階D：書き込みを1種類ずつ解放する
読み取りが安定してから、試験フォルダへのファイル作成、試験用チャットへの送信、別端末への委任という順に、操作を一種類ずつ追加します。各操作で「許可」「拒否」「タイムアウト」「途中停止」「再起動後」を確認します。支払い、取引、予約、顧客への送信、本番コードの変更は、この段階の合格だけで解放しません。別の承認フローと責任者を置いてください。
検証で起きやすい4つの取り違え
失敗1：日常利用端末へいきなり入れる
❌ 個人用スマートフォンや業務PCへ導入し、連絡先、メール、ブラウザ、ファイルをまとめて許可する。
⭕ 初期化可能な専用端末、専用OSユーザー、ダミーアカウント、空の試験フォルダから始めます。アクセス先を一つずつ増やし、権限追加の前後で通信とログを比較します。
失敗2：オープンソースを完全ローカルと読み替える
❌ ソースが公開されているため、会話やツール結果は外部へ出ないと説明する。
⭕ モデル事業者、リレー、会話同期、外部検索、MCP、ブラウザ、チャット連携を別々の経路として記録します。自前リレーでも外部モデルを選べば、モデル処理のデータは外部へ送られます。
失敗3：承認カードを安全性の保証にする
❌ 送信前に確認が出るため、誤送信や情報流出は起きないと判断する。
⭕ 承認疲れ、過大な恒久許可、再起動後のtaint消失、OSユーザー権限での実行を前提にします。承認を拒否した時の挙動、外向き通信遮断、専用ユーザー、コンテナ、読み取り専用資格情報を組み合わせてください。
失敗4：1.0.0を企業向け完成保証と受け取る
❌ 「安定版」と書かれているため、画面操作の成功率や企業統制も十分だとみなす。
⭕ 安定版はプロジェクト自身のリリース区分として扱います。公式Roadmapは、画面要素の誤認、予期しないダイアログからの復帰失敗、固定評価セットの未整備、端末間で共通する記憶の未実装、英語・中国語以外の精査不足を挙げています。自社のタスクで再現可能な合否基準を作ってください。
コミュニティの反応は期待と警戒に分かれた
Hacker Newsのスレッドでは、オープンソースでセルフホスト可能な代替を歓迎する反応がある一方、日常利用するスマートフォンへ画面操作型エージェントを入れることへの警戒、権限境界やデータ持ち出しへの質問、Meta Museを連想させる名称への懸念が目立ちました。
個人エージェント自体の必要性を疑う意見に対し、メールの優先順位付けや実行機能がアクセシビリティや実行機能支援に役立つという反論もあります。ただし、それらの体験談の多くはHermes Agentやコメント投稿者自身の環境についてであり、NanoMuseの導入成果ではありません。取得したスレッドでは、NanoMuseを業務環境へ導入して評価したと確認できる報告や、開発者による公式回答は見当たりませんでした。
コミュニティの不安は、製品欠陥の証明ではありません。同時に、人気や好意的な反応も安全性の証明ではありません。HNから受け取るべき実務上の示唆は、「便利かどうか」の議論より、「どの境界をどう検証すれば信頼できるか」という問いです。
よくある質問
NanoMuseは何をするAIエージェントですか？
公式説明では、スマートフォン、PC、Webをまたぎ、シェル、ブラウザ、MCP、スキル、端末画面などを使って作業するパーソナルAIエージェントです。各端末にエージェントを置き、リレーを介して会話やタスクをつなぐ設計です。
データはすべて端末内に残りますか？
いいえ。主要な状態は端末に保存される設計ですが、モデルへ渡すメッセージ、画像、ツール結果は設定したモデル事業者へ送られます。nanoMuse Cloudへサインインした場合は、アカウント情報、ネットワーク情報、会話同期データなども公式文書に記載された範囲でリレーが扱います。
iPhoneでも他のアプリを自動操作できますか？
2026年10月9日時点の公式説明では、iPhone・iPad版はTestFlightベータで、iOS端末自身の画面をHandsで操作する機能はありません。Android版やデスクトップ版と同じ機能だと考えないでください。
セルフホストすれば完全な閉域運用になりますか？
自動的にはなりません。自前リレーへ移しても、外部モデル、Web検索、ブラウザ、MCP、チャット連携を使えば外向き通信が発生します。閉域要件がある場合は、ローカルモデル、コネクタ制限、DNS・egress制御、通信観測まで含めて確認してください。
1.0.0なら本番導入してよいですか？
版番号だけでは判断できません。公式は初の安定版と説明していますが、Roadmapには未完成点が残っています。隔離端末、ダミーデータ、最小権限で自社タスクを試し、セキュリティ、監査、停止、更新、ライセンスの合否を決めてから判断してください。
既存の自己ホスト型エージェントと何を比較すべきですか？
端末画面を操作できる範囲、端末間委任、モデル選択、記憶の可視性、承認境界、OS隔離、データ同期、管理機能を同じ条件で比較します。比較軸を作る際は、OpenClawの機能・セットアップ難易度・注意点も参考になります。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- nanoMuse公式GitHubリポジトリ — 公開物、対応環境、構成、ライセンスを確認（参照日: 2026年10月9日）
- nanoMuse 1.0.0 Keel リリースノート — 公開日時、初の安定版という位置付け、配布物、署名状態、更新内容を確認（参照日: 2026年10月9日）
- Architecture — MuseAgent、Sentinel、ツール実行、監査の処理経路を確認（参照日: 2026年10月9日）
- Privacy — 端末内保存、モデル事業者、リレー、会話同期、データ制御を確認（参照日: 2026年10月9日）
- Sentinel — 承認、taint、サンドボックス、OS隔離の限界を確認（参照日: 2026年10月9日）
- Security Policy — 専用ユーザー、認証、公開範囲、外向き通信に関する公式推奨を確認（参照日: 2026年10月9日）
- Run nanoMuse yourself — 自分のキー、自前リレー、自前ランタイムの手順を確認（参照日: 2026年10月9日）
- Roadmap — 記憶、画面操作、評価、国際化などの未完成点を確認（参照日: 2026年10月9日）
- nanoMuse: An Open-Source Personal Agent for Every Device You Own — プロジェクト著者によるシステム報告と提出日を確認（参照日: 2026年10月9日）
- Show HN: NanoMuse — 投稿日時とコミュニティの反応を確認。製品仕様の根拠には使用していません（参照日: 2026年10月9日）
結論
NanoMuseの価値は、スマートフォン、PC、Web、モデル、記憶、承認を一つのオープンソース実装で観察できる点にあります。日本企業にとっては、すぐ全社展開する製品というより、端末横断エージェントの権限設計とデータ経路を具体的に検証できる候補です。
最初に行うのは、公式文書で対象版を固定し、専用端末とダミーデータを用意し、読み取りだけのタスクを実行することです。その後、モデル事業者、リレー、同期、外部コネクタを一経路ずつ確認し、承認拒否、途中停止、再起動、削除、更新を再現します。これらの証跡がそろわない限り、顧客データ、社内メール、本番ファイル、外部送信へ権限を広げないでください。
あわせて読みたい：
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
