Monty - AI生成コードを安全に実行する軽量Pythonインタプリタ

 (github.com/pydantic)
8 ポイント 投稿者 GN⁺ 2026-02-08 | 1件のコメント | WhatsAppで共有
  • AIが生成したコードを安全に実行するために設計されたRustベースの軽量Pythonインタプリタで、コンテナサンドボックスの複雑さと遅延を排除
  • ファイルシステム・環境変数・ネットワークアクセスを完全に遮断し、開発者が指定した外部関数のみ呼び出し可能
  • 1マイクロ秒未満の起動時間とCPythonに近い実行性能を提供し、Rust・Python・JavaScriptのすべてから呼び出し可能
  • 実行状態をバイト単位でスナップショット保存・復元でき、プロセス間で中断・再開が可能
  • Pydantic AIのCode Mode機能を動かす予定で、LLMが書いたPythonコードを安全に実行する中核コンポーネントとして使用

Monty概要

  • MontyはRustで書かれた実験的なPythonインタプリタで、AIが生成したコードを安全に実行するためのツール
    • コンテナベースのサンドボックスのコスト・遅延・複雑性を避け、LLMが書いたPythonコードを直接実行可能
    • 起動時間は数マイクロ秒単位で、一般的なコンテナの数百ミリ秒よりはるかに高速
  • できること
    • Pythonコードの一部の構文の実行をサポートし、型ヒントベースの静的型チェックを含む
    • ホストアクセスを完全に遮断し、外部関数呼び出しは開発者が明示的に許可した関数のみ可能
    • Rust・Python・JavaScriptから呼び出し可能で、リソース使用量の追跡と制限機能を内蔵
    • stdout/stderrの収集、非同期コード実行、スナップショット保存・復元機能をサポート
  • 制限事項
    • 標準ライブラリはsys、typing、asyncio、dataclasses(予定)、json(予定)のみ利用可能
    • クラス定義とmatch文はまだ未対応
    • サードパーティライブラリはサポート対象外
  • 設計目的はただ一つ、エージェントが書いたコードを安全に実行すること

Pydantic AI統合

  • MontyはPydantic AIのCode Modeを駆動
    • LLMがツール呼び出しの代わりにPythonコードを書き、Montyがそれを安全に実行
    • 例ではget_weather、get_populationのような関数型ツールを定義し、LLMがそれらを呼び出すコードを作成

代替技術との比較

  • Montyは言語の完全性には制限があるが、セキュリティ・速度・単純性に優れる
    • 起動遅延0.06ms、無料、導入が簡単、スナップショット機能をサポート
  • 他技術との比較要約:
    • Docker: 完全なCPython環境、セキュリティは良好だが起動遅延は195ms
    • Pyodide: WASMベース、セキュリティが弱く起動遅延は2800ms
    • starlark-rust: 非常に制限された言語で、高速だがPythonとは異なる
    • sandboxingサービス: 強力なセキュリティを持つが、コスト・遅延・設定が複雑
    • YOLO Python(exec/subprocess): 高速だがセキュリティは皆無
  • Montyはファイルアクセス制御、リソース制限、スナップショットベースの中断・再開機能を通じて
    AIコード実行向けの安全なPython環境を提供

関連記事

