Monty: AI向けにRustで書かれた最小限の安全なPythonインタプリタ

概要

Monty は、Rustで実装された 最小限・高セキュリティ なPythonインタプリタ。 AIエージェント によるコード実行を安全・高速に実現。 コンテナ不要 で、数マイクロ秒の超高速起動。 ホスト環境遮断 や型チェック、スナップショット対応。 Pydantic AI などでの利用が進行中、他技術との比較も掲載。

Montyとは何か

Rust製 の最小限かつ安全なPythonインタプリタ
主な用途は LLM（大規模言語モデル）エージェント によるPythonコードの安全実行
コンテナ型サンドボックス 不要、複雑な環境構築なし
起動時間 は1マイクロ秒未満、超高速
ホスト環境 （ファイルシステム、環境変数、ネットワーク）へのアクセスは完全遮断
外部関数呼び出し のみ許可し、開発者が制御
現代的な型ヒント 対応、型チェックツール（ty）をバイナリに同梱
スナップショット 機能で状態保存・復元が可能
Rust/Python/JavaScript から呼び出し可能、CPython非依存
リソース制御 （メモリ、アロケーション、スタック深度、実行時間）対応
stdout/stderrの収集、呼び出し元への返却機能
同期/非同期コード の両対応

Montyでできないこと

標準ライブラリ は一部のみ使用可能（sys, typing, asyncio, dataclasses, json）
サードパーティライブラリ 非対応（例：Pydantic）
クラス定義不可 （今後対応予定）
match文非対応 （今後対応予定）

主な用途・モチベーション

AIエージェント が生成したコードの安全実行
従来のツール呼び出し よりも高速・安価・信頼性向上
サンドボックス不要 でホストリスク低減
例：Cloudflare Codemode、Anthropic MCP、Hugging Face Smol Agents

Pythonでの利用例

インストール
- uv add pydantic-monty または pip install pydantic-monty
基本的な使い方
- コード・型定義・外部関数を渡してMontyインスタンス生成
- 外部関数の実装を渡して実行（同期/非同期両対応）
外部関数を含む逐次実行
- start()で実行開始、外部関数呼び出し時に一時停止
- resume()で値を渡して再開
シリアライズ/デシリアライズ
- インタプリタやスナップショットをバイト列として保存・復元可能
- 複数プロセス間での状態共有やキャッシュ用途

Rustでの利用例

MontyRun でPythonコードを実行
dump()/load() でシリアライズ・復元
リソース制御 や 標準出力 のカスタマイズも容易

Pydantic AIとの連携

CodeModeToolset でMontyを活用
LLMがPythonコードを生成→Montyが安全に実行
複数ツールの組み合わせ や 結果の一元取得 が可能

主要な代替技術との比較

| 技術名 | 言語対応範囲 | セキュリティ | 起動時間 | コスト | セットアップ難度 | ファイルマウント | スナップショット | |-------------------|----------------|------------------|------------|-------|----------------|----------------|----------------| | Monty | 部分的 | 厳格 | 0.06ms | 無料 | 容易 | 容易 | 容易 | | Docker | 完全 | 良好 | 195ms | 無料 | 中程度 | 容易 | 中程度 | | Pyodide | 完全 | 低い | 2800ms | 無料 | 中程度 | 難しい | 難しい | | starlark-rust | 非常に限定的 | 良好 | 1.7ms | 無料 | 容易 | 不可？ | 不可？ | | サンドボックスサービス | 完全 | 厳格 | 1033ms | 有料 | 難しい | 中程度 | 中程度 | | YOLO Python | 完全 | ほぼ無防備 | 0.1ms | 無料 | 容易／危険 | 難しい | 難しい |

Montyの特徴まとめ

クラス未対応、標準ライブラリ制限、サードパーティ非対応
ファイル・ネットワーク・環境変数の利用は明示的制御
起動・実行が極めて高速
pipやnpmで簡単導入、4.5MBの軽量バイナリ
スナップショット機能で状態保存・再開が容易

他技術との違い

Docker ：完全なPython環境だが、起動遅延やセットアップが重い
Pyodide ：WASMベースでライブラリ豊富だが、サーバ用途やリソース制御が難しい
starlark-rust ：高速・安全だがPython互換性が低い
サンドボックスサービス ：高機能だがコストやセットアップが複雑
YOLO Python ：高速だがセキュリティ皆無

まとめ

Monty はAI時代の 安全・高速なコード実行基盤 として有力な選択肢
コンテナ不要・高速起動・明示的な権限制御 が最大の強み
Pydantic AI など主要プロジェクトでの採用が進行中
用途特化型 のため、万能なPython環境が必要な場合は他技術を検討

Hackerたちの意見

