「AIエージェントキャッチアップ #71 - OpenShell」を開催しました

ジェネラティブエージェンツの大嶋です。

「AIエージェントキャッチアップ #71 - OpenShell」という勉強会を開催しました。

https://generative-agents.connpass.com/event/388576/generative-agents.connpass.com

アーカイブ動画はこちらです。

www.youtube.com

OpenShell

今回は、AIエージェントのためのランタイム「OpenShell」をキャッチアップしました。

OpenShellのGitHubリポジトリはこちらです。

github.com

公式ドキュメントはこちらです。

docs.nvidia.com

今回のポイント

OpenShellとは

OpenShellは、NVIDIAが公開した、AIエージェントのための安全でプライベートなランタイムです。 AIエージェントのためのサンドボックス環境を提供し、ポリシーによってファイル操作やネットワークアクセスを制御します。

現在はアルファ版であり、開発者1名、環境1つ、ゲートウェイ1つでの検証段階です。 Claude Code、OpenCode、Codex、GitHub Copilot CLI、OpenClaw、Ollamaのエージェントがサポートされています。

OpenShellの基本概念

OpenShellの基本概念は以下の通りです。

サンドボックス：AIエージェントが実行される安全でプライベートな実行環境
ゲートウェイ：サンドボックスの作成、CLIリクエストの仲介、ポリシーの適用、プロバイダー認証情報の管理を行うサーバー
プロバイダー：AIモデルプロバイダーのAPIキー、GitHubやGitLabのトークンなどを管理するエンティティ
ポリシー：ファイル操作やネットワークアクセスを制御するルール

実際に動かしてみた

実際にOpenShellを動かしてみました。

Claude Codeの起動

OpenShellをインストールしてopensh sandbox create -- claudeコマンドを実行すると、OpenShellが起動して、しばらくするとClaude Code用のサンドボックスが起動しました。

デフォルトでは、現在のディレクトリにはファイルは存在しないようでした。

--uploadオプションを使うと、ローカルのファイルをサンドボックスにアップロードできるようです。

ネットワークポリシーを試す

続いて、OpenShellのチュートリアルの通り、ネットワークポリシーを試しました。

docs.nvidia.com

openshell sandbox create --name demo --keep --no-auto-providersでデモ用のサンドボックスを作成しました。

GitHub API (https://api.github.com/zen) への通信テストを試すと、デフォルトではポリシーが設定されていないため、403の応答となりました。

GitHub APIへの通信を許可するポリシーをgithub-readonly.yamlとして用意しました。

version: 1

filesystem_policy:
  include_workdir: true
  read_only: [/usr, /lib, /proc, /dev/urandom, /app, /etc, /var/log]
  read_write: [/sandbox, /tmp, /dev/null]
landlock:
  compatibility: best_effort
process:
  run_as_user: sandbox
  run_as_group: sandbox

network_policies:
  github_api:
    name: github-api-readonly
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - { path: /usr/bin/curl }

引用元：https://docs.nvidia.com/openshell/latest/tutorials/first-network-policy.html#apply-a-read-only-github-api-policy

ポリシーを適用します。

openshell policy set demo --policy github-readonly.yaml --wait

すると、GitHub APIにアクセスできるようになりました。

OpenShellのアーキテクチャの概要

OpenShellは、K3sというIoTやエッジコンピューティング向けの軽量Kubernetesディストリビューションをベースとしたアーキテクチャになっています。

OpenShellでサンドボックス作成のコマンドを実行すると、自動的にK3sが起動し、その中でサンドボックス環境が管理されます。ユーザーはOpenShellのCLI（openshell）を使えばKubernetesのCLI（kubectl）を直接使ったり意識する必要はありません。

画像引用元：https://docs.nvidia.com/openshell/latest/about/architecture.html

OpenShellのKubernetesリソースを確認してみた

OpenShellの動作を理解するため、Kubernetesのリソースを見てみました。

OpenShellのKubernetesリソースの概要

docker psコマンドを実行すると、ghcr.io/nvidia/openshell/cluster:0.0.16というイメージのコンテナが起動していることが分かります。

docker execコマンドで接続してkubectl get all --all-namespacesで、Kubernetesリソースの概要を把握します。

agent-sandbox-systemとopenshellというStatefulSetがあることが分かります。

サンドボックスのカスタムリソース

Kubernetesにはカスタムリソース定義（CRD）という機能があり、OpenShellでもカスタムリソースが活用されています。

kubectl get crdでカスタムリソースの定義を確認すると、sandboxes.agents.x-k8s.ioが定義されていることが確認できました。

kubectl get sandboxes.agents.x-k8s.io --all-namespacesとすると、作成したサンドボックスのリソースが確認できます。

OpenShellのサンドボックス作成の動作

DeepWikiによれば、OpenShellでサンドボックスを作成する際は、以下のように動作するようです。

OpenShellのCLIがゲートウェイ（openshellというStatefulSetのPod）に通信して、サンドボックスのカスタムリソースを作成
Agent Sandbox Controllerがサンドボックスのカスタムリソースを監視して、実際にサンドボックスのPodを起動

改めて、OpenShellとは

ここまでの内容を踏まえて、改めて整理します。

コーディングエージェントのように、ファイル操作やコマンド実行、ネットワークアクセスが可能なAIエージェントを運用する場合、サンドボックス環境をどう用意するかが課題になります。 OpenShellは、そのようなサンドボックス環境をK3sベースで提供するOSSです。

Kubernetesなどでサンドボックスのランタイムを提供する場合、カスタムリソースを使うのは自然な設計の1つだと思います。 OpenShellはまさにそのように実装されています。

OpenShellは現在、シングルノードのみがサポートされています。マルチノードでの利用はサポートされていないため、SaaSのバックエンドなどで使用するのは難しそうです。一方で、DGX Sparkのような物理マシンを用意して、1台のマシンの中で複数のサンドボックス環境を運用するような構成では役立つかもしれません。