Open Computer Use

Open Computer Use

あらゆる LLM に専用のコンピューターを提供する MCP サーバーです。ライブブラウザー、ターミナル、コード実行、ドキュメント用スキル、自律型サブエージェントを備えた Docker ワークスペースを管理します。セルフホスト可能なオープンソースで、あらゆるモデルにプラグインできます。

アーカイブ済みです。 このリポジトリの開発と保守は終了しています。修正、セキュリティ更新、依存関係の更新は行われず、イシューとプルリクエストも受け付けません。本番環境では実行しないでください。

Open Computer Use は、LLM に実際のコンピューターを提供するための概念実証でした。後継は Wide Moat です。これは、Open Terminal、ブラウザー、gVisor で分離された Kubernetes サンドボックスを備えた Open WebUI で、イングレスサイドカーと MITM プロキシ経由のエグレスを備えています。既知の制限に記載されている分離と認証情報の取り扱いに関する問題は、このコードベースではなく、そのアーキテクチャで対処されています。ai.lab.widemoat.ai でお試しください。

このコードは FSL-1.1-Apache-2.0 のもとで引き続き利用できます。使用、フォーク、セルフホストが可能です。各リリースは公開から 2 年後に Apache-2.0 に移行します。

これは何ですか？

あらゆる LLM に、分離された Docker コンテナーを備えたフル装備の Ubuntu サンドボックスを提供する MCP サーバーです。AI のコンピューターと考えてください。開発者ができることなら、何でも実行できます。

• コードを実行 — 分離されたコンテナーで bash、Python、Node.js、Java を実行します
• ドキュメントを作成 — スキルを使って、プロフェッショナルなスタイルの Word、Excel、PowerPoint、PDF を作成します
• ウェブを閲覧 — Playwright とライブ CDP ブラウザーストリーミング（AI が見ているものをリアルタイムで確認できます）
• Claude Code を実行 — インタラクティブなターミナルを備え、MCP サーバーが自動設定される自律型サブエージェントです
• 13 以上のスキルを使用 — ドキュメント作成、ウェブテスト、デザインなどの実績あるワークフローを利用できます

本番環境でのマルチユーザー展開向けに構築されています。 MAU 1,000 人以上でテスト済みです。各チャットセッションは独自の分離された Docker コンテナーで実行されるため、AI はパッケージのインストール、ファイルの作成、サーバーの実行ができ、ユーザー間でデータが漏れることはありません。MCP クライアント間でシームレスに動作します。今日 Open WebUI で始めて、明日は Claude Desktop や n8n に切り替えられます。バックエンドは同じままで、移行は不要です。

主な差別化要素

機能	Open Computer Use	Claude.ai（Claude Code web）	open-terminal	OpenAI Operator
セルフホスト可能	はい	いいえ	はい	いいえ
任意の LLM	はい（OpenAI 互換）	Claude のみ	任意（Open WebUI 経由）	GPT のみ
コード実行	完全な Linux サンドボックス	サンドボックス（Claude Code web）	サンドボックス／ベアメタル	いいえ
ライブブラウザー	CDP ストリーミング（共有、インタラクティブ）	スクリーンショットベース	いいえ	スクリーンショットベース
ターミナル + Claude Code	ttyd + tmux + Claude Code CLI	Claude Code web（組み込み）	PTY + WebSocket	該当なし
スキルシステム	組み込み 13 種（自動挿入）+ カスタム	組み込みスキル + カスタム指示	Open WebUI ネイティブ（テキストのみ）	該当なし
コンテナー分離	Docker（runc）、チャットごと	Docker（gVisor）	共有コンテナー（OS レベルのユーザー）	該当なし

MCP 互換クライアントならどれでも利用できます：Open WebUI、Claude Desktop、LiteLLM、n8n、または独自の連携機能。代替製品との詳しい比較については、docs/COMPARISON.md をご覧ください。

ライブブラウザーのストリーミング

スキルを使ったファイルプレビュー

フロントエンドデザイン — ブラウザータブにライブ表示されたランディングページ

プレゼンテーション — 既定の白いテンプレートではなく、カスタムデザインシステムを使用

独自のスキルを作成 — 繰り返しの作業を再利用可能な関数にまとめる

