Phantom を採用する前に読む: 自前マシンを与えられた Claude Agent SDK 製エージェントの実像
An AI co-worker with its own computer. Self-evolving, persistent memory, MCP server, secure credential collection, email identity. Built on the Claude Agent SDK.
ひと目でわかる
- これは何？
- Phantom は AI エージェントに専用マシンを与え、永続メモリ、MCP サーバー、Slack 経由の対話、自己進化の仕組みを一つにまとめた TypeScript 製の常駐型エージェントである。Apache-2.0 で公開されているが、Docker ソケットをマウントする設計と自己進化の評価ループをどう扱うかが採用判断の分かれ目になる。
- 誰に向いている？
- Slack やメールを窓口にした常駐エージェントを専用 VM 上で動かし、その作業ログや生成物を自分で管理したいチームに向く。個人のノート PC や、既存の本番 Docker ホストに同居させたい場合は避けるべきである。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 91 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
毎回ゼロから始まるチャットへの不満を、専用マシンで解こうとしている
Phantom が狙うのは、セッションを閉じれば文脈が消えるチャット型エージェントの使い捨て感をなくすことだ。README はこの問題を「Every session is day one」と表現している。解決策として提示されるのは、エージェント用の計算機を一つ用意し、そこにソフトウェアをインストールさせ、データベースを立てさせ、ダッシュボードを作らせ、前週に伝えた内容を覚えさせるという方針である。利用者のノート PC は利用者のもののままで、エージェントの作業場は別マシンになる。
対象読者は、Slack 上で動く同僚のような存在を欲しがっている開発チームか、あるいは自分でエージェント基盤を組み立てる手間を省きたい個人開発者である。README は「This is not a chatbot」と明言しており、対話の窓口は Slack、Web チャットの /chat、そしてエージェント自身のメールアドレスになる。ツールを自分で作り、許可を求めずにインフラを組む挙動が前提に置かれている。
本体は Claude Agent SDK で、記憶は Qdrant、埋め込みは Ollama が担う
リポジトリ情報では主要言語が TypeScript、実行環境として Bun と Docker が topics に挙がっている。エージェント本体は Claude Agent SDK の上に構築されていると説明されている。Docker での起動時には Qdrant がメモリ用に起動し、Ollama が埋め込みモデルを取得する。つまり永続メモリはベクトル検索側のコンポーネントに預けられ、エージェントの推論そのものとは別プロセスで動く。
外部との接続は MCP サーバー経由で拡張される。README の事例では、エージェントが自分で作った REST API を MCP ツールとして登録し、後のセッションや他のエージェントからも同じ API を引けるようにしたと書かれている。チャネルは Slack、Telegram、Email、Webhook が同梱で、Discord は同梱されていない。同梱外のチャネルが必要になった場合、エージェント自身が Discord Bot API の説明を行い、トークンを安全に受け取るためのリンクを提示し、保存後にコンテナを起動する流れを README は示している。
自己進化については、プロバイダ設定の説明の中で「every evolution judge flow through the chosen provider」と触れられている。進化の判定を行う仕組みが本体のモデル選択と連動していることが読み取れるが、判定の基準や頻度は README の範囲では確認できない。
起動は docker compose up -d の三手で、設定は .env と phantom.yaml に分かれる
README が推奨するのは Docker 経由である。手順は次の三つで完結する。
curl -fsSL https://raw.githubusercontent.com/ghostwright/phantom/main/docker-compose.user.yaml -o docker-compose.yaml curl -fsSL https://raw.githubusercontent.com/ghostwright/phantom/main/.env.example -o .env docker compose up -d
.env には ANTHROPIC_API_KEY、Slack のトークン、OWNER_SLACK_USER_ID を入れる。メール送信を使うなら RESEND_API_KEY を追加する。起動後は http://localhost:3100/health で状態を確認でき、Slack を設定していれば準備完了時に DM が届くと説明されている。
モデルの切り替えは phantom.yaml の provider ブロックで行う。README の例では type: zai、api_key_env: ZAI_API_KEY、model_mappings に sonnet: glm-5.1 を指定し、.env に ZAI_API_KEY を置いて再起動する。同梱のプロバイダは Anthropic、Z.AI、OpenRouter、Ollama、vLLM、LiteLLM、そして Anthropic Messages API 互換の任意エンドポイントである。切り替えてもツール、メモリ、自己進化のパイプラインは同じままで、変わるのは推論部分だけだと README は述べている。
Docker ソケットのマウントは設計上の意図的なトレードオフである
README のセキュリティ注記は明確である。docker-compose.yaml は /var/run/docker.sock を Phantom コンテナにマウントする。これはサンドボックス化されたコード実行などのために兄弟コンテナを起動できるようにするための措置で、意図的なアーキテクチャ上のトレードオフだと書かれている。同時に、このソケットはコンテナに Docker デーモンへの root 相当のアクセスを与えるため、Phantom プロセスが侵害されればホスト上の任意のコンテナを作成、変更、破壊できると明記されている。
緩和策として README が挙げるのは、専用マシンか VM で動かすこと、個人のワークステーションでは動かさないことである。この一点だけで、Phantom を既存の共有 Docker ホストに相乗りさせる選択肢は現実的でなくなる。エージェントに「許可を求めずにインフラを組む」権限を与えるという商品説明と、この注記は表裏の関係にある。利便性の源泉がそのまま攻撃面になっている。
README の成功事例はすべて本番インスタンスの話で、再現手順は付いていない
ClickHouse を導入して Hacker News の 2,870 万行を読み込み、分析ダッシュボードと REST API を作った話、3 スターの監視ツール Vigil を見つけて ClickHouse に統合し、890,450 行、25 メトリクスの自動更新ダッシュボードを組んだ話が掲載されている。いずれも「These are not mockups」と断った上での本番環境の出来事である。
ただし、これらは事例紹介であって検証可能なベンチマークではない。どのモデルで、どのくらいの時間とトークンを消費し、何回失敗したのかは書かれていない。エージェントに計算機と権限を与えれば必ずこの種の成果が出る、という主張にはなっていない点は公正である。逆に言えば、同じ構成を組んでも同じ結果になる保証はどこにもない。導入検討時には、こうした事例を能力の証明ではなく、権限を与えたときに起こりうる挙動の範囲を示す資料として読むのが妥当である。
汎用のワークフロー自動化とは、状態をどこに置くかが根本的に違う
比較対象として分かりやすいのは n8n や Temporal のようなワークフロー基盤である。これらは処理の手順を人が定義し、状態は外部のデータベースやキューに置かれ、実行のたびに同じ経路をたどることが期待される。再現性と監査が設計の中心にある。
Phantom は逆で、何をするかをエージェント自身が決め、成果物と記憶を自分のマシン上に蓄積する。同じ依頼でも経路は毎回変わりうる。決まった手順を確実に回したいならワークフロー基盤の方が適しており、Phantom をそこに使うのは過剰である。一方で、依頼の内容が事前に決められない探索的な作業、たとえば未知のデータセットを調べて必要なツールを自分で揃えるような仕事は、手順を先に書けないという理由でワークフロー基盤に向かない。Phantom の README が挙げる事例はすべてこの後者の種類である。
もう一つの違いはモデルの固定度である。ワークフロー基盤は LLM を呼ぶノードの一つとして扱うが、Phantom はモデル選択がエージェント全体の設定であり、自己進化の判定まで同じプロバイダを通る。
Apache-2.0 と、常駐させるコンポーネントの数
ライセンスは Apache-2.0 で、リポジトリはアーカイブされていない。最終 push は 2026-06-16 である。README にはバージョン 0.20.2 と表示されており、取得できた範囲ではリリースノートはない。0.x 系であること、そして自己進化という性質上、内部のツール定義やメモリ形式がバージョン間で変わりうることは前提に置いた方がよい。アップグレード時の確認対象は phantom.yaml の provider ブロックと .env のキー名である。README でもプロバイダ追加時に既存デプロイが設定変更なしで動き続けると説明されているため、設定ファイルの互換性は意識されている。
運用コストの面では、Phantom 本体に加えて Qdrant と Ollama が常駐する。Docker での起動説明がそうなっている以上、最低でもこの三つ分のメモリとディスクを見込む必要がある。エージェントが自分で ClickHouse や監視スタックを追加で導入する事例が README に載っていることも踏まえると、専用マシンのリソースは最初から余裕を持たせておくべきである。ライセンス条件の解釈はここでは扱わない。
導入前に潰しておくべき三つの確認事項
第一に、docker-compose.yaml の /var/run/docker.sock マウントを外した状態で、どこまで機能が残るかを自分の環境で確かめること。README はサンドボックス化されたコード実行のためにこのマウントが必要だと説明しているので、外せばその機能は落ちる。落ちた状態で用途が足りるなら、侵害時の影響範囲は大きく縮む。
第二に、phantom.yaml の provider を Anthropic 以外にしたとき、自己進化の judge が期待通りに動くかを確認すること。README は judge も選択したプロバイダを通ると書いているが、判定の品質がプロバイダ間で同等かどうかには触れていない。
第三に、OWNER_SLACK_USER_ID の設定である。Slack 経由で DM を送る相手を決めるキーであり、ここを誤ると意図しない相手にエージェントの出力が届く。Slack を設定しなければ DM 通知は来ないが、/chat とメールの経路は残る。エージェントに専用マシンと root 相当の権限を与える構成である以上、これらの確認を省いて動かし始めるのは勧められない。
編集部の結論
Slack やメールを窓口にした常駐エージェントを専用 VM 上で動かし、その作業ログや生成物を自分で管理したいチームに向く。個人のノート PC や、既存の本番 Docker ホストに同居させたい場合は避けるべきである。導入前に確認するのは、docker-compose.yaml の /var/run/docker.sock マウントを外した状態でどこまで動くか、phantom.yaml の provider ブロックで既存の Anthropic 以外を選んだときに自己進化の judge が同じモデルで通るか、そして Qdrant と Ollama の分だけ増える常駐プロセスのリソースである。
コミュニティノート