専用の仮想マシンで働くAIの同僚をつくるOSS「Phantom」の仕組みと導入前の注意点

「AIに専用のパソコンを持たせて、頼まなくても仕事を進めてくれる同僚にできるらしい。うちでも試してよいか」「社員が個人の判断で、AIエージェントにSlackとメールの権限を渡し始めている。どこから止めればよいのか」——AIエージェントの業務利用が広がるなかで、情報システム部門やセキュリティの担当者に寄せられる相談です。どちらも、便利な道具を入れるかどうかの話に見えます。しかし本当に問われているのは、道具の出来ではありません。AIに自分の機械と身元を与えたとき、その行動の責任と範囲を誰がどう決めるのかという点です。この記事では、AIエージェントに専用の仮想マシンとメールアドレスを与え、記憶と自己改変で育てるOSS「Phantom」を取り上げ、一次情報で確かめられる仕組みと、導入前に押さえるべき注意点を整理します。導入や設定の手順は扱いません。

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

Phantomは、GitHubで公開されているAIエージェントのソフトウェアです。リポジトリの説明文は「自分の計算機を持つAIの同僚」で、自己進化、長く残る記憶、MCPサーバー（AIと外部の道具をつなぐ共通の取り決めに沿った窓口）、認証情報の安全な収集、メールでの身元を特徴に挙げています。READMEによると、Claudeの開発用の部品の上に作られています。会話のたびに文脈が消える対話型のAIではなく、ずっと動き続ける同僚として設計されている点が、ほかのAIエージェントとの大きな違いです。

配布の形を確かめます。リポジトリはGhostwrightという組織のアカウントで2026年3月26日に作られ、ライセンスはApache-2.0です。2026年10月26日時点でスターは1,483、派生は190、未解決の課題と変更の提案は合わせて65件です。最新のタグは0.20.2で、GitHubの「リリース」の欄には版の公開記録が見当たりませんでした。リポジトリへの最後の反映は6月16日ですが、既定の枝で確認できる最新の変更は2026年5月2日のもので、それ以降は別の枝の動きにとどまっています。

組織のアカウントは2026年2月19日に作られ、公開しているリポジトリは6件、フォロワーは76です。READMEでは、Phantomは同じ組織の4つ目の製品とされ、画面の読み取りを担う道具や、仮想マシンを用意する道具（Specter）と並べて紹介されています。所在地や代表者などの情報は、確認した範囲のリポジトリと公式サイトには書かれていませんでした。運営の実績を判断する材料は、まだ限られていると見るのが妥当です。

なぜ「AIに自分の機械を持たせる」発想が出てきたのか

READMEは冒頭で、いまのAIエージェントは使い捨てだと述べています。会話を閉じれば文脈が消え、次は一からやり直しになる。そこでPhantomは、AIに専用の機械を与え、ソフトを入れ、データベースを立て、先週言われたことを覚え、日ごとに仕事がうまくなる存在にする、と説明しています。社員のパソコンはそのまま社員のものとして残り、AIの作業場所は別に置く、という整理です。

READMEの比較表では、利用者の端末で動く従来のAIエージェントは端末のファイル全体に触れうるのに対し、Phantomは隔離した仮想マシンで動き、何を見せるかを利用者が決められる、とされています。作ったものは公開の住所（認証つき）で同僚や顧客に共有でき、24時間動き続けるとも書かれています。端末から切り離す考え方そのものは、防御の観点からも理にかなっています。

ただし、READMEには同時に、Phantomは許可を求めずにインフラを組み立てる同僚だという一文があります。実例として、頼まれていないのに分析用のデータベースを立て、大量のデータを読み込み、画面と外部向けの窓口まで作った話が「誰も頼んでいない」と添えて紹介されています。自律して動くことを売りにしている以上、企業が気にすべきなのは機械の分離よりも、その機械の中で何を許すかです。

専用の機械と窓口：Slack・ウェブ・メールで話しかける仕組み

READMEと窓口の文書によると、PhantomにはSlack、ブラウザーで使う対話画面、Telegram、メール、ウェブフック（外部のシステムから合図を送る仕組み）などの窓口があります。どの窓口から話しかけても、同じ記憶が使われると説明されています。動かす場所は、自分で用意した機械か、開発元が用意する管理型の環境です。

Slackの窓口では、必要な権限の一覧が文書に示されています。公開と非公開のチャンネルの投稿を読む権限、招待されていない公開チャンネルにも投稿できる権限、個人あてのメッセージを読み書きする権限、反応の絵文字を読む権限などです。非公開のチャンネルや個人あてのやり取りまで読める権限が既定の一覧に入っていることは、社内のSlackにつなぐ前に必ず確かめたい点です。反応の絵文字は、自己進化の材料として使われるとも書かれています。