データ → 分析付きグラフ

Claude Code — クラウド上のインタラクティブなターミナル

サブエージェントダッシュボード — 監視と制御

アーキテクチャの詳細は docs/FEATURES.md、すべてのスクリーンショットは docs/SCREENSHOTS.md をご覧ください。

ヒント：ターミナルで Claude Code を使ってスキルを作成し、チャットでは任意のモデルで使えます。スキルはモデルに依存しないため、一度作成すればどこでも使えます。

複数 CLI 対応のサブエージェントランタイム（v0.9.2.1+）：サブエージェントのディスパッチは Claude Code（既定）、OpenAI Codex、OpenCode（OpenRouter / qwen / DeepSeek / 75 以上のプロバイダーに対応）をサポートしています。.env で SUBAGENT_CLI=claude|codex|opencode を切り替えてください。OpenCode + qwen3-coder + OpenRouter の手順については docs/multi-cli.md をご覧ください。

アーキテクチャ

docs/future-architecture/ には、このリポジトリでは構築されていない Kubernetes アーキテクチャの設計メモがあります。このコードがサポートする方法は Docker Compose のみです。

試す方法

方法	URL	必要なもの	おすすめの用途
無料オンラインデモ — Open WebUI + Computer Use、モデル込み	ai.lab.widemoat.ai	GitHub または Google でのサインイン	30 秒で一通り試す
セルフホスト	以下の クイックスタート	Docker、初回ビルドに約 15 分	完全な制御、エアギャップ環境、高頻度の利用

OAuth のみです。メールアドレス／パスワードや SMS は使用できません。ai.lab.widemoat.ai では、利便性のためにモデルが無料で同梱されています。ホスト型 MCP エンドポイントはオフラインです。詳しくは docs/CLOUD.md をご覧ください。

クイックスタート

git clone https://github.com/Wide-Moat/open-computer-use.git
cd open-computer-use
cp .env.example .env
# Edit .env — set OPENAI_API_KEY (or any OpenAI-compatible provider)

# 1. Start Computer Use Server (builds workspace image on first run, ~15 min)
docker compose up --build

# 2. Start Open WebUI (in another terminal)
docker compose -f docker-compose.webui.yml up --build

http://localhost:3000 を開くと、Computer Use がすぐに使える状態の Open WebUI が表示されます。

注： Docker Compose ファイルは2つあります。docker-compose.yml（Computer Use Server）と docker-compose.webui.yml（Open WebUI）です。これらは localhost:8081 経由で通信します。これは、サーバーと UI が別々のホストで稼働する実際のデプロイを想定した構成です。

モデル設定（重要！）

Open WebUI でモデルを追加したら、モデル設定に移動して次の項目を設定してください。

設定	値	理由
関数呼び出し	Native	Computer Use ツールの動作に必要です
チャット応答のストリーミング	On	リアルタイムの出力ストリーミングを有効にします

Function Calling: Native に設定しないと、モデルは Computer Use ツールを呼び出しません。

サンドボックスの内容

カテゴリ	ツール
言語	Python 3.12、Node.js 22、Java 21、Bun
ドキュメント	LibreOffice、Pandoc、python-docx、python-pptx、openpyxl
PDF	pypdf、pdf-lib、reportlab、tabula-py、ghostscript
画像	Pillow、OpenCV、ImageMagick、sharp、librsvg
ウェブ	Playwright（Chromium）、Mermaid CLI
AI	Claude Code CLI、Playwright MCP
OCR	Tesseract（言語を設定可能）
メディア	FFmpeg
図表	Graphviz、Mermaid
開発	TypeScript、tsx、git

スキル

組み込みの公開スキル13個とサンプル14個：

スキル	説明
pptx	html2pptx を使って PowerPoint プレゼンテーションを作成・編集します
docx	変更履歴を含む Word 文書を作成・編集します
xlsx	数式を含む Excel スプレッドシートを作成・編集します
pdf	PDF の作成、フォームへの入力、抽出、結合を行います
sub-agent	複雑なタスクを Claude Code に委任します
playwright-cli	ブラウザーの自動化とウェブスクレイピングを行います
describe-image	Vision API による画像分析を行います
frontend-design	本番環境品質の UI を構築します
webapp-testing	Playwright でウェブアプリケーションをテストします
doc-coauthoring	構造化されたドキュメント共同作成ワークフローを実行します
test-driven-development	TDD の手法を徹底します
skill-creator	カスタムスキルを作成します
gitlab-explorer	GitLab リポジトリを探索します

