世界を動かす技術を、日本語で。

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

2026年2月7日原文(github.com)

概要

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があるよ。

Hacker Newsで議論の続きを見る