polterguy/magic を採用する前に読む: Hyperlambda と MCP で組むセルフホスト型フルスタック生成

既存データベースに後から安全な API を被せる、という出発点

このプロジェクトが解くのは、すでに動いているデータベースに対して、認証とロール制御つきの REST API を後付けする作業だ。README は、MySQL、PostgreSQL、SQL Server、MariaDB の既存スキーマを指定すると CRUD API が得られると説明している。API Wizard の実演では chinook データベースが 54 個の保護された REST エンドポイントに変換される様子が示されている。

対象読者は、レガシーなスキーマを抱えたバックエンド担当者と、社内ツールを短いサイクルで出したい小規模チームだ。CRM、管理画面、予約システム、業務ツールといった用途が README に列挙されている。フロントエンドだけを生成するツールではなく、データベース、API、認証、RBAC、ジョブまでを一つの実行環境に含める点が、Lovable や Bolt との違いとして README 自身が挙げている位置づけである。

Hyperlambda を実行する .NET ランタイムという構成

中核は Hyperlambda という言語と、それを解釈せずコンパイル済み .NET ランタイム上で走らせる実行モデルだ。README の比較表では、n8n、Zapier、Make が JSON や YAML のワークフローを解釈するのに対し、Magic はコンパイル済みランタイムで動くと対比されている。ロジックをデータとして解釈するのではなく、コードとして実行する側に倒している。

データの流れはこうだ。ダッシュボードの Hyper IDE でファイルを編集し、保存するとその場で実行できる。デプロイやパブリッシュの工程が挟まらないと README は明記している。Playground は保存せずに Hyperlambda を実行する場所として用意されている。保存されたファイルは modules フォルダ配下に置かれ、MCP プラグインを入れると、そこにある HTTP エンドポイントが一つずつエージェントから呼べるツールに変わる。

生成側の設計も特徴的だ。Hyperlambda Generator はテキストではなく AST を出力し、存在しない関数が含まれていれば解析段階で拒否される。README の表現を借りれば「hallucinated function invocations を返すことはできない」。ただし論理的に誤ったコードは書ける、と README 自身が但し書きを付けている。関数の存在保証と、処理内容の正しさは別問題である。

サンドボックスと関数単位の RBAC という安全モデル

Hyperlambda はサンドボックス内で動作し、サンドボックス外のファイルシステムにはアクセスできない。加えて RBAC によって個々の関数をホワイトリスト化できる。README はこれを、サーバーがコードを入力として受け取り、その出所を知らないまま安全に実行できる仕組みだと説明している。呼び出しを実行レベルで制限する言語は他に知らない、というのが README の主張だ。

この設計が効くのは、AI エージェントにツール空間を動的に広げさせたい場面である。語彙を制限しつつ、必要な関数だけを許可する。攻撃面を広げずに機能を足せる、というのが README の言い分である。

ただし、これは README が提示している設計意図であって、第三者が検証した結果ではない。README には、バックエンドの重大なセキュリティバグに 100 ドル、自然言語 API の攻略にさらに 100 ドルを払うという記述がある。自然言語 API は 3 か月間、誰でも入力できる状態で破られていないと書かれている。金額と期間が示されている点は具体的だが、これは提供者自身による挑戦の告知であり、監査結果ではない。導入検討時は、この主張を前提にせず、公開されている修正履歴を自分で追うべきだ。

起動は docker compose の 1 行から、ポートは 5555 と 4444

README が示す起動手順は短い。

curl -fsSL https://hyperlambda.dev/docker-compose.yaml | docker compose -f - up

起動後、localhost:5555 を開き、接続先として localhost:4444 を指定し、root / root でログインする。5555 がダッシュボード、4444 がバックエンド側のポートという役割分担だと読める。

設定の入口はダッシュボードのサイドバーに集約されている。Hyper IDE はファイルの編集、実行、そして再生(replay)を担う。Playground は保存前の実行用。SQL Studio はクエリとスキーマ設計。Endpoint Generator はテーブルから保護された CRUD エンドポイントを作り、OpenAPI や Swagger の URL を貼れば Stripe、GitHub、Slack などの仕様を型付きエンドポイントとして取り込む。このほかユーザーとロール、スケジュールタスク、機械学習、プラグインストアが並ぶ。

MCP を使う場合は mcp プラグインを導入し、Claude Code、Cowork、OpenAI の Codex などから cloudlet の URL を指定する。ダッシュボード上部に表示される MCP URL をそのまま渡す形になる。