サンプルスキル14個：web-artifacts-builder、copy-editing、social-content、canvas-design、algorithmic-art、theme-factory、mcp-builder など。

詳しくは docs/SKILLS.md をご覧ください。

MCP 統合

このサーバーは Streamable HTTP 経由で標準の MCP を使用します。任意の MCP クライアントから、お使いのデプロイ環境に接続できます。

• セルフホスト：http://localhost:8081/mcp。簡単な動作確認：

  curl -X POST http://localhost:8081/mcp \
    -H "Content-Type: application/json" \
    -H "X-Chat-Id: test" \
    -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'
  

  セルフホスト環境への統合ガイド（LiteLLM、Claude Desktop、カスタムクライアント）については、docs/MCP.md をご覧ください。チャットごとのシステムプロンプトは、MCP ネイティブの6つの冗長な経路（ツールの説明、サンドボックス内の /home/assistant/README.md、InitializeResult.instructions、アップロード済みファイル用の resources/list、およびレガシー統合用の HTTP /system-prompt エンドポイント）を通じて伝達されます。全体図は docs/system-prompt.md をご覧ください。

設定

すべての設定は .env で行います。

変数	デフォルト	説明
OPENAI_API_KEY	—	LLM API キー（OpenAI 互換のもの）
OPENAI_API_BASE_URL	—	カスタム API ベース URL（OpenRouter など）
MCP_API_KEY	—	MCP エンドポイント用のベアラートークン
DOCKER_IMAGE	open-computer-use:latest	サンドボックスコンテナのイメージ
COMMAND_TIMEOUT	120	Bash ツールのタイムアウト（秒）
SUB_AGENT_TIMEOUT	3600	サブエージェントのタイムアウト（秒）
SINGLE_USER_MODE	—	true = 1 つのコンテナを使用し、チャット ID は不要です。false = X-Chat-Id が必須です。未設定 = 厳密にチェックしません
PUBLIC_BASE_URL	http://computer-use-server:8081	ブラウザーからアクセス可能な Computer Use サーバーの URL です。/system-prompt に組み込まれ、X-Public-Base-URL レスポンスヘッダーで Open WebUI フィルターに返されます。公開 URL の唯一の信頼できる情報源です。Open WebUI フィルターの URL 要件。
CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS, ORCHESTRATOR_URL, TOOL_RESULT_MAX_CHARS, TOOL_RESULT_PREVIEW_CHARS	—	open-webui コンテナ（CU サーバーではありません）の設定です。埋め込む際に必要です。Open WebUI を独自のスタックに埋め込む際に必要な設定を参照してください。
POSTGRES_PASSWORD	openwebui	PostgreSQL のパスワード
VISION_API_KEY	—	Vision API キー（画像の説明用）
ANTHROPIC_AUTH_TOKEN	—	Anthropic キー（Claude Code サブエージェント用）
MCP_TOKENS_URL	—	Settings Wrapper の URL（任意。下記参照）
MCP_TOKENS_API_KEY	—	Settings Wrapper の認証キー

カスタムスキルとトークン管理（任意）

デフォルトでは、組み込みの 13 個のスキルをすべてのユーザーが利用できます。ユーザーごとのスキルアクセスとカスタムスキルを設定するには、Settings Wrapper をデプロイしてください。settings-wrapper/README.mdを参照してください。

パーソナルアクセストークン（PAT）： Settings Wrapper では、外部サービス（GitLab、Confluence、Jira など）用の暗号化されたユーザー別 PAT も保存できます。サーバーはユーザーのメールアドレスを使ってトークンを取得し、サンドボックスに注入します。これにより、認証情報を共有せずに、各ユーザーの AI がそれぞれのリポジトリやドキュメントにアクセスできます。トークン注入用のサーバー側コード（docker_manager.py）は実装済みですが、Open WebUI ツールは必要なヘッダーを渡さず、今後も追加されません。

MCP クライアント連携

