チャットからAIに作業を任せる常駐型OSS「Moltis」の仕組みと導入前の注意点

「社員が自宅の小型サーバーでAIアシスタントを常に動かし、チャットアプリから仕事を頼んでいるらしい」「安全を売りにした自前運用のAIエージェントなら、社内で使わせても問題ないのだろうか」——情報システム部門やセキュリティの担当者から、こうした相談が増えています。自分の機械で動かす、命令は隔離して実行する、と聞くと、それだけで守りは済んだように感じられます。しかし本当に問うべきなのは、その仕組みが何を守り、何を利用者の判断に残しているのかという点です。この記事では、チャットや音声からAIに作業を任せられる常駐型のOSS「Moltis」を取り上げ、仕組みの全体像と、2026年9月に公開された重大・高の2件のセキュリティ勧告、企業が導入前に確かめたい点を一次情報に基づいて整理します。導入や設定の手順は扱いません。

Moltisとは何か。2026年10月時点で確かめられる事実

Moltisは、GitHubの組織アカウント「moltis-org」が公開している、個人向けのAIエージェントのサーバーです。READMEは自らを「安全で常駐型の個人向けエージェントサーバー」と説明し、Rustで書かれた一つの実行ファイルとして、利用者自身の機械の上で動くことを特徴に挙げています。小型のパソコンや、手のひら大の基板の計算機（Raspberry Piなど）、自前のサーバーで動かす想定です。

ライセンスはMITで、OSI（オープンソースの定義を管理する団体）が承認したライセンスです。リポジトリは2026年1月29日に作られ、組織アカウントは2026年2月2日に作られました。2026年10月23日の時点で、スターは約2,900、派生（フォーク）は約360で、作成からの平均では1日あたり約11スターのペースです。直近の更新は2026年10月22日で、開発は活発に続いています。

READMEによると、中身は59の部品（Rustでいう「クレート」）に分かれたおよそ27万行のコードで、エージェントの中心部分は約7,500行にまとめられているとされます。提供元はこれを「監査しやすさ」の根拠として挙げています。ただし、組織アカウントの公開リポジトリは7つ、フォロワーは56にとどまり、READMEには開発者個人の名前や運営する会社の情報は書かれていません。この点は、後の「安全性の評価」で改めて扱います。

リリースの名前は、以前は「0.10.12」のような番号でしたが、2026年9月以降は「20260902.03」のように日付をもとにした名前に変わっています。確かめた時点の最新は、2026年10月19日の「20261019.01」です。版の名前の付け方が途中で変わっているため、自社で使っている版が、勧告の修正を含む版より新しいかどうかを日付で読み取る必要がある点は覚えておいてください。

なぜ注目されているのか：常駐型AIアシスタントを一つの実行ファイルで

2026年に入り、AIアシスタントを自分の機械で常に動かし、チャットアプリから話しかけて作業を頼む、という使い方が海外の開発者の間で広がりました。その代表がOpenClawで、Moltisのトピックにも「openclaw」が付いています。READMEはOpenClawからの設定や道具の取り込みにも対応すると書いており、既存の常駐型アシスタントの、より安全志向の受け皿として名乗りを上げている位置づけです。

READMEは、米国の技術系の掲示板「Hacker News」で上位に取り上げられたことも記しています。注目の理由として提供元が強調しているのは三点です。一つ目は、JavaScriptの実行環境や追加の部品の取り寄せを必要とせず、一つの実行ファイルで動くこと。二つ目は、命令を利用者の機械に直接ではなく、隔離したコンテナの中で動かすこと。三つ目は、外部の部品を売り買いする仕組み（プラグインの市場）を持たないことで、そこを経由したサプライチェーン攻撃（配布経路を狙う攻撃）を避けるという考え方です。

こうした説明は、AIアシスタントに強い権限を渡すことへの不安が広がっていることの裏返しでもあります。常駐型のアシスタントは、メールやチャット、ファイル、外部のサービスの鍵を預かり、利用者が見ていない時間にも動きます。便利さと引き換えに、ひとつの弱点が利用者の機械やつながった仕組みに直結するのが、この種の道具の本質です。Moltisが安全を前面に出しているのは、その不安に応えるためだといえます。

仕組み1：メッセージの通り道と、記憶の置き場所