話しかけてよい人は、文書の説明では、設定した持ち主のSlackの利用者番号で絞り込まれます。ブラウザーの対話画面は、メールで届く一度きりのリンクでログインし、30日有効の記録で利用者を見分ける方式です。Slackを使わない場合、そのリンクを送るために外部のメール配信サービス（Resend）の鍵を設定する前提になっています。持ち主の身元を確かめる仕組みが、どの外部サービスに依存しているかも、導入前に一覧にしておく対象です。

記憶と自己進化：AIが自分の設定を書き換える仕組み

記憶の文書によると、Phantomの記憶は三層に分かれます。会話の要約や使った道具を残す「出来事の記憶」、利用者の好みや社内の事情などの「事実の記憶」、作業の進め方を残す「手順の記憶」です。記憶はベクトル検索用のデータベース（Qdrant）に入り、会話のたびに関連する記憶が最大で約5万トークン分、AIへの指示に組み込まれます。文書の例には「この人が主なレビュー担当で、テストの網羅を気にする」といった、同僚個人についての情報も記憶の対象として挙げられています。

自己進化は、会話が終わるたびに振り返りを行い、AIが自分の設定ファイル（話し方、利用者の好み、業務の知識、手順など）を書き換える仕組みです。自己進化の文書では、書き換えの後に機械的な検査をかけ、変えてはいけないファイルが変わっていないか、認証情報らしい文字列が紛れていないか、増減が大きすぎないかを確かめ、問題があれば元に戻すと説明されています。変えてはいけない8つの原則（データを持ち出さない、自分の安全装置を書き換えない、記録を残し続けるなど）を「憲法」と呼んで固定しています。

一方で、同じ文書は、三層の防御をすり抜ける微妙な価値観のずれは、受け入れた残りの危険だと明記しています。開発元の方針文書も、十分に巧妙な悪意ある入力が、時間をかけてAIの振る舞いに影響しうると認めています。記憶と自己改変は、外から届いた文章が長く残る入口にもなるという前提で扱う必要があります。

自分で道具を作る機能とMCPでの公開

Phantomは、動いている間に自分で新しい道具を作り、MCPの道具として登録できます。登録した道具は再起動しても残り、MCPでつないだ別のAIエージェントからも呼び出せると説明されています。READMEは、外部の対話用の道具を自作して古い回避策をやめた例を紹介しています。道具の中身は、シェルの命令か、機械上に置いたスクリプトの二種類です。

MCPの窓口は、合言葉（トークン）で利用者を見分け、権限を「読む」「操作する」「管理する」の三段階に分けています。道具の登録は最上位の「管理する」権限だけに許され、その理由を文書は動的な道具は任意のコードを実行できるからと説明しています。合言葉は元の文字列ではなく変換した値で保存され、利用者ごとに1分あたり60回の上限がある、とされています。

開発元の文書によると、自作の道具は、鍵や合言葉を渡さない最小限の環境で別の処理として動きます。以前は文字列をそのままコードとして実行する方式もありましたが、遠隔からのコード実行を防ぐための最優先の修正として取り除かれたと書かれています。過去に、任意のコード実行につながる方式が入っていたことは、作り手の注意深さを示すと同時に、この種の機能が危うさと隣り合わせであることを物語っています。

認証情報の収集と、AIが持つメールアドレス

READMEは、認証情報（他のサービスの鍵や合言葉）を設定ファイルに平文で書かず、暗号化したフォームで集めると説明しています。開発元の方針文書によると、集めた情報は配置ごとの鍵で暗号化（AES-256-GCM）して保管されます。READMEの実例では、Phantomが利用者に他社のチャットサービスの鍵を送るためのリンクを渡し、受け取った鍵を使って自分で新しい窓口を立ち上げたと紹介されています。

ここで押さえたいのは、保管が暗号化されていることと、AIが鍵を求めてくることは別の問題だという点です。AIのほうから「このリンクから鍵を登録してください」と頼む流れが当たり前になると、社員が、AIに頼まれれば社外のサービスの鍵を渡してよいと思い込むおそれがあります。誰の権限の鍵を、どの目的で、どこまでの範囲で渡すかは、AIではなく社内の決まりで判断する事柄です。

もう一つの特徴が、Phantomごとに独自のメールアドレスを持つことです。READMEは、Slackの外にいる人へ報告を送る用途を挙げ、毎週の報告を「自分のメールアドレスから」送る例を示しています。窓口の文書では、一般的なメールの受信と送信の仕組みで、既存のメールサービスのアカウントを使う形が説明されています。AIが会社の名前で社外にメールを出せる状態は、なりすましや誤送信の観点で、人の社員と同じ扱いが必要です。

