Python スキルの実行

ZeroClaw は Python スキルを実行できますが、現実的な Python の作業では通常、2 つの明示的なデプロイ方法のいずれかを選択する必要があります。

信頼できるホストの Python 環境でスキルを実行するか、または
Skill が必要とする Python とパッケージがすでに含まれているカスタム Docker ランタイムイメージ内で実行します。

デフォルト設定は意図的に保守的になっています。どの信頼境界を採用するかを決定するまで、多くのコピー＆ペーストされた Python パターンをブロックします。

このページでは、組み込みの shell ツールを通じて呼び出される Python スクリプトについて説明します。SKILL.toml が kind = "shell" または kind = "script" を持つ独自の [[tools]] エントリを定義している場合、そのスキルツールは現在、runtime.kind = "docker" を通してではなく、shell ポリシーの下でホストのサブプロセスとして実行されます。現時点でコンテナ化された Python 実行を行うには、スキルの指示で組み込みの shell ツールを通じて Python スクリプトを呼び出すか、スキルツールのコマンドで目的のコンテナ境界を明示的に実行させるかのいずれかにしてください。

3つのレイヤー

Pythonスキルの実行は、3つの独立したレイヤーによって制御されます。

レイヤー	設定画面	それが決定する内容
スキル監査	`[skills].allow_scripts`	シェルライクなヘルパーファイルをスキルパッケージから読み込めるかどうか。Python の `.py` ヘルパーはデフォルトで許可されます。
シェルのポリシー	`[risk_profiles.<alias>].allowed_commands`	シェルツールが `python`、`python3`、`pip`、またはその他の実行可能ファイルを呼び出せるかどうか。
実行境界	`[risk_profiles.<alias>].sandbox_*` と `[runtime]`	許可されたコマンドが実際に実行される場所と、適用されるファイルシステム、ネットワーク、リソースの制限。

Python ヘルパーファイルには allow_scripts = true は必要ありません。シェルのようなヘルパーファイルを有効にするのは、スキルのソースを確認した後にのみ行い、リスクプロファイルの allowed_commands でインタープリター（python、python3、pip）を許可してください。allowed_commands は空でない場合、厳格な実行可能ファイルの許可リストとして機能します。シェルポリシーは、その許可リストに加えて、破壊的なパターンやインタープリターの引数リスクを引き続きチェックします。

Python パッケージは、イメージのビルド時、レビュー済みのローカル仮想環境、またはエージェントのターン外の別のセットアップ手順でインストールすることを推奨します。ランタイムでのパッケージインストールがそのデプロイメントの意図的な一部である場合にのみ、pip を信頼済みプロファイルに追加してください。

ブロックされたままの項目

ZeroClaw は、以下のようなインラインインタープリターの実行を意図的にブロックします。

sh

python3 -c print("hello")
python3 -m http.server
python3 -m pip install requests
node -e console.log(process.env)

Python のスキルでは、コードを監査可能なスクリプトファイルに記述し、そのファイルを実行してください:

sh

python3 skills/portfolio/run.py

これにより、実行可能ファイルがスキル監査パスでレビュー可能になり、シェルコマンド文字列が任意のコードコンテナーになることを防ぎます。

PYTHONPATH=... python3 script.py のような環境変数のプレフィックスもポリシーの影響を受けます。安定したランタイム環境のセットアップが必要な場合は、ラッパースクリプト、プロジェクトローカルの仮想環境、またはスクリプト内での明示的な設定を優先してください。

パターンA: 信頼されたネイティブPython

スキルが信頼できる場合や、ホストのPythonインストール、パッケージ、ファイルシステム権限、ネットワークを使用させたい場合は、ネイティブ実行を使用してください。

これは、ローカル開発環境、シングルユーザーのワークステーション、またはご自身でスキルを記述したホームラボに適しています。このプロファイルでのツール実行に対するOSレベルのサンドボックス化が解除されるため、通常のユーザー権限とZeroClawのポリシーチェックが残りのガードレールとなります。

レビューされていないサードパーティ製スキルやマルチテナント環境では、このパターンを使用しないでください。

パターンB: カスタムDockerランタイムイメージ

Python の依存関係を再現可能なコンテナイメージ内に保持しつつ、組み込みのシェル実行に対するランタイム境界も維持したい場合は、Docker を使用してください。

スキルに必要なパッケージを含むイメージを作成します。

# Dockerfile.skill-exec
FROM python:3.12-slim

RUN pip install --no-cache-dir \
    pandas \
    polars \
    requests

WORKDIR /workspace

ビルドする:

sh

docker build -f Dockerfile.skill-exec -t zeroclaw-python-skills:local .

runtime.kind = "docker" を介して ZeroClaw をイメージに向けると、一時的なコンテナ内でシェル呼び出しが実行されます。Docker 固有のイメージ、ネットワーク、メモリ、CPU、読み取り専用 rootfs、ワークスペースのマウント設定は runtime.docker 配下にあります。

sandbox_backend = "none" を設定すると、Docker ランタイムを2つ目の独立したサンドボックスコンテナで包むことを回避できます。このパターンでは、Docker ランタイムが組み込みシェル呼び出しの実行境界となり、runtime.docker でイメージとコンテナの制限を設定します。

スキルがアウトバウンドHTTPを必要とする場合は、runtime.docker.networkを意図的に変更してください。スキルがマウントされたワークスペース外にパッケージキャッシュ、レポート、または一時的な状態を書き込む必要がある場合は、代わりに/workspace配下に書き込むべきかどうかを確認し、それでも不十分な場合にのみread_only_rootfsを緩和してください。

ワークスペースマウント

runtime.docker.mount_workspace = true の場合、ZeroClaw は設定されたワークスペースをコンテナ内の /workspace にマウントし、そこをコンテナの作業ディレクトリに設定します。スキルスクリプトでは、可能な限りワークスペースからの相対パスを使用してください。

ワークスペースのパスをさらに制限する必要がある場合は、ワークスペースの許可リストを設定してください。ZeroClaw は Docker ボリュームマウントを追加する前に、ホストのワークスペースパスを許可リストと照合して検証します。

マウント検証はフェイルクローズ方式です。許可リストが空の場合でも、ワークスペースは存在し、正規パスに解決できなければなりません。設定された許可リストのルートもすべて存在し、正規化できる必要があります。別のルートが一致する場合でも、古いエントリや無効なエントリが1つでもあると、Dockerの起動前にコマンドが拒否されます。アップグレードする前に、古いエントリを削除するか、意図したディレクトリを作成してください。

パターンの選択

スキルを自分で記述またはレビューしており、シングルユーザーホスト上で最も低いレイテンシを求める場合は、信頼できるネイティブの Python を使用してください。
ビルトインシェル呼び出しに対して、再現可能な依存関係、本番環境向けのパッケージング、または明示的なコンテナ境界が必要な場合は、カスタムDockerランタイムイメージを使用します。
レビューされていない、またはマルチテナントのスキルソースに対しては、より厳格なリスクプロファイル、より狭いコマンド許可リスト、コンテナ化された実行を使用してください。

ZeroClaw Docs