READMEの説明では、利用者はウェブの画面、TelegramやDiscordなどのチャットアプリ、外部から呼び出す窓口（API）のいずれかからMoltisに話しかけます。受け付けたメッセージは、中継の役を持つサーバー部分を通ってエージェントの本体に渡り、本体が言語モデル（文章を生成するAI）を呼び出し、必要に応じて道具を使います。つながるチャットとして、Telegram・Signal・Teams・Discord・Slack・WhatsApp・Matrix・Nostrなどが挙げられています。

言語モデルは一つに縛られず、複数の提供元を切り替えて使えます。手元で動かすモデルの選択肢も用意されています。ここで押さえたいのは、本体を手元で動かしても、外部の提供元のモデルを呼べば、会話の中身はその提供元へ送られるという点です。「自分の機械で動かす」が「何も外に出ない」を意味するわけではありません。

記憶の仕組みも特徴の一つです。会話の記録はセッションごとのファイルに残され、長く覚えておく内容はSQLite（小型のデータベース）に、全文検索と意味の近さで探す検索を組み合わせて保存されます。セッションをまたいで過去の話を思い出す機能や、記録が長くなると自動で要約して詰める機能もあります。便利な反面、預けた情報が長く残り、別の会話からも引き出されうるということでもあり、何を覚えさせるかは利用者が決める必要があります。

仕組み2：命令をコンテナの中で動かす隔離の考え方

Moltisの守りの中心は、AIが実行する命令を利用者の機械に直接ではなく、隔離した入れ物（コンテナ）の中で動かすことです。公式のセキュリティの文書によると、DockerやPodman、Appleのコンテナ機能などから使えるものを選び、既定ではいちばん強いものを自動で使います。WASM（ブラウザ由来の隔離された実行形式）で動く道具もあります。

公式の文書は、コンテナには既定でネットワークの接続を持たせず、記憶の量・計算の量・動かせる処理の数に上限を設けられると説明しています。さらに「信頼済みのネットワーク」という設定では、許可した宛先にだけ通信させ、すべての通信を記録できます。AIが行きすぎた命令を出しても、被害が囲いの外に広がりにくくするという考え方です。

ただし、この囲いは設定と実装の両方が正しくて初めて効きます。後で詳しく見る高の勧告は、まさにこの隔離の部分で、別々の会話が同じコンテナと作業場所を共有してしまう可能性があるというものでした。また、公式の文書によると、作業用のホームフォルダの保存方法の既定は「共有」で、これは会話どうしを分ける境界としては設計されていません。隔離の仕組みがあることと、会話ごとに完全に分かれていることは、同じではないのです。

仕組み3：人の承認と、つなぐ相手の絞り込み

命令の実行には、人の承認を挟む仕組みがあります。公式の文書によると、承認の方式は三つで、既定は安全とみなした命令だけを自動で通す方式です。すべてを承認に回す方式と、承認を求めない方式も選べますが、承認を求めない方式について、文書は完全に自動化され隔離された環境でのみ向く危険な設定だと明記しています。

危険な命令の型をまとめた一覧があり、利用者の機械で直接実行する命令がそれに当たると、承認を求めない方式でも承認に回されます。ただし、この一覧が効くのは機械で直接実行する場合だけで、コンテナの中の命令には適用されないと書かれています。加えて、道具を呼び出す直前に中身を調べて止められる「差し込み口（フック）」が15種類の場面に用意されています。

チャットからの利用にも絞り込みがあります。チャットで話しかけてくる相手は、明示的に許可した人でなければ使えません。命令の実行や道具の利用といった強い権限は、運用者として指定した人にだけ与えられ、公開や共有のチャットでは使える道具が制限されます。誰の言葉をAIへの指示として受け付けるかを、人が先に決める仕組みで、チャットを入り口にする道具では特に重要な部分です。

仕組み4：鍵の保管と配布物の検証

外部のサービスの鍵（パスワードや接続用の合言葉）の扱いについて、公式の文書は、データベースに保存する重要な値をパスワードから作った鍵で暗号化する「金庫」の仕組みを説明しています。金庫はログインのときに開き、再起動すると閉じます。閉じている間は、金庫の中身が必要な要求は受け付けません。道具の出力に鍵が混じった場合に伏せ字にする処理もあるとされます。

ログインの方式は、パスワードと、指紋や端末の認証を使うパスキーに対応し、外部から呼び出す窓口の鍵には、読む・書く・管理などの範囲を明示して与える必要があります。ログインや窓口への接続には、送り元ごとの回数の上限もかけられています。