Computer Use Server は標準の MCP over Streamable HTTP に対応しており、MCP 互換クライアントならどれでも接続できます。Open WebUI は主にテストされているフロントエンドですが、唯一の選択肢ではありません。

クライアント	セルフホスト用 URL	状態
Open WebUI	Docker Compose スタックに含まれており、自動設定されます	本番環境でテスト済み
Claude Desktop	http://localhost:8081/mcp — docs/MCP.mdを参照してください	動作します
n8n	MCP Tool ノード → http://computer-use-server:8081/mcp	動作します
LiteLLM	MCP プロキシ設定 — docs/MCP.mdを参照してください	動作します
カスタムクライアント	MCP JSON-RPC に対応した任意の HTTP クライアント。docs/MCP.mdの curl の例を参照してください	動作します

Open WebUI との統合

Open WebUI は、拡張可能なセルフホスト型 AI インターフェースです。ツール呼び出し、関数フィルター、アーティファクトに対応しており、Computer Use に必要なものがすべてそろっているため、主要なフロントエンドとして使用しています。

互換性： このビルドは、Open WebUI 0.11.0 を対象として厳密にビルドおよび検証されています。ビルドバージョンの最初の 3 つのセグメント（v0.11.0.X）は、常に対象となる Open WebUI のベースバージョンと一致します。異なるバージョンの Open WebUI を使用している場合は、最初の 3 つのバージョンセグメントが使用中のものと一致する Open Computer Use ビルドを選んでください。たとえば、Open WebUI 0.8.12 の場合は、v0.8.12.Y ビルドを使用します。

フォークではない理由は？ Computer Use 自体はフォークではありません。公式のプラグイン API（ツールと関数）を通じて機能を追加するため、標準の Open WebUI でも、ツールとフィルターをインストールするだけで動作します。（プラグインでは実現できない変更のために別のフォークも存在しますが、このリポジトリはそれに依存していません。）

企業ゲートウェイ（LiteLLM、Azure、Bedrock）を通じて Claude Code を実行していますか？3 つの経路を紹介する運用手順については、docs/claude-code-gateway.md を参照してください。

openwebui/ ディレクトリには、次のものが含まれています。

• tools/ — MCP クライアントツール（Computer Use Server への軽量なプロキシ）。必須 — Open WebUI とサンドボックスをつなぐブリッジです。
• functions/ — システムプロンプトの挿入、ファイルリンクの書き換え、アーカイブボタン。必須 — これがないと、モデルはスキルやファイル URL を認識できません。
• patches/ — アーティファクト、エラー処理、ファイルプレビューに関するビルド時の修正。任意ですが推奨 — UX が大幅に向上します。
• init.sh — 初回起動時にツールとフィルターを自動インストールします。任意 — 代わりに Workspace UI から手動でインストールできます。
• init.sh — 初回起動時にツールとフィルターをインストールし、バルブを設定します。

自動初期化の仕組み

初回の docker compose up 時に、初期化スクリプトが次の処理を自動的に実行します。

1. 管理者ユーザー（[email protected] / admin）を作成します
2. POST /api/v1/tools/create を通じて Computer Use ツールをインストールします
3. POST /api/v1/functions/create を通じて Computer Use フィルターをインストールします
4. ツールとフィルターのバルブ（ORCHESTRATOR_URL=http://computer-use-server:8081 — サーバー間通信に使う内部 URL。両方のバルブに設定されます）を設定します
5. ツールをパブリック読み取り可能にします（group:* と user:* のワイルドカードの両方にアクセス権を付与）。これにより、管理者以外のユーザーにもワークスペースでツールが表示されます
6. フィルターを有効かつグローバルにします（/toggle と /toggle/global という個別の 2 つの切り替え）。有効でもグローバルでないフィルターは何もせず、手動セットアップでよくあるミスです
7. POST /api/v1/configs/models を通じて、{function_calling: "native", stream_response: true} を DEFAULT_MODEL_PARAMS にマージします。モデルごとに Advanced Params をクリックしなくても、すべてのモデルに適切なデフォルトが設定されます

マーカーファイル（.computer-use-initialized）によって、以降の起動時に処理が再実行されないようにします。

