Open-Inspectを組織の開発作業に置くときの境界線
プロジェクト概要：オープンソースのバックグラウンド エージェント コーディング システム。バックグラウンド エージェント: Open-Inspect Ramp の Inspect からインスピレーションを得たオープンソースのバックグラウンド エージェント コーディング システム。
ひと目でわかる
- これは何？
- ColeMurray/background-agentsは、複数の入口からサンドボックス上のコーディングエージェントを動かす、単一テナント前提のMITライセンス製品です。
- 誰に向いている？
- Open-Inspectは、同じ組織の利用者が同じリポジトリ群を扱う社内環境なら検討しやすい設計です。一方、利用者ごとにリポジトリ権限を厳密に分けるマルチテナントサービスとしては、READMEが明記する前提から外れます。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Open-Inspectが解こうとしている作業
ColeMurray/background-agentsは、バックグラウンドでコーディングエージェントを走らせるオープンソースシステムです。READMEは、Node.js、Python、git、ブラウザ自動化、VS Codeを含む開発環境をエージェントに渡し、Web UI、Slack、GitHubのプルリクエスト、Linearのイシュー、Webhookから同じ仕組みに接続できると説明しています。単なるチャット画面ではなく、作業場所、セッション、変更、プルリクエストまでを一つの流れに置く発想です。
メタデータ上の言語はTypeScript、ライセンスはMITです。2026年8月29日の素材では2,689スター、399フォーク、84件のオープンイシューが記録されています。これは利用の広がりを読む補助情報であり、性能や運用品質を証明する数値ではありません。
最初に読むべき単一テナントの宣言
このプロジェクトの採否を左右するのは、READMEが単一テナント展開専用と明記している点です。想定されるのは、同じ組織に属し、同じリポジトリへアクセスできる利用者です。GitHub Appのインストール資格情報は利用者間で共有され、セッション作成時に個人単位のリポジトリアクセス検証は行われません。したがって、Appが見られるリポジトリはシステム上の利用者からも見える前提になります。
GitHubログインでは利用者のOAuthトークンでプルリクエストを作成し、書き込み権限のある範囲に帰属を寄せます。Googleなど別の方法でログインした利用者にはSCMトークンがないため、共有GitHub Appボットに戻ります。個人帰属と共有資格情報の差は、監査記録を設計する前に整理すべき点です。
コントロールプレーンから作業用サンドボックスへ
構成は、接続を受けるコントロールプレーンと、実際の開発環境を持つデータプレーンに分かれます。前者はCloudflare Workers上で動き、セッションごとのDurable ObjectsにSQLiteデータベース、WebSocketハブ、イベントストリーム、GitHub連携を持ちます。リポジトリ単位の秘密情報はD1データベースに保存されるとREADMEにあります。
後者はセッション用サンドボックスを管理し、スーパーバイザー、OpenCodeランタイム、コントロールプレーンとのブリッジを含みます。Modal、Daytona、E2B、OpenComputerなど複数のサンドボックス基盤が挙げられているため、利用者は機能一覧だけでなく、選んだ基盤の隔離、費用、リージョン、ログの扱いを別に確認する必要があります。
起動時間を短くする三つの仕掛け
READMEが説明する起動短縮策は、ファイルシステムスナップショット、リポジトリや環境ごとのプリビルドイメージ、入力中から始めるプロアクティブウォーミングです。プロンプト後の状態を保存し、後続セッションでは再クローンの代わりに復元します。プリビルドイメージは最新コミットと依存関係を取り込み、30分ごとに再構築される設計です。
この方式は、毎回同じ初期化を待つ作業には合いますが、スナップショットに何が残るかを運用側が把握しなければなりません。特に秘密情報、生成物、未コミット変更、依存関係の差分について、復元後にどの状態を正とするかを決めておく必要があります。READMEは仕組みを示しますが、組織固有の保持期間や削除手順までは定めていません。
複数リポジトリと共同作業の単位
新しいセッションでは最大10個のリポジトリを並べて扱えます。エージェントは関連する変更を複数リポジトリにまたがって行い、リポジトリごとにプルリクエストを開く想定です。リポジトリの集合は名前付き環境として保存でき、独自の秘密情報スコープと任意のプリビルドイメージを持ちます。
マルチプレイヤーセッションでは、接続中の利用者が同じ作業を見て、プレゼンス表示やリアルタイムストリーミングを使えます。プロンプトはgitコミットの著者情報に結び付けられるため、誰の指示がどの変更につながったかを後から追いたい組織には意味があります。ただし、共同確認がレビュー承認を代替するとはREADMEに書かれていません。
モデル選択と接続口の多さ
READMEはAnthropic Claude、OpenAI、xAI Grok、OpenCode Zen、Z.AIのモデル群を列挙しています。OpenAIはChatGPTの既存サブスクリプションをOAuthで使えるとされ、Grokは対象となるSuperGrokサブスクリプションと管理下のOAuthを前提にします。モデル名や契約条件は更新され得るため、導入時点の対応表を一次資料で照合するべきです。
利用側の入口も多く、Web UIにはストリーミング、ターミナルパネル、共同作業表示があります。Slack、GitHub、Linearのボットや認証済みWebhookからセッションを作れるため、通知を作業へつなげやすい反面、各入口に誰が起動権を持つかを個別に定義する必要があります。
自動化と子セッションの扱い
自動化はcron、Sentryアラート、JSONPath条件付きWebhookに対応すると説明されています。一つの定期実行を最大10リポジトリへ分岐させ、それぞれにセッションとプルリクエストを作る構成です。3回連続で失敗すると自動停止し、手動実行ボタンと履歴も用意されています。無人実行ができることと、無人で安全に変更を出せることは別なので、レビューや権限の境界は組織側で置く必要があります。
エージェントはspawn-childで独自サンドボックスの子セッションを起動し、状態取得やキャンセルを行えます。深度制限とリポジトリ単位のガードレールがあるため、並列化の便利さだけでなく、子作業の数、費用、成果物の統合方法も先に決めると運用しやすくなります。
導入前に見る秘密情報と起動スクリプト
サンドボックスにはNode.js 22、Python 3.12、Bun、git、GitHub CLIなどが入り、agent-browserによるヘッドレスChromium、code-server、Webターミナル、最大10ポートの暗号化トンネルもREADMEに記載されています。秘密情報はAES-256-GCMで暗号化され、グローバル、リポジトリ、環境の単位でスコープされ、起動時に環境変数として注入されます。ここは自社の秘密情報分類と照合する場所です。
リポジトリ側の.openinspect/setup.shはイメージ構築や新規セッションで動き、start.shは非ビルドセッションの開始時に動きます。後者の失敗は厳格に扱われます。OPENINSPECT_BOOT_MODEや各タイムアウトの意味も確認し、MITライセンス、依存基盤、許可リポジトリを記録してから小さな検証環境へ入れるのが妥当です。
編集部の結論
Open-Inspectは、同じ組織の利用者が同じリポジトリ群を扱う社内環境なら検討しやすい設計です。一方、利用者ごとにリポジトリ権限を厳密に分けるマルチテナントサービスとしては、READMEが明記する前提から外れます。採用前にSSOやVPNの境界、GitHub Appの対象リポジトリ、OAuth経路、サンドボックスの秘密情報注入を実環境で確認してください。
コミュニティノート