dtyq/magic を採用前に読む: サンドボックス、承認フロー、予算上限をどう実装しているか

Magic が解こうとしているのは「個人向けアシスタントの企業導入」という摩擦

README は冒頭で OpenClaw を名指しし、個人向け AI アシスタントとして高く評価したうえで、企業文脈に持ち込むと別の問題が出ると書いている。データが個人アカウントに散る、予算の歯止めがない、出力がプレーンテキストで止まる、危険な操作に承認ゲートがない、という 4 点だ。Magic の対象読者はこの 4 点を運用上の障害として認識している組織、具体的には情シスと、AI を部門横断で配りたい中規模以上のチームになる。README は OPC（One Person Company）や OPT（One Person Team）という語も使っており、一人法人や小規模チームも想定読者に入れている。ただし後述するように、この 2 つの層に同じ構成を勧めるのは無理がある。

構成要素は 4 つ: エージェント、ワークフロー、IM、共同編集オフィス

リポジトリの説明文は、Magic を「Generalist AI Agent + Workflow Engine + IM + Online collaborative office system」の 4 要素の統合体と位置づけている。README の 7 項目はこの 4 要素を企業向けの機能に翻訳したものだ。ナレッジ統合、成果物レンダリング、セキュリティとコンプライアンス、Human-in-the-Loop、コスト管理、チーム共同作業、そして途中で切れている「Open Ecosystem Compatib...」の項目。主言語は TypeScript、デフォルトブランチは master、ホームページは magicrew.ai。最終 push は 2026-08-12 と記録されている。ここで注意したいのは、4 要素を 1 つのリポジトリに同居させている点そのものが導入コストの主要因になるという点だ。IM と共同編集オフィスが不要な用途でも、デプロイ単位は分かれていない可能性が高い。README にはコンポーネントを個別に切り出して使う手順が示されていない。

サンドボックスと Sidecar プロキシ: 分離の単位はどこか

セキュリティの説明で具体的なのは 3 つだ。各エージェントは専用のサンドボックスコンテナ内で動き、メインシステムとは別 VPC に置かれ、プライベートエンドポイント経由で接続する。Sidecar ネットワークプロキシがユーザーごとにトラフィックを独立管理する。テナント間でリソースとデータが完全に分離される。加えて、公開前の plugin security review が悪意あるコードを検出するとある。ここから読み取れる設計上の判断は、エージェントの実行を「信頼できる境界の内側」に閉じ込めることを最優先し、そのためにネットワーク層で分離しているという点だ。プロセス分離ではなく VPC 分離を選んでいる以上、単一ノードの Docker で試す構成と、README が想定する本番構成の間にはかなりの隔たりがあると考えるのが自然だ。Sidecar をユーザー単位で立てるなら、同時実行ユーザー数に比例してネットワーク側のリソースも増える。この点について README は数値も目安も示していない。

Human-in-the-Loop と予算上限はポリシー層の機能

承認フローの説明は明確だ。エージェントが高リスク操作を試みたとき承認ワークフローが起動し、定型的な操作は自律実行、データ削除やメール送信のような破壊的操作は人間の明示的な確認を要求する。コスト管理側は「cost compass」と呼ばれ、部門別、ユーザー別、エージェント別に日次予算を設定できると書かれている。どちらもモデルやプロンプトではなく、実行を仲介する層に置かれた制御だ。つまり Magic の価値の一部は、LLM の性能とは独立に、誰が何をどこまで実行できるかを決めるポリシー記述にある。ここは設計として筋が通っている。ただし README は、承認が必要になる操作の種別をどう分類するか、予算超過時にタスクを止めるのかキューに積むのかを書いていない。運用に載せる前に、この 2 つの挙動は実装を読むか検証環境で確かめる必要がある。

成果物レンダリング: チャットで終わらせないという主張