配布物そのものの信頼性についても手当てがあります。READMEによると、リリースの成果物には、GitHubの来歴の証明、鍵を持たない方式の電子署名、ハードウェアの鍵による署名、ハッシュ値（改ざん検知用の値）が付けられています。入手した配布物が本物かを確かめる手段が用意されているのは、企業が検討するうえで評価できる点です。一方で、READMEには公式サイトから取り寄せたスクリプトをそのまま実行する導入方法も案内されており、この方法では検証の手順が省かれがちになる点には注意が要ります。

公式文書が自ら挙げている限界

Moltisの公式のセキュリティの文書は、守りの仕組みだけでなく、限界も正直に書いています。企業が検討するうえでは、この限界の一覧こそが判断の材料になります。まず、会話の履歴と初期設定のデータは、保存時に暗号化されないとされています。金庫で守られるのは一部の重要な値で、すべてではありません。

次に、利用者が設定画面から預けたファイルは、道具を使えるすべての会話から読めます。チャットアプリ経由の会話も含まれるため、文書は、それが許容できない限り機密のファイルを預けないよう注意しています。また、ログインの情報がまだ一つも設定されていない状態では、手元からの接続に全面的な操作を許す、という段階の扱いも説明されています。

ほかにも、外部に公開する場合は自動で作られる証明書では足りず、正式な証明書を用意すること、間に中継のサーバーを置く場合は設定を誤ると手元からの接続とみなされて認証をすり抜けうること、内部の宛先への接続を防ぐ仕組みに例外を足すと守りが弱まることなどが挙げられています。限界の一覧を読み、自社の使い方でどれに当たるかを先に洗い出すことが、仕組みの説明を読む以上に大切です。

似た常駐型アシスタントとの比べ方

READMEには、OpenClaw、Hermes Agent、Moltisの三つを並べた比較表があります。これは提供元が自ら作った比較であり、第三者による検証ではない点に注意してください。そのうえで、企業が見るべき軸に絞って要点を並べると、次のようになります。

比べる軸	OpenClawの場合	Hermes Agentの場合	Moltisの場合
主な作り	JavaScript系の実行環境と付属アプリ	Pythonが中心	Rustの一つの実行ファイル
命令の実行先	アプリ単位の権限と道具	手元・Docker・遠隔接続など複数	Docker・Podman・Appleのコンテナ機能・WASM
ログインの方式	端末の組み合わせと手元の制御	コマンド操作とチャットの設定	パスワード・パスキー・窓口の鍵・金庫
外部の部品	拡張や道具が多い	プラグインや道具の集まり	市場は持たず、同梱と作業場所の手順書（スキル）

表から読み取れるのは、Moltisが実行の隔離とログインの守りを、最初から本体に組み込む方向に寄せている、ということです。一方、どの道具を選んでも、AIに命令の実行や外部の鍵を預ける構造は同じです。表の右端が最も安全だと読むのではなく、自社が預けたいもの・止めたいものに対して、それぞれの守りがどこまで効くかを確かめる材料として使ってください。

安全性の評価：注意付きとした根拠

このラインでは、Moltisの安全性を「注意付き」と判定しました。OSSをクローン・導入・実行はせず、公開されている情報だけで判断しています。根拠は三つです。一つ目は、重大（クリティカル）と高（ハイ）の二つのセキュリティ勧告が2026年9月2日に公開されていることです。どちらも修正版が出ていますが、命令の実行と隔離という、この道具の守りの中心に関わる弱点でした。

二つ目は、運営体制の情報が少ないことです。組織アカウントは2026年2月に作られたばかりで、READMEには開発者個人や会社の情報がありません。スターの伸びは1日あたり約11と、不自然に多いとまではいえない水準ですが、長い実績を持つ運営元とはいえません。三つ目は、導入用のスクリプトとコンテナの定義ファイルがリポジトリの直下にあり、導入時に自動で動く処理を含みうることです。

一方で、評価できる点もあります。勧告を自ら公開して修正版を出していること、限界を文書に明記していること、配布物の署名や来歴の証明を用意していることは、弱点に向き合う姿勢の表れと読めます。とはいえ、問題が見つかっていない部分があっても、それは安全の保証ではないことは押さえておいてください。今回の判定は、2026年10月23日時点で公開されている情報に基づくものです。

公開済みのセキュリティ勧告2件の中身

2件の勧告の概要を、GitHubの勧告のページに基づいて整理します。悪用の手順には触れず、影響・前提条件・修正版だけを扱います。どちらもCVE番号は付いていません。