注： Open WebUI は、ファイルシステムからのツールの事前インストールに対応していません。ツールは REST API を通じて読み込む必要があります。初期化スクリプトがこの処理を自動化するため、手動で行う必要はありません。

手動セットアップ（docker-compose を使用しない場合）

Open WebUI を個別に実行する場合は、次の手順を手動で行います。

1. Workspace > Tools に移動 → 新しいツールを作成 → openwebui/tools/computer_use_tools.py の内容を貼り付けます
2. Tool ID を ai_computer_use に設定します（フィルターの動作に必須です）
3. Valves を設定します。ORCHESTRATOR_URL = Computer Use Server の内部 URL（Docker compose の場合は http://computer-use-server:8081）
4. ツールの ⋯ → Share メニューを開き、アクセスを Public に設定します（group:* と user:* の両方のワイルドカードに読み取り権限を付与します）。設定しない場合、ツールが表示されるのは管理者アカウントだけで、管理者以外のユーザーにはエラーなしで空のツール一覧が表示されます
5. Workspace > Functions に移動 → 新しい関数を作成 → openwebui/functions/computer_link_filter.py を貼り付けます
6. フィルターを有効にします。Functions の一覧で Active と Global の両方を切り替えます。これらは別々のスイッチです。Active でも Global でなければ、フィルターは読み込まれますが、チャットには適用されません
7. モデルの設定で、Function Calling = Native、Stream Chat Response = On に設定します。または、Admin → Settings → Models → Advanced Params で一度だけグローバルに設定します（function_calling: native、stream_response: true）。これらはすべてのモデルの DEFAULT_MODEL_PARAMS になります。

docker-compose スタックでは、これらすべてが自動的に処理されます。

Open WebUI を独自のスタックに組み込む場合に必要なセットアップ

標準の docker-compose.webui.yml 以外で Open WebUI を実行する場合（独自の compose、Kubernetes、Portainer、または派生リポジトリなど）、Computer Use を気付かないうちに動作しなくする4 つの落とし穴があります。本番環境で4つすべてに遭遇しました。次の順番で確認してください。

Step 1 — このリポジトリに必要なのは標準のアップストリームイメージだけです

ツールとフィルターをインストールすれば、公開されている ghcr.io/open-webui/open-webui に対して Computer Use が動作します。このリポジトリで再ビルドする必要はありません。

以前はその逆でした。このリポジトリには8つのパッチスクリプトと、ビルド済みイメージにパッチを適用する Dockerfile が含まれていました。アップストリームをプルすると、それらのパッチはすべて気付かないうちに適用されずに済まされていました。これらのパッチは削除されています。対処していた問題のうち3つはその後アップストリームで修正され、残りはフォークのソースコミットとして残っています。これは、この統合の実行とは別の問題です。

プレビュー URL の検出にも、ビルド時のホスト設定は必要ありません。iframe のオリジンは、モデルが記述した URL から読み取られ、その URL はサーバーの PUBLIC_BASE_URL に由来します。

ステップ 3 — 2 つの URL 設定、2 つの役割（パブリックと内部）

v4.0.0： 古い「3 か所の FILE_SERVER_URL を一致させる必要がある」という落とし穴はなくなりました。現在は、役割が異なる 2 か所のみです。パブリック（ブラウザーからアクセス可能）と内部（Docker 内部）です。COMPUTER_USE_SERVER_URL のビルド引数は v0.9.2.0 で削除されました。fix_preview_url_detection はホストに依存しなくなりました（ステップ 2 を参照）。

場所	役割	読み取り元	本番環境（ドメインあり）	ローカル開発環境（Docker Desktop）
computer-use-server コンテナ上の PUBLIC_BASE_URL 環境変数（docker-compose.yml / .env）	パブリック — /system-prompt のリンクに埋め込まれ、X-Public-Base-URL レスポンスヘッダーを通じてフィルターに返されます	サーバー（パブリック URL の唯一の信頼できる情報源）	https://cu.your-domain.com	http://localhost:8081
フィルターとツールの Valves に設定する ORCHESTRATOR_URL（open-webui コンテナ上の ORCHESTRATOR_URL 環境変数から init.sh が設定）	内部 — /system-prompt のサーバー間フェッチ、MCP の tools/call 転送	フィルターとツール（Docker ネットワーク）	http://computer-use-server:8081	http://computer-use-server:8081