README が繰り返し強調する差別化は、出力をテキストで止めず PPT、データダッシュボード、議事録、レポート、Excel ファイル、画像生成用の無限キャンバスとして納品するという点だ。スクリーンショットが 4 枚添えられており、企業調査レポート、ソリューション PPT、決算電話会議の分析、ポスター制作の例が並ぶ。ここは README の中で最も検証が難しい部分でもある。画像は成果物の見た目を示すが、どの入力からどの程度の人手修正でそこに到達したのかは分からない。レンダリングフレームワークが「built-in」とだけ書かれ、テンプレートの拡張方法や出力形式の制約には触れていない。既存の社内資料フォーマットに厳密に合わせる必要がある組織にとっては、この部分が導入後の最大の調整コストになりうる。

セルフホストの入口と、そこで見えなくなるもの

README のバッジに self-hosted-deployment へのアンカーがあり、本文中にも Deploy now のリンクが置かれている。つまりセルフホストが想定された配布形態だ。ただし取得できた範囲の README には、docker compose のファイル名、環境変数、必要なミドルウェア、推奨スペックのいずれも記載がない。デプロイ手順はアンカー先の節に分離されていると見られる。したがって、ここで具体的なコマンドを挙げることはできない。これは記事の都合ではなく、材料の制約だ。導入検討の最初の作業は、リポジトリの self-hosted-deployment 節とデプロイ用ファイルを直接開き、必要なコンテナ数と外部依存を数えることになる。VPC 分離と Sidecar プロキシを本番で再現するとなれば、単一ホストの compose では済まない可能性が高い。

向かないケースと、代わりに何を使うか

Magic が過剰になる典型は、1 つの LLM 呼び出しを定期実行したいだけの用途だ。その場合、IM 連携と共同編集オフィスとテナント分離を抱えた構成を維持する理由がない。README 自身が比較対象として挙げている OpenClaw は、主要 IM を会話チャネルとして接続し、任意の LLM を使い、24 時間自律実行する個人向けアシスタントだと説明されている。アプローチの違いは統制の有無だ。OpenClaw は個人が自分のアカウントと自分の判断で使うことを前提に接続性と自律性を優先する。Magic は同じ自律実行に、予算上限、承認ゲート、テナント分離という制約を上から被せる。制約が不要なら Magic の構成は純粋な重量物になる。逆に、監査や承認の説明責任が求められる組織では、OpenClaw 側に同等の統制を後付けするほうが総コストは高くつく。どちらが優れているかではなく、統制を先に買うか後から足すかの違いだ。

ライセンス表記とメンテナンス費用の見積もり

GitHub 上のライセンス表示は NOASSERTION であり、これは自動判定が既知のライセンス条項に一致しなかったことを意味する。README にもライセンス条項の説明はない。企業導入では、これは最初に潰すべき不明点だ。LICENSE ファイルを直接読み、商用利用、再配布、改変の条件と、プラグインとして配布するコードへの波及を確認する必要がある。ここで法的な助言はできない。メンテナンス面では、最終 push が 2026-08-12 と記録されていること以外、リリースノートやバージョン履歴は取得できていない。アップグレードの互換性ポリシーも不明だ。4 要素を 1 つに束ねた構成では、どれか 1 つの更新が全体の再デプロイを要求しやすい。運用チームは、コンポーネント単位で更新できるのかをデプロイ構成から先に確認しておきたい。

編集部の結論

採用を検討すべきなのは、社内 ERP や CRM を包んで「デジタル従業員」として配りたい情シス部門と、承認フローや予算上限を AI 利用の前提条件にしている組織だ。逆に、単一の LLM 呼び出しや小さなワークフローを数日で動かしたい個人開発者には、IM と共同編集オフィスまで含む構成は明らかに過剰で、OpenClaw のような個人向けアシスタントのほうが短距離で目的に届く。導入前に確認すべきは 3 点ある。第一に LICENSE ファイルの実際の条項（GitHub の表示は NOASSERTION であり、README にライセンス条項の記述はない）。第二に self-hosted-deployment の手順がどの程度のインフラを前提にしているか。第三に、plugin security review が誰の責任でどの工程で行われるのか。この 3 点が自組織の基準を満たさない限り、サンドボックス分離や予算上限の説明だけでは導入判断は下せない。

公式情報源

1. dtyq/magic on GitHub
2. Issues
3. Project website
4. README