項目	重大の勧告	高の勧告
識別番号	GHSA-2p93-cxhg-rc7q（重大）	GHSA-88m8-m5rv-pxrg（高）
内容	遠隔の機械での命令実行を中継する部品で、受け取った命令を十分に検査しないまま実行してしまう弱点	会話を区別する識別子が衝突し、別の会話と同じコンテナや作業場所を使ってしまう弱点
深刻度	重大。CVSSは9.9（勧告の本文では9.8）	高。CVSSは7.6
前提条件	運用者の役割と書き込みの権限を持つ、ログイン済みの利用者	会話を作って命令を動かせ、自分の会話の識別子に影響を与えられる利用者
影響を受ける版	0.10.12以降、20260902.02より前	20260902.03より前
修正された版	20260902.02	20260902.03

重大の勧告は、ログイン済みの利用者が、つながった遠隔の機械の上で任意の命令を実行できてしまうというものです。修正版では、命令を解釈する処理を取り除き、遠隔の機械の側で実行してよいプログラムを既定ですべて拒否し、許可したものだけを通す方式に改め、転送の前に承認を挟むようにしたと説明されています。既存の遠隔の機械は登録し直し、許可するプログラムを明示する必要があるとされます。

高の勧告は、権限の低い利用者が別の会話の隔離された状態に触れられるというもので、ファイルや保存された認証の情報、道具のデータが見えたり、相手が後で使うデータを書き換えたりするおそれがあるとされます。修正版は識別子の作り方を衝突しにくい方式に改めました。ただし、古い版で作られた会話ごとの作業場所は、更新後は自動では引き継がれないこと、既定の「共有」の作業場所はもともと会話を分けないことも、勧告に明記されています。

悪用されうるリスク

ここからは、公開情報から考えられるリスクを概要の水準で整理します。2026年10月23日時点で、これらの勧告が実際の攻撃に使われたという報告は確認できていません。以下は可能性としての整理です。最も大きいのは、修正前の版を使い続けている環境です。重大の勧告の前提はログイン済みの利用者ですが、ログインの情報が漏れた場合や、社内の複数人で一つのサーバーを共有している場合には、その前提は思ったより簡単に満たされる可能性があります。

二つ目は、チャットを入り口にする道具に共通するリスクです。AIは、受け取った文章や読み込んだウェブページ、ファイルの中に紛れ込んだ指示に引きずられることがあります（プロンプトインジェクション）。Moltisは話しかける相手を絞る仕組みを持ちますが、AIが読み込む外部の文章までは選べません。命令の実行や外部への送信の権限を持つアシスタントでは、紛れ込んだ指示が実際の操作につながるおそれがあります。

三つ目は、預けた情報の集中です。常駐型のアシスタントには、メール、チャット、外部のサービスの鍵、長期の記憶が一か所に集まります。会話の履歴は保存時に暗号化されないとされているため、サーバーそのものが乗っ取られたり、機械が盗まれたりした場合には、個人の仕事のやり取りがまとめて外に出る可能性があります。社員が私物の機械で動かしている場合、会社はその存在にすら気づけないかもしれません。

導入を検討するときに確かめること

Moltisを社内で試す、あるいは社員の利用を認めるかを判断するときは、仕組みの説明を読むだけでなく、次の順で確かめてください。どの段階でも、実際の操作は隔離した試験用の環境で行い、本番の鍵は使いません。

この順番で確かめると、道具の良し悪しよりも先に、自社が何を預け、誰が管理するのかがはっきりします。一つでも決められない項目があるなら、試験の範囲を広げる前に、その点を決めてから進むのが安全です。

企業が取るべき対策

Moltisに限らず、常駐型のAIアシスタントが社内に入り込むことを前提に、企業として打てる手を整理します。一つ目は、社員が私物の機械で動かす常駐型のAIアシスタントの扱いを、利用規程に明記することです。会社のチャットやメールの鍵を、承認のない道具に預けることを禁じるか、届け出制にするかを決めます。

二つ目は、社内で正式に使う場合の管理です。動かす機械を会社が管理するものに限り、ログインの設定を必ず行い、外部に公開しない構成を基本にします。AIに預ける鍵は、読み取りだけなど最小の権限のものを用意し、個人の鍵を流用させません。三つ目は、記録の確認です。どのチャットから誰の指示で何が実行されたかの記録を、定期的に人が見る体制を作ります。