その代わりに、エージェントに埋め込まれたLLMが書いたPythonコードを安全に実行できるようにしてくれるんだ。起動時間は数マイクロ秒単位で、何百ミリ秒もかからない。インタープリターが実行可能ファイルに埋め込まれていて、プロセス内で動くなら話は別だけど、何もしないuvの呼び出しでも、私のシステムでは約10msかかる。こういうミニマルな実装のアイデアは好きだな。AIのサンドボックス的な視点からは考えてもみなかったけど、標準ライブラリなしの代替案があって、そこにもっと考えられた「コア」ライブラリを積み重ねられるのがいいなと思った。ディスクの占有も少ないし。Pydanticから出てくるとは思わなかったけど。

└

PydanticとFastAPIは今の私のお気に入りのPythonプロジェクトだね。いつも面白い新しいプロジェクトを出してくれる。

└

uvはPythonではなくRustで書かれているよ。

WebAssemblyのビルドを作って、試すためのウェブプレイグラウンドを立ち上げたよ: https://simonw.github.io/research/monty-wasm-pyodide/demo.ht... まだクラスのサポートはないけど！でも、クラスを使おうとするLLMはエラーメッセージが出て、クラスを使わないようにコードを書き直すから、あまり関係ないかな。WASMビルドを動かすためのノートはこちら: https://simonwillison.net/2026/Feb/6/pydantic-monty/

└

これめっちゃクールなんだけど、使い道がちょっと分からないな。これは主にコーディングモード用で、MCPの呼び出しがMonty関数を通るってこと？それとも、クエリに答えるための簡単な計算や前処理・後処理をするため？それかCaMeLを実装するため？ターミナルエージェントの力は、ネットワークやファイルシステムにアクセスできるからって感じがするし、サンドボックス化されたコンテナは自然な延長なのかな？

これって、私がGitに移る前にMercurialを使っていた時のことを思い出す。みんながGitを使っていて、その理由がなんか流行に乗ってるように見えたけど、Mercurialの方がUXもメンタルモデルもずっと良かった。今はみんながPythonでエージェントのexecを書いてるけど、TypeScriptやJSの方がずっと適してると思う。いつも速くて安全だし、型があるおかげで信頼性も高いし、情報密度も高いからね。でも、これも負ける気がする。

└

できるだけ少ないJSを使わせてくれない？サーバーサイドでこんな忌まわしいものを使う理由が全くわからない。今時のC#だって、単一ファイルからスクリプトのように実行できるんだから。— 最新のCodex UIアプリもElectronだし。AIの力で自分で書くはずなのに、ネイティブのSwiftUIやWinUI、LinuxのQTとかがうまくいかないんだよね。

└

エージェントにコードを実行させる大きな利点は、コンテキストを膨らませずにデータを処理できることだよ。LLMはデータ処理のためのPythonを書くのが本当に得意だと思う。Pythonにはこのニッチに対する素晴らしいエコシステムがあるからじゃないかな。型安全性やセキュリティの問題は、tyやpyodideによって軽減できるといいな（CFのPythonワーカーでも使われてるし） https://pyodide.org/en/stable/ https://github.com/astral-sh/ty

└

ついでに、最近のGILの変更がMercurialに何か改善として波及するのかなって思った。まだ個人リポジトリには古いhgを使ってるけど、外部プロジェクトとの相互運用はほとんどのhgホストが衰退したからgitにデフォルトで切り替わってる。

└

歴史的な理由（FFI）から、Pythonは素晴らしいベクトルやテンソルの数学（numpy / scipy / pandas / polars）や、OpenCVからPyTorchまでのML / AIライブラリにアクセスできるんだ。だから、科学や研究でPythonが広まっているんだよ。「みんなPythonを知ってる」って感じだね。私はTypeScript（JSじゃなくて）をもっと好きなんだけど、Pythonに比べて高度な型システムがあるからなんだ。TS/JSは本質的に速いわけじゃなくて、良いJITコンパイラがあるだけ。Pythonはまだそれなしで出荷されてるからね。セキュリティに関しては、各インタープリタは他と同じくらい許容的で、どちらも環境からかなり安全に隔離できるよ。

└

10年以上PythonとJavaScriptをやってきたけど、JavaScriptよりもPythonを選ぶね。JavaScriptは美しいけど、同時に最も恐ろしいプログラミング言語でもある。未完成な感じがするし、これまでに遭遇した奇妙なことが多すぎる。例えば、nullや空、undefinedの値をチェックするのが一貫していないから、ライブラリによって挙動がバラバラなんだよね。

└

Pythonにはuv、ruff、tyがあるよ。

└

Pythonの利点は、みんなが「遅いし悪い」ってわかってるところだね。これはグルー言語として重要な特性だと思う。だからこそ、CやFortranで書かれたライブラリを呼び出すインセンティブが高まるんだ。