開発元が認める危険：管理者と同等の権限とネットワーク

READMEの導入の節には、開発元自身による安全上の注記があります。標準の構成では、コンテナの管理機能の窓口をPhantomのコンテナに渡しており、それはその機械のコンテナを作る・変える・消すことが自由にできる、管理者と同等の権限だと書かれています。Phantomの処理が乗っ取られれば、同じ機械のどのコンテナも操作されうる、という意味です。

開発元は対策として、個人の作業用のパソコンではなく専用の機械か仮想マシンで動かすこと、信頼できない処理にこの窓口を見せないことを挙げています。方針文書では、この設計はエージェントがもともと機械の操作を全面的に許されている以上受け入れられる、と説明されています。あわせて、エージェントは外部のサービスを呼び出し、ソフトやデータを取り込めるネットワークの接続を持ち、ネットワークを遮断すると役に立つ仕事ができないため、意図的にそうしているとも明記されています。

開発元がこれらを隠さずに書いている点は評価できます。ただ、企業にとっての意味は明確です。Phantomを動かす機械は、AIが管理者として振る舞い、外部と自由に通信する機械として扱う必要があります。社内のネットワークや本番のデータと同じ場所に置けば、隔離の効果は大きく損なわれます。

開発元が説明する守りの層と、その限界

守りの文書は、8つの層で守ると説明しています。持ち主だけが話しかけられる仕組み、変えられない原則、自己進化の変更を別のモデルが審査する仕組み、危険な命令の遮断、自作の道具の隔離、MCPの合言葉と権限、ネットワークの防火壁（同じ組織の道具で用意した場合）、MCPのやり取りの記録です。以下の表は、2026年10月26日に文書を読んだ範囲の整理です。

守りの仕組み	開発元の説明	文書に書かれた限界・前提	導入側が確かめること
危険な命令の遮断	破壊的な命令を実行前に止める	安全の境界ではなく補助と明記	遮断に頼らない権限の絞り込みをしたか
変えられない原則	8つの原則を自己進化から守る	微妙なずれは受け入れた残りの危険	原則の中身を自社の決まりと照らしたか
自己進化の審査	変更を検査し、失敗なら元に戻す	審査の方式の説明が文書で食い違う	変更の履歴を誰がいつ確かめるか
自作の道具の隔離	鍵を渡さない最小限の環境で動かす	道具自体は任意の命令を実行できる	登録できる権限を誰に渡すか
MCPの合言葉	三段階の権限と回数の上限	鍵の保護は利用者の責任	発行した合言葉の一覧と失効の手順
記録	MCPのやり取りを記録する	入力は200字で切り詰めて残す	記録の保存先と見る人を決めたか

表の左から二列目は開発元の自己申告で、第三者が検証した結果ではありません。とくに危険な命令の遮断について、文書は決まった型に当てはまる明らかな破壊的命令を止めるだけで、安全の境界ではないとはっきり書いています。守りの本体は原則、審査、持ち主の制限だとされていますが、その審査の方式も次の節で見るとおり文書によって説明が異なります。

文書どうしの食い違いをどう読むか

一次情報を読み比べると、同じ仕組みについて文書ごとに説明が異なる箇所がありました。一つ目は自己進化の審査です。READMEと守りの文書は、三つの判定役のモデルが投票し、一つでも反対すれば変更を止めると説明しています。これに対し自己進化の文書は、以前の6つの判定役による内容の審査は、費用がかかり効果がなかったため削除したと書き、機械的な検査と変えてはいけないファイルの照合に置き換えたと読める内容になっています。

二つ目はログインのリンクです。守りの文書では、一度きりのリンクは30分で切れ、メール配信サービスで送られるとされます。一方、方針文書では、リンクの有効期限は10分で、Slackの個人あてメッセージで持ち主に届けると書かれています。どちらが現在の動きなのかは、文書からは確定できませんでした。守りの説明が版の更新に追いついていない可能性を考えておく必要があります。

食い違いそのものは、更新の速いソフトウェアではよく起こります。ただし、導入を判断する材料として文書を使うなら、どの文書のどの記述を根拠にしたかを記録し、気になる点は動かす前に開発元に問い合わせるのが確実です。社内の審査の資料に「三重の審査がある」とそのまま書くと、実際の動きと違う説明になりかねません。

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