README の数値をそのまま採用根拠にできない理由

README には性能とトークン消費の数値が並ぶ。Hyperlambda は FastAPI や Flask より約 20 倍速く、LangChain より約 50 倍、n8n、Zapier、Make のようなグラフィカルなワークフローツールより 100 から 1,000 倍速いとされる。C# と Entity Framework とは性能・スケーラビリティの両面でほぼ同等とも書かれている。MCP プラグインについては、トークン消費がおよそ 80 パーセント減るという計測結果が示されている。

これらはいずれも README 自身が「our measurements」と断っている自己計測値である。条件、データセット、ハードウェア、比較対象のバージョンは README からは分からない。したがって、導入判断の根拠にはできない。80 パーセントという数字も、どのエージェント、どのタスクでの話かは示されていない。

検証するなら、自分のデータベースと自分のエンドポイント群を用意し、MCP 経由で同じタスクを実行したときのトークン数と応答を比較するのが最短だ。性能側は、Hyperlambda の処理と同等の C# 実装を並べて測る以外に、README の倍率を確かめる方法はない。

向かない場面: フロントエンドの作り込みと Hyperlambda の保守

このプロジェクトはバックエンドとエンドポイント生成に重心がある。フロントエンドは React と Vite のダッシュボードとして提供されるが、生成されるアプリの見た目を細かく制御したい場合、Lovable や Bolt のようにフロントエンド中心で設計されたツールのほうが素直な選択になる。README の比較表でも、Lovable と Bolt はフロントエンドとサードパーティ BaaS を担当範囲としており、バックエンドの有無が両者の分かれ目になっている。

もう一つの制約は言語そのものだ。Hyperlambda は独自言語であり、既存の C# や Python の知識はそのまま移らない。ロジックを自然言語で生成できるとはいえ、生成されたコードを読んで直せる人がチームにいなければ、問題発生時の切り分けは難しくなる。README は AI が関数の存在を保証すると述べているが、論理の誤りは残ると明記している。この但し書きは、生成物をレビューする前提で運用するべきだということを意味する。

代替として挙げるなら n8n だ。n8n は JSON ベースのワークフローを解釈する実行モデルで、外部 SaaS との連携ノードが中心にある。Magic はコンパイル済みランタイムでコードとして実行し、データベースと認証を内側に持つ。連携の網羅性を優先するなら n8n、データの所在と実行性能を優先するなら Magic、という切り分けになる。

ライセンスと更新コスト

ライセンスは MIT で、リポジトリには LICENSE ファイルが置かれている。README の比較表でも「MIT, fully open source」と明示されている。MIT は商用利用を含めて制約が少ない条件だが、具体的な義務や同梱物の扱いは案件ごとに変わるため、法務判断はここでは扱わない。

更新頻度は高い。直近のリリースは v23.5.19(参照ファイルのダウンロードに関するセキュリティパッチ)、v23.5.18(CSV スロットでの BOM 文字の無視)、v23.5.17(起動時の AI 関数システムメッセージの移行)で、いずれも 2026 年 9 月に集中している。パッチが継続的に出ている一方、マイナーバージョンが細かく刻まれるため、固定バージョンで運用するのか追従するのかを最初に決めておく必要がある。

セキュリティ修正が定期的に入るということは、逆に言えば修正対象になる箇所がそれだけ出ているということでもある。Hyperlambda がコードを入力として受け取る設計である以上、パッチ適用の遅れはそのまま露出につながる。追従コストを見積もったうえで採用を決めたい。

編集部の結論

既存の MySQL、PostgreSQL、SQL Server、MariaDB スキーマを持ち、その上に社内ツールや管理画面を素早く被せたいチームには向く。データを外部 SaaS に置けない制約がある場合も候補になる。逆に、フロントエンドのデザインを細かく作り込みたい場合や、Hyperlambda を保守できる人を社内に確保できない場合は避けたほうがよい。MCP プラグインのトークン削減率と Hyperlambda の性能倍率はいずれも README の自己計測値であり、自環境で再現するまで採用根拠にしないこと。まず docker compose で起動し、root/root でログインしたうえで、modules フォルダに置いたエンドポイントが MCP 経由で実際にツールとして見えるかを確認する。

公式情報源

1. License: MIT
2. polterguy/magic on GitHub
3. Project website
4. README
5. Releases