└

PythonがJSよりもずっと優れている理由が3つあると思う。1つ目は、大きな標準ライブラリがあること（CSV、sqlite3、xml/json、zipfile）。2つ目は、PythonではLLMがやりそうなことはたぶんうまくいくってこと。JSではNode/Denoの分裂があって、同じことをするライブラリが多すぎる（XMLHTTPRequest/Axios/fetch）、互換性のないインポート構文も多い（例えば、tsxとNodeのネイティブts実行を比べてみて）、トップレベルのawaitみたいな機能（小さなスクリプトにはすごく重要で、LLMが使う可能性が高い！）は、満月の日に3回祈らないと動かないこともある。3つ目は、データ処理のエコシステムがはるかに優れていること（特にcsv/pandas）。これは演算子のオーバーロードがあるからでもあるね。

ちょっとバカな質問かもしれないけど、seccompを使ってPythonインタープリタがアクセスできるシステムコールの数を制限したり拒否したりできないの？例えば、ホストのファイルシステムに干渉されたくないなら、ファイルシステム関連のシステムコールを使えないようにすればいいんじゃない？完全に別のインタープリタを使うメリットって何なの？

└

君のアプローチは有効だね。でも、いつも何か回避策があるんじゃないかって考えちゃうよ。すべてのシステムのあらゆる側面にアクセスできるランタイムから始めると、攻撃者が君の設置したブロックを突破しようとする方法はたくさんあるからね。超ミニマルなものから始めるポイントは、攻撃面が小さいことなんだ。本当に何かが突破するのは難しいと思うよ。

└

https://github.com/butter-dot-dev/bvisor はその方向に進んでるね。

サンドボックス問題に対する面白い視点だね。前にやった実験を思い出すなぁ（https://github.com/imfing/jsrun）。これはV8をPythonに埋め込んで、ホスト環境へのアクセスを厳しく制御しながらJavaScriptを実行できるようにしたものなんだ。信頼できないコードをPythonで実行するのと似た目的だね。PydanticチームがMontyをどこに持っていくつもりなのか、特に興味があるよ。ミニマルインタープリタのアプローチはAIワークロードには良い出発点に思えるけど、Pythonのセマンティクスの長い尾は厳しいね。セキュリティと予測可能性のために表面積を小さく保つことと、LLMが生成する複雑なタスクを処理するための十分な言語機能を提供することの間にはトレードオフがあるんだ。

└

安全で信頼できないワークロードには、VMを避ける方法はないね。Montyのような他の選択肢は、実際のワークロードには非現実的なトレードオフが多すぎる。ちなみに、私はE2Bで働いているけど、これは私個人の意見だよ。

└

どこに行き着くかは分からないけど、主な目標はコーディングモードやプログラム的なツール呼び出しを可能にすることなんだ。もっと複雑なことには外部関数呼び出しメカニズムを使う予定だよ。近い将来、クラス、データクラス、日付時刻、JSONのサポートを追加するつもり。これで多くのユースケースには十分だと思う。

Montyは、私がRustベースのRLM実装を出すきっかけになった欠けていたリンクなんだ。きっと他の多くの場面でも役立つと思うよ。ただ、パニックには気をつけてね！

└

rlm-rs: https://crates.io/crates/rlm-rs src: https://github.com/synth-laboratories/Horizons

誰かがWASMをターゲットにしたPythonの「コンパイラ」を作るようにエージェントに指示してくれたらいいのに。今の時代にそんなものがまだないなんて、ちょっと驚きだよ…。

これめっちゃいいね！Claude Codeはアイデアが行き詰まったときに、小さなPythonスクリプトを実行してテストすることが多いんだ。こういうのがあれば、実験を一つ一つ承認しなくても済むから楽になるな。

└

最近、AnthropicがJavaScriptエンジンを買収したって聞いたけど？それは、LLMが書いたコードのために、より密接な統合と安全な実行環境を求めてるからだと思ったんだ。サンドボックスは、ブラウザのJavaScriptではすでに非常に一般的だしね。

真面目な質問なんだけど、なんで生成されたスクリプトにSELinuxを使わないの？元のランタイムやエコシステムにアクセスできるし、改ざんされることもないし、テストも十分にされてる。syscallを回避するためのフォークやトリッキーな間接呼び出しも必要ない。こういうランタイムには技術的負債が伴って、サポートもないし、特定のドキュメントも不足してるし、エコシステムや機能のサポートもない。2年後に放置されないことを願うよ。DockerやNix Linux、または隔離されたコンテナにも同じことが言えるし…セキュリティのレベルはLLMにとって十分であるべきで、人間（専門のハッカー）による攻撃にも対抗できるべきだよね。

ハクソク