1件のコメント

 
GN⁺ 2026-02-08
Hacker Newsのコメント

  • WebAssemblyでビルドしたバージョンを動かしてみた。実際に試せるWebプレイグラウンドを作ってある
    まだクラス対応はないが、LLMがクラスを使おうとするとエラーを見て、自分でクラスを使わないコードに書き直す
    ビルド手順をまとめた記事はこちらにある

    • 言っていることは正しいが、こうした低レベル抽象の小さな不便さが積み重なると、高位レベルの性能が落ちる。LLMが本来の問題解決ではなく、Pythonインタプリタの穴を回避するのにリソースを使うことになる
    • 面白いプロジェクトだが、具体的なユースケースがあまり思い浮かばない。MCP呼び出しをMonty関数に置き換えるコードモード向けなのか、それともクエリの前処理・後処理やCaMeL実装向けなのか？
      ターミナルエージェントの強みはネットワーク・ファイルシステムへのアクセスなのだから、そうであればサンドボックスコンテナの方が自然な拡張に感じる
    • 正直なところ、なぜ必要なのかわからない。自分のモデルはすでに複数言語でうまくコードを書けるのに、わざわざ制限付きPythonだけを使う理由があるだろうか？
      Typescript、C#、Pythonはどれも問題なく使えている
    • 「クラスを使わないコードに書き直す」というのは、結局のところ学習データにそういうコードが十分ある場合にしかできない。幸いStack Overflowのコードは多いので大丈夫かもしれない

  • 昔、Gitに移る前にMercurialを使っていた頃を思い出した。当時はGitが流行っていて皆が使っている感じだったが、MercurialのUXの方がずっと良いと思っていた
    今は皆Pythonでagent execを書いているが、自分はTypeScript/JSの方が適していると感じる。速くて安全で、型のおかげで情報密度も高い。だが今回も自分が負けそうだ

    • PythonがJSより良いと思う理由は3つある
      1. 豊富な標準ライブラリ（CSV、sqlite3、jsonなど）
      2. LLMが書いたコードの大半がそのまま動く。JSはNode/Denoの分断、import構文の混乱、top-level awaitのような不安定要素が多い
      3. データ処理エコシステムがはるかに強力（csv/pandasなど）
    • 10年以上PythonとJSを使ってきたが、毎回奇妙な例外処理やnull/undefinedチェック問題に悩まされてきた。だから自分なら毎日Pythonを選ぶと思う
    • 歴史的にPythonは科学・AIエコシステムが強い。numpy、scipy、PyTorchのようなライブラリのおかげだ
      個人的にはTypeScriptの静的型システムの方が好みだが、速度やセキュリティ面では両言語とも似たような水準だ
    • エージェントがコードを実行できればデータを直接処理できるので、コンテキストを減らせる。
      Pythonはこうしたデータ処理エコシステムが整っており、Pyodideやtyのようなツールでセキュリティ問題も緩和できる
    • AIのおかげでCPythonもついにJIT内蔵の圧力を受けている。GPU側もPython DSLベースのJITが多く、実性能差は大きくない。
      いまやNVIDIAもPythonでカーネルを書くことを公式にサポートしている

  • このプロジェクトはサンドボックス化の問題に対する興味深いアプローチだ。以前、jsrunという実験でPythonの中にV8を入れてJSを安全に実行したことがある
    Montyも似た目標を持っているようだ。最小限のインタプリタから始めるのはAIワークロードに適しているが、Pythonの長い尻尾の文法を扱うのは簡単ではない
    安全性と予測可能性のために表面積を減らしつつ、LLMが生成する複雑なコードまで処理できるだけの機能を提供するバランスポイントが重要だ

    • 目標はコードモードや外部関数呼び出しを単純化することだ。短期的にはclass、dataclass、datetime、jsonあたりに対応すれば十分そうだ
    • しかしセキュリティが重要な環境では、結局VMベースの分離が必須だと思う。Montyのようなアプローチには現実的な制約が多い（E2B勤務者の意見）

  • 少し違う話だが、Monty Robertsの『The Man Who Listens to Horses』という本を思い出した。
    動物の言語を学ぶ内容で、書籍リンクと動画がある

  • 「LLMが書いたPythonコードを超高速かつ安全に実行する」という説明は興味深かった。
    ただ、uvのようなRustベースのランタイムでも最低10ms程度はかかるので、マイクロ秒単位は難しそうに見える
    それでも標準ライブラリなしのミニインタプリタというアイデアは良い。AIサンドボックス化の観点でも新鮮で、Pydanticからこういうものが出てくるとは思わなかった

    • PydanticとFastAPIは最近もっとも面白いPythonチームだ。いつも新しいプロジェクトを出してくる
    • ちなみにuvはRustで書かれたランタイムだ

  • 自分は既存言語を再利用するより、AI専用の厳格な言語を作る方が良いと思う
    AIは仕様をよく理解するので、人間のような緩い文法は必要ない。
    むしろ正確な構造と一貫したフォーマットを強制する言語の方が向いている。
    自分もそういう言語を試しているが、AIのコード生成には人間以上の規律を求められると考えている

    • だが問題は学習量だ。モデルに新しい言語を覚えさせるには膨大なデータが必要になる。
      すでにPythonをよく知っているモデルに「この関数だけ使え」と制限する方がはるかに現実的だ

  • jstanleyが言った**「小さな不便さ(papercut)」の論点はその通りだが、逆にAI生成コードを大規模に実行する場合はセキュリティリスク**の方が大きい
    ファイルI/O、ネットワーク、subprocessのような機能を完全なCPythonに開放するのは危険だ
    ただしクラス制限は奇妙だ。セキュリティとは無関係で、単にコードが汚くなるだけだ。
    おそらく「最小機能から始めて段階的に拡張する」アプローチなのだろう

    • そう、クラス制限はセキュリティ目的ではなく、単にまだ実装されていないだけだ

  • CPythonの全機能を真似するよりも、AIコードに必要な最小限のインタプリタを作るアプローチは興味深い
    完全なランタイムは攻撃面が広すぎるが、制限されたサブセットなら安全だ
    エラーフィードバックを通じてLLMが自分で制限文法に適応するよう促す戦略も現実的だ。
    ほとんどのツール利用シナリオでは、メタクラスや動的importは必要ない

  • 素朴な疑問だが、seccompでシステムコールを制限すればよいのでは？
    ファイルアクセスを防ぎたいなら関連するsyscallを遮断すれば済むはずで、わざわざ別のインタプリタが必要な理由が気になる

    • bvisorのようなプロジェクトがその方向に進んでいる
    • 正しい方向性ではあるが、基本ランタイムが強力すぎると回避可能性が多い。
      最初から極度に単純なランタイムで始めれば、攻撃面が小さくなりはるかに安全だ

  • プロジェクト自体は筋が通っているが、「AI向け超高速ツール」という言い方には笑ってしまう
    AIの思考速度があまりに遅いので、コード実行がいくら速くても全体の体感速度には大きな差がない
    まるで隣で氷河が動く速度で働く同僚と一緒に配達しているようなものだ