⚠️ ORCHESTRATOR_URL をパブリックドメインに向けないでください。 技術的には動作しますが、すべての MCP リクエストがブラウザー→CDN→Traefik→コンテナを経由することになります。この経路で問題が起きると、ツール呼び出しの途中でストリームが切断され、ユーザーには MCP call failed: Session terminated と表示されます。Docker ネットワーク内にとどめてください。

フィルターにはパブリック URL 用の Valve はなくなりました。サーバーの X-Public-Base-URL レスポンスヘッダーからパブリック URL を読み取り、プロンプトとともにキャッシュします。パブリック用の設定項目が 1 つ、内部用の設定項目が 1 つです。

docs/openwebui-filter.md も参照してください。

ステップ 4 — open-webui コンテナの 4 つの環境変数

下流の compose の environment: ブロックにコピーして貼り付けてください。

services:
  open-webui:
    environment:
      # --- Computer Use required env vars (read by build-time patches) ---
      - CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS=200
      - TOOL_RESULT_MAX_CHARS=50000
      - TOOL_RESULT_PREVIEW_CHARS=2000
      # Internal URL of the Computer Use server — seeded by init.sh into both
      # Tool and Filter Valves, and read by the fix_large_tool_results patch.
      # Same Docker network: use the service DNS name.
      - ORCHESTRATOR_URL=http://computer-use-server:8081

変数	未設定時のデフォルト値	正しく設定した場合の効果
CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS	256（上流）	1 ターンあたりのツール呼び出し上限です。標準のリポジトリでは 200 に設定され、-1 で上限が無効になります。Open WebUI は、フォールバックとして 0.10 より前の名前 CHAT_RESPONSE_MAX_TOOL_CALL_RETRIES を読み取ります。
TOOL_RESULT_MAX_CHARS	50000（パッチ組み込み値）	ツールの結果を切り詰めるかアップロードする文字数のしきい値です。0 で無効になります。
TOOL_RESULT_PREVIEW_CHARS	2000（パッチ組み込み値）	切り詰めまたはアップロード後にモデルに表示されるプレビューのサイズです。
ORCHESTRATOR_URL	空	init.sh によってツールとフィルターの両方の Valves に設定され、fix_large_tool_results パッチによってアップロード先として読み取られます。空の場合、大きすぎる結果は通知されずに切り詰められ、モデルはデータを失います。

注：最後の 3 つは、イメージが上流の ghcr.io の場合は何も行いません。ステップ 1 の fix_large_tool_results が必要です。

ステップ 5 — フィルターはグローバルに、ツールは公開読み取り可能にする

Open WebUI では、各関数に2 つの別々のスイッチ（is_active と is_global）があり、各ツールには2 つの必須の権限付与（group:* と user:*）があります。標準の init.sh はこれらを設定しますが、手動またはカスタムのデプロイでは片方を見落としがちで、「すべてインストールしたのに何も動かない」と何時間も悩むことになります。

リソース	設定内容	UI のパス	エンドポイント	理由
フィルター computer_use_filter	is_active = true かつ is_global = true	Admin → Functions → computer_use_filter → Active を切り替え + Global を切り替え	POST /api/v1/functions/id/computer_use_filter/toggle + .../toggle/global	is_active は関数を読み込むだけです。is_global を設定すると、実際にすべてのチャットに適用されます。Active でも global でない場合、ログにも何も残らず、ひそかに機能しません。
ツール ai_computer_use	group:* および user:* に対する access_grants、permission: read	Workspace → Tools → ai_computer_use → ⋯ → Share → Public	POST /api/v1/tools/id/ai_computer_use/access/update with {"access_grants":[{"principal_type":"group","principal_id":"*","permission":"read"},{"principal_type":"user","principal_id":"*","permission":"read"}]}	権限付与がない場合、そのツールを作成した管理者アカウントにしか表示されません。管理者以外のユーザーには、エラーもなくツール一覧が空で表示されます。UI の「Public」切り替えは両方のワイルドカードを書き込みます。片方だけを書き込むと、Open WebUI のバージョンによっては、一部のユーザーにはツールが表示され、他のユーザーには表示されません。