四つ目は、更新の追随です。今回の2件の勧告は、公開と同じ日に修正版が出ています。修正版が出ても、使う側が上げなければ弱点は残り続けるため、版の確認を日常の運用に組み込みます。五つ目は、勧告の情報を集める仕組みです。社内で使うOSSの一覧を持ち、それぞれのセキュリティの画面の更新を担当者が受け取れるようにしておくと、次の勧告にも早く気づけます。

AIに任せる範囲と、人が決める範囲

常駐型のアシスタントは、人が見ていない時間にも動き続けます。だからこそ、AIに任せる範囲と、人が決める範囲を先に分けておく必要があります。AIに任せてよいのは、決められた範囲の中で、取り消せる作業を速く進める部分です。AIに判断させず、人が決めるのは、どの鍵を預けるか、誰の指示を受け付けるか、どの操作に承認を挟むか、いつ止めるかの四つです。

また、AIが何かを実行したときは、なぜその操作をしたのかの根拠を書かせ、記録に残すようにします。根拠のない操作は人が確かめるまで次に進めない、という運用にしておくと、紛れ込んだ指示に引きずられた動きにも気づきやすくなります。人が確認する範囲を先に決めておくことが、AIを道具として使い続けるための土台です。避けたい使い方は次のとおりです。

• 「自分の機械で動かすから安全」と考え、修正前の古い版を使い続ける
• 承認を求めない方式にして、命令の実行をすべてAIに任せる
• 公開や共有のチャットにつなぎ、誰の指示でも道具を使えるようにする
• 会社のメールやチャットの管理用の鍵を、個人で動かすアシスタントに預ける
• 機密のファイルを、すべての会話から読める場所に預ける

これらはどれも、道具の側の守りではなく、使う側の決めごとで防げるものです。仕組みが厚いほど安心しがちですが、最後に効くのは人が引いた線です。AIを万能の見張り役と考えず、人が確かめる場面を残してください。

よくある質問：勧告が出たOSSは避けるべきか

重大の勧告が出たということは、使うべきではないのですか

勧告が出たこと自体は、必ずしも悪い兆候ではありません。弱点を公開して修正版を出すのは、保守が続いている証拠でもあります。判断の分かれ目は、修正版が出ているか、使う側がそれに上げられる体制を持っているかです。今回の2件は修正版が出ていますが、守りの中心に関わる弱点だったことを踏まえ、試験の範囲を絞って慎重に評価するのが妥当です。

社内の一人が自宅で使っているだけなら、問題はありませんか

会社の鍵や情報を預けていなければ、影響は限られます。ただ、会社のチャットやメールとつないでいる場合、その機械の守りが会社の情報の守りになります。利用の実態を把握し、会社の情報を扱うなら届け出と版の確認を求めるのが現実的です。

手元のモデルを使えば、情報は外に出ませんか

手元のモデルを使えば、会話の中身を外部の提供元に送らずに済みます。ただし、チャットアプリをつなげば、そのアプリの提供元にはメッセージが通ります。どこまでを閉じたいのかを先に決め、つなぐ相手を選んでください。

• Moltisの機能・仕組み・限界は、GitHubのリポジトリ、README、公式のセキュリティの文書を2026年10月23日に確かめた範囲に基づきます。仕様は変わることがあるため、導入前に最新の情報を確かめてください
• セキュリティ勧告の影響を受ける版・修正された版・深刻度は、2026年10月23日時点のGitHubの勧告のページに基づきます。実際の攻撃に使われたという報告は、同日時点で確認できていません
• スター数・作成日などの数値は2026年10月23日時点のものです。この記事は防御と評価の目線で書いており、導入・設定・実行の手順は扱いません

まとめ

Moltisは、Rustで書かれた一つの実行ファイルで動く、常駐型のAIエージェントのサーバーです。MITライセンスのOSSで、チャットアプリや音声からAIに作業を頼め、命令をコンテナの中で動かし、危険な操作を人の承認に回す仕組みを備えています。一方で、2026年9月2日には、遠隔での命令実行に関わる重大の勧告と、隔離の取り違えに関わる高の勧告が公開され、それぞれ20260902.02と20260902.03で修正されました。

導入を検討するなら、修正済みの版であることを確かめ、預ける鍵・受け付ける相手・承認の範囲・更新の担当を人が先に決めることが出発点です。自分の機械で動かすことは安全の保証ではありません。守りの仕組みと限界の両方を読み、人が線を引いたうえで使うことが、常駐型のAIアシスタントとの付き合い方です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。