このラインでは、取り上げる題材を、公開されている事実だけで精査しています。題材を入手したり動かしたりはしていません。Phantomの判定は「注意付き」です。ライセンスはOSI承認のApache-2.0で、GitHub上にこのリポジトリのセキュリティ勧告は登録されていませんでした。スターの伸びは1日あたり約6.9件で、不自然な水増しの目安には当たりません。

注意付きとした根拠は三つです。一つ目は運営の実績です。組織のアカウントは2026年2月に作られ、フォロワーは76で、実績を判断するための期間と材料がまだ乏しい状態です。二つ目は機能の性質です。認証情報を集める機能と独自のメールアドレスを持ち、管理者と同等の権限で機械を操作するため、誤用や乗っ取りのときの影響が大きくなります。三つ目は更新の状況で、最後の反映は2026年6月、既定の枝の更新は5月で止まっています。

脆弱性の報告窓口は方針文書に定められており、48時間以内の受領連絡、30日以内の修正といった目標が書かれています。ただし窓口は個人の無料メールのアドレスで、修正の対象は最新の版だけとされます。勧告がないことは弱点がないことを意味しません。精査は公開情報の範囲に限られ、コードの中身や実際の動きを検証したものではないため、安全の保証にはならない点を添えておきます。

管理型の提供と、開発元の範囲外とされること

公式サイトでは、開発元が用意する仮想マシンでPhantomを動かす管理型の提供が案内されています。サイトの説明では、最初の利用者は無料で、仮想マシンの費用は開発元が持ち、AIモデルの費用は利用者が自分の鍵で払う形です。利用者のモデルの鍵は暗号化して保管し、記録に残さないと書かれています。一方、確認した範囲では、データの保存期間、開発元の担当者が中身を見られるかどうか、利用規約やプライバシーの方針は見つけられませんでした。

管理型を使うと、AIの記憶、Slackやメールでのやり取り、集めた認証情報が、実績の浅い組織の用意した機械に置かれることになります。外部の委託先としての審査を通さないまま、社員が個人で申し込める形である点は、情報システム部門として把握しておきたいところです。公開の住所で作ったものを共有する機能も、どの範囲の人が見られるかを確かめる必要があります。

方針文書は、開発元が脆弱性として扱わないものも挙げています。AIモデル自体への指示の乗っ取り（プロンプトインジェクション）、自分で用意した環境の設定の誤り、依存する外部の部品の弱点、AIモデルの鍵の保護です。裏を返せば、外から届く文章による乗っ取りへの備えと環境の守りは、使う側の責任とされているということです。

悪用されうるリスク

Phantomは業務を手伝うためのソフトウェアで、攻撃のための道具ではありません。それでも、使い方しだいで生まれうる危険はあります。以下は推測を含む整理で、Phantomが実際に悪用された事例は、2026年10月26日時点で確認した一次情報からは見つけられませんでした。

一つ目は、外から届く文章による誘導です。Phantomはメール、Slack、ウェブの情報を読み、命令を実行し、ネットワークにつながります。届いたメールやページに紛れた指示にAIが従えば、記憶に偽の事実が書き込まれたり、集めた情報が外へ送られたりする筋書きは考えられます。記憶と自己進化があるため、その影響が一度の会話で終わらず残る可能性もあります。二つ目は、AIの持つメールアドレスの悪用です。乗っ取られた場合、会社の名前で社外にもっともらしいメールを送られるおそれがあります。

三つ目は、個人に関わる情報の扱いです。READMEは、営業の候補企業の調査や、採用候補者を調べて公開の紹介ページを作る使い方を例に挙げています。AIが人を調べてページにする作業は、本人の知らないところで個人の情報を集め、外から見える形にすることにつながりえます。四つ目は、使われなくなった機械が動き続けることです。24時間動く設計のため、担当者が異動しても、鍵と権限を持ったまま放置される可能性があります。

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

実際に検討するときは、動かす前の段階で、文書と社内の取り決めで確かめられる点から整理します。下の手順は、ソフトウェアを動かす前に終えられるものに絞っています。

この手順の要は、機能を試す前に、何を許し、どこに置き、どう止めるかを決めることです。自律して動くエージェントは、動かし始めてから範囲を狭めるのが難しいため、順番を逆にしないことが大切です。

企業が取るべき対策

一つ目は、AIエージェントを社内のサービスにつなぐ行為を、申請と承認の対象にすることです。Phantomのように、社員が個人でSlackやメールの権限を渡せる道具は増えています。どのAIが、どの窓口に、誰の権限でつながっているかの台帳を作り、つなぐ前に情報システム部門が確かめる流れにします。二つ目は、AIの持つメールアドレスや公開の住所を、人の社員のアカウントと同じ規程で扱うことです。送信の範囲、署名、社外への公開の可否を決めます。