データベースで確認します（標準スタックでは Postgres を使用します。docker-compose.webui.yml:53 を参照）：

# Filter flags — expect (t, t):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
  "SELECT is_active, is_global FROM function WHERE id='computer_use_filter';"

# Tool grants — expect TWO rows (group|* and user|*, both 'read'):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
  "SELECT principal_type, principal_id, permission FROM access_grant WHERE resource_id='ai_computer_use';"

SQLite をバックエンドに使用する Open WebUI のデプロイでは、psql を sqlite3 /app/backend/data/webui.db に置き換え、同じ SQL を実行してください。

ステップ 6 — すべてをまとめて確認する

# 1. Env vars reached the container:
docker exec open-webui env | grep -E 'CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS|TOOL_RESULT_|ORCHESTRATOR_URL'

# 4. Tool+Filter Valve (Session-terminated trap) — Admin UI is simplest:
#    Workspace → Tools → ai_computer_use → Valves → ORCHESTRATOR_URL
#    Admin → Functions → computer_link_filter → Valves → ORCHESTRATOR_URL
#    → both must be http://computer-use-server:8081 (internal URL, Docker service DNS),
#      NOT your public domain.

# 5. Server env (baked into system prompt AND returned to filter via header):
docker exec computer-use-server env | grep ^PUBLIC_BASE_URL=
# → must be a URL your browser can reach (e.g. http://localhost:8081 for local dev).

# 7. Filter is ACTIVE *and* GLOBAL (see Step 5):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
  "SELECT is_active, is_global FROM function WHERE id='computer_use_filter';"
# → expect (t, t). Two 't's, not one.

# 8. Tool is public-read with both wildcards (see Step 5):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
  "SELECT principal_type, principal_id, permission FROM access_grant WHERE resource_id='ai_computer_use';"
# → expect TWO rows: (group, *, read) and (user, *, read).

イメージを再ビルドした後、ブラウザーでハードリロード（Cmd+Shift+R / Ctrl+Shift+R）を実行してください。そうしないと、古い JS チャンクがキャッシュされたままになり、修正が反映されていないと思い込んでしまいます。

症状 → 間違っているステップ

症状	ステップ
HTML アーティファクトが、チャット内で生の <iframe ...> テキストとして表示される	1（上流のイメージ、fix_artifacts_auto_show がありません）
ファイルリンクでプレビュー iframe の自動挿入が行われない	1（fix_preview_url_detection がありません）、またはブラウザーから PUBLIC_BASE_URL にアクセスできない
すべてのツール呼び出しで MCP call failed: Session terminated が発生する	3（ツールの Valve がパブリックドメインを指しています）
ツールループが早く終了する。「Model temporarily unavailable」というバナーが表示される	4（CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS が設定されていません）
大きなツール出力が通知なく ...(truncated) になり、モデルが誤った判断をする	4（ORCHESTRATOR_URL が未設定、またはアクセス不能）、または 1（fix_large_tool_results がありません）
ツールループのエラーに生の Python 例外が表示される	1（fix_tool_loop_errors がありません）
管理者以外のユーザーにはツール一覧が表示されない（管理者には表示される）	5（ツールに access_grants がなく、公開読み取り可能になっていません）
UI ではフィルターが「Active」に見えるのに、プレビュー iframe やアーカイブボタンが表示されない	5（フィルターの is_global=false です。is_active=true だけが切り替えられています）
チャット内のファイルリンクを開くと 404 / 白い画面になる	サーバーの PUBLIC_BASE_URL がブラウザーからアクセスできる URL と一致していません。docs/openwebui-filter.md を参照してください
再ビルドしても新しい動作が反映されない	ブラウザーに古い JS がキャッシュされています。ハードリロードしてください

セキュリティに関する注意

本番環境でテスト済み。セルフホスト環境の Open WebUI で 1000 人以上のユーザーを対象にテストされています。現在はメンテナンスされていません。未修正の項目は以下に記載されています。

現在のモデル