三つ目は、AIが動く機械を、管理者の権限を持つ外部向けの機械として扱うことです。社内のネットワークから切り離し、外部への通信を記録し、置くデータを絞ります。四つ目は、記憶と自己進化の中身を定期的に確かめることです。記憶に個人の情報や機密が溜まっていないか、自己進化で振る舞いがどう変わったかを、人が決まった間隔で読む仕組みにします。開発元は版の履歴が残り、元に戻せると説明していますが、見る人がいなければ変化に気づけません。

五つ目は、外から届く文章への備えです。開発元はAIモデルへの指示の乗っ取りを自分たちの範囲外としています。AIが読むメールやページは信頼できない入力として扱い、外部への送信や鍵の利用など影響の大きい操作の前に人の承認を挟みます。そのうえで、AIを止める担当と手順を決め、異動や退職のときに鍵を失効させる流れに組み込みます。

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

Phantomは、AIに機械の操作、道具の作成、外部との通信、自分の設定の書き換えまで任せる設計です。READMEは、AIが頼まれずに仕組みを組み立てた例を誇らしげに紹介しています。だからこそ、先に決めるのは、AIに判断させない部分です。

具体的には、どの窓口と鍵を渡すか、社外へ何を送ってよいか、新しい道具の登録を誰が承認するか、記憶と自己進化の変化を誰が確かめるか。この四つはAIに委ねず、人が決めて記録に残します。AIには、操作の前に理由と根拠を書かせ、人が確かめられる形にしておくのが基本です。やってはいけない向き合い方を挙げます。

• 専用の機械で動くから安全だと考え、機械の中で何を許すかを決めない
• AIに頼まれるまま、社外のサービスの鍵を登録用のリンクから渡す
• AIのメールアドレスから社外へ送る内容を、人が確かめずに任せる
• 「三重の審査がある」というREADMEの説明を、自社で確かめずに社内の審査資料へ書き写す
• 管理型の提供を、委託先の審査を通さずに個人の判断で申し込む
• 記憶や自己進化の履歴を、誰も読まないまま動かし続ける

裏を返せば、人が決める範囲ははっきりしています。何を渡し、何を送らせ、何を承認し、誰が見るか。この四つが決まらないまま自律型のエージェントを入れても、便利さと引き換えに、説明のつかない行動の記録が増えるだけです。

よくある質問：社員が個人で試すのは止めるべきか

一律に禁止するより、試してよい条件を決めるほうが現実的です。会社のSlack、会社のメール、会社の鍵につながない、検証用の独立した環境で、公開されている情報だけを扱う範囲であれば、仕組みを学ぶ価値はあります。問題になるのは、会社の窓口や鍵につないだ瞬間です。その段階に進む前に、申請と承認の流れを通すよう決めておきます。

「Apache-2.0なら商用でも自由に使えるのか」という問いもありそうです。Apache-2.0は商用での利用を認めるOSI承認のライセンスで、ライセンスの面での制約は小さいと言えます。ただし、ライセンスが使ってよいと言っていることと、安全に使えることは別の話です。この記事で見てきた権限の強さ、運営の実績、文書の食い違いは、ライセンスとは別に判断する必要があります。

最後に、「開発元が危険を正直に書いているなら信頼してよいのか」という問いです。危険を文書で認めている点は、何も書かないより評価できます。しかし、認めた危険を引き受けるのは導入する側です。開発元の説明は判断の出発点として読み、自社の環境でどう抑えるかを自分たちで決めることが欠かせません。

• Phantomの機能・守りの仕組み・更新の状況は、GitHubのリポジトリとその中の文書、公式サイトを2026年10月26日に確かめた範囲に基づきます。開発の状況によって変わる可能性があります
• 文書どうしで説明が異なる点は、どちらが現在の動きかを確定できていません。導入を判断する前に開発元に確認してください
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

Phantomは、AIエージェントに専用の仮想マシン、Slackやメールの窓口、独自のメールアドレス、三層の記憶、自分で道具を作る機能を与え、会話のたびに自分の設定を書き換えて育てるOSSです。ライセンスはApache-2.0で、セキュリティ勧告は登録されていません。開発元は、管理者と同等の権限、自由なネットワーク接続、自己改変が誘導されうることを文書で認めています。

一方で、運営する組織は2026年2月に作られたばかりで、既定の枝の更新は5月から止まり、守りの説明には文書どうしの食い違いもあります。判定は注意付きです。機械を分けるだけで安心せず、何を許し、どこに置き、誰が見て、どう止めるかを先に決めることが、Phantomのような自律型のエージェントを検討するときの出発点です。

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