• Docker socket：サンドボックスコンテナを管理するには、サーバーが Docker ソケットにアクセスする必要があります。これによりホストへの大きなアクセス権が付与されるため、信頼できる環境でのみ実行してください。
• MCP_API_KEY：本番環境では、強力なランダムキーを設定してください。設定しない場合、ポート 8081 にネットワークアクセスできる人なら誰でも、コンテナ内で任意のコマンドを実行できます。
• サンドボックスの分離：各チャットセッションは、リソース制限（RAM 2GB、CPU 1基）付きの個別コンテナで実行されます。Docker Compose では、コンテナは標準のランタイム（runc）を使用し、ホストカーネルを共有します。Kubernetes Helm chart のデフォルトは rootless Podman で、ユーザー名前空間に加えて AppArmor を使用し、特権コンテナは使いません。また、ハイパーバイザーレベルの境界を実現するため、Kata Containers を選択することもできます。Compose では、gVisor は一度も組み込まれていません。コンテナはデフォルトでネットワークにアクセスできます。
• POSTGRES_PASSWORD：本番環境では、.env のデフォルトパスワードを変更してください。

既知の制限事項

• 認証されていないファイル／プレビューエンドポイント：/files/{chat_id}/、/api/outputs/{chat_id}、/browser/{chat_id}/、/terminal/{chat_id}/ は、チャット ID を知っている人なら誰でもアクセスできます。チャット ID は UUID であり、推測は困難ですが、実際のセキュリティ境界ではありません。
• サーバーにユーザーごとの認証がない：MCP サーバーは、有効な MCP_API_KEY を送信する接続元を信頼します。ユーザー ID（X-User-Email）はクライアントから渡されますが、サーバー側では検証されません。
• HTTP ヘッダー内の認証情報：API キー（GitLab、Anthropic、MCP トークン）は、クライアントからサーバーへ HTTP ヘッダーとして渡されます。Docker ネットワーク内では安全ですが、外部に公開する場合は HTTPS を使用してください。
• デフォルトの管理者認証情報：[email protected] / admin — マルチユーザー環境では、直ちに変更してください。

未修正のセキュリティ項目

これらはこのリポジトリでは対応されません。

• ファイル／プレビュー／ターミナルエンドポイント用のセッションごとの署名付きトークン（認証にチャット ID を使う方式を置き換える）
• Open WebUI JWT の検証によるサーバー側のユーザー検証
• TLS 証明書を自動取得するHTTPS サポート
• すべてのツール呼び出しとファイルアクセスの監査ログ
• サンドボックスコンテナ向けのネットワークポリシー（デフォルトで送信トラフィックを制限）
• シークレット管理 — 認証情報をヘッダーから暗号化されたサーバー側ストレージに移動
• gVisor（runsc）ランタイム — より強力に分離するためのオプションのコンテナサンドボックス（Claude.ai と同様）

開発

# Build workspace image locally
docker build --platform linux/amd64 -t open-computer-use:latest .

# Run tests
./tests/test-docker-image.sh open-computer-use:latest
./tests/test-no-corporate.sh
./tests/test-project-structure.sh

# Build and run full stack
docker compose up --build

コントリビュート

このリポジトリはアーカイブされており、コントリビューションを受け付けていません。CONTRIBUTING.md を参照してください。

コミュニティ

• 後継：widemoat.ai、デモは ai.lab.widemoat.ai
• 連絡先：[email protected]

ライセンス

このプロジェクトでは複数のライセンスを採用しています。

• コア（computer-use-server/、openwebui/、settings-wrapper/、Docker の設定）：Functional Source License, Version 1.1, Apache 2.0 Future License（FSL-1.1-Apache-2.0）。自由に使用、変更、フォーク、再配布でき、内部でセルフホストできます。各リリースは公開から 2 年後に自動的に Apache 2.0 に切り替わります。有料版と競合するホステッドサービスまたは組み込みサービスを提供するには、商用契約が必要です。
• 当社のスキル（skills/public/describe-image、skills/public/sub-agent）：MIT
• サードパーティのスキル：個別の LICENSE.txt ファイルまたは原著のソースを参照してください。

帰属表示が必要です：「Open Computer Use」と、このリポジトリへのリンクを記載してください。

詳細は NOTICE を参照してください。サードパーティ依存関係のライセンス（PyMuPDF AGPL、Anthropic Skill License、Apache 2.0 バンドルなど）については、THIRD-PARTY-LICENSES.md を参照してください。