メインコンテンツへスキップ

Documentation Index

Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt

Use this file to discover all available pages before exploring further.

概要

チーム全体の設定により、Enterprise 管理者 は組織全体での Devin CLI の使用を制御できます。
  • Devin Enterprise admins は、顧客向けの Devin ダッシュボードの Settings → Enterprise → Windsurf (app.devin.ai/org/{orgName}/settings/windsurf) でこれらの設定を管理できます。Enterprise settings にアクセスできる管理者は、セルフサービスで設定できます。
  • Windsurf Enterprise admins は、Windsurf ダッシュボードの https://windsurf.com/team/cli-settings でこれらの設定を管理できます。
これらのページで Devin CLI に適用されるのは、Devin CLI 専用の設定のみです。一般的な Windsurf チーム設定 は Windsurf に適用されるもので、Devin CLI の設定ページにも記載されていない限り、Devin CLI には適用されません。

Available の設定

モデル

ユーザーがDevin CLI経由でアクセスできるモデルを制御できます。設定できる項目は次のとおりです。
  • 特定のモデルを許可リストに追加 — ユーザーがアクセスできるモデルを、承認済みの厳選された一覧に制限します
  • すべてのモデルを許可 — ユーザーに利用可能なすべてのモデルへのアクセスを許可します
Configure をクリックして、各カテゴリのモデルアクセスを管理します。

デフォルトモデル

Devin CLI が新しいセッションで利用するチーム全体のデフォルトモデルを固定することもできます。これは、Windsurf でデフォルトモデルに使用されるものと同じ設定のため、一度設定すれば両方に適用されます。
  • チームのデフォルトが設定されていない場合、Devin CLI は組み込みのデフォルトモデルを利用します。
  • 固定したデフォルトが上記の許可されたモデルの一覧に含まれていない場合、Devin CLI は組み込みのデフォルトモデルにフォールバックします。常に許可リストが優先されます。
  • 各ユーザーはセッション中に引き続きモデルを切り替えられます。この設定で制御されるのは、新しいセッションの開始時に使われるモデルのみです。
Enterprise 管理者は、Windsurf チーム設定 ページ、Devin CLI Settings ページ、または app.devin.ai/org/{orgName}/settings/windsurf にある顧客向けの Devin Enterprise 設定ページからデフォルトモデルを設定できます。 Devin CLI エージェントが、公開インターネット上で Web 検索を実行できるようにします。なお、特定の URL を読み取るエージェントの機能には影響しません。この処理はユーザーのマシン上でローカルに実行されます。このツールは、Enterprise チームではデフォルトで無効です。

MCP サーバー

ユーザーが MCP (Model Context Protocol) ツールを利用できるかどうかを管理します。
  • オン/オフの切り替え — MCP サーバーの利用を全体として有効または無効にします
  • 許可された MCP サーバー — ユーザーが接続できる MCP サーバーを指定します。サーバーが 1 つも追加されていない場合は、デフォルトですべてのサーバーが許可されます。特定のサーバーのみにアクセスを制限するには、サーバーを追加 をクリックします。

ターミナル権限

Devin CLIの利用に関する、チームで強制適用される権限ルールを設定します。これらのルールは最も優先され、個々のユーザーのローカル設定やプロジェクト設定で上書きすることはできません。 設定をクリックして権限エディタを開きます。設定には、3つのフィールドを持つJSONオブジェクトが必要です。
{
  "deny": [
    "exec"
  ],
  "ask": [],
  "allow": [
    "Read(~/my-repository/**)"
  ]
}
  • deny — アクションを完全にブロックします (最優先)
  • ask — アクションごとに常にユーザーに承認を求めます
  • allow — 承認を求めずにアクションを自動的に許可します
権限はスコープベースまたはツールベースで設定できます。
TypeFormatExample
ファイルの読み取りRead(/path)Read(~/sensitive/**)
ファイルの書き込みWrite(/path)Write(.env*)
コマンドの実行Exec(cmd)Exec(rm), Exec(sudo)
HTTP フェッチFetch(url)Fetch(https://internal.api/*)
ツールベースツール名read, edit, exec
機密ディレクトリへのアクセスや rm -rfsudo のような危険なコマンドをブロックするなど、組織全体でアクションを禁止するには、チームで適用する deny ルールを利用してください。
権限の構文、glob パターン、設定の使用例について詳しくは、Permissions ドキュメントを参照してください。

サンドボックス強制

組織におけるサンドボックスの動作を制御します。これらの設定により、すべてのCLIセッションにOSレベルの分離が適用され、ファイルシステムへのアクセスとネットワーク通信が制限されます。

サンドボックス強制モード

組織全体で --sandbox フラグの強制レベルを設定します。
  • 任意 (デフォルト) — --sandbox を指定するかどうかはユーザーが選択します。強制はされません。
  • 必須 — すべてのユーザーに対して --sandbox フラグが強制的に有効になります。コマンドラインで指定していなくても適用されます。すべての CLI セッションは、Read/Write の権限スコープを適用する OS レベルのファイルシステム サンドボックス内で実行されます。
将来的には Strict モードが追加され、サンドボックス設定が完全に固定されて、ユーザーが変更できなくなる可能性があります。 サンドボックスがアクティブな場合:
  • 書き込み可能なパス は、付与された Write(...) 権限スコープと workspace ディレクトリから導出されます
  • 読み取り可能なパス は、付与された Read(...) スコープから導出されます (/usr/bin などのプラットフォームのデフォルトパスは常に読み取り可能です)
  • セッションの途中で付与されたスコープにより、それ以降のコマンドで利用できるサンドボックスの範囲が動的に拡張されます
サンドボックスの解決に失敗した場合 (たとえば、ユーザーのプラットフォームでサンドボックス化ツールを利用できない場合) 、CLI はサンドボックスなしで実行されるのではなく、起動を拒否します。このフェイルクローズの動作は、この Team 設定でサンドボックスが有効化された場合でも、ユーザーが --sandbox を直接指定した場合でも適用されるため、意図したセキュリティが気付かないうちに回避されることはありません。Enterprise によって強制されている場合、ユーザーには Team 管理者に連絡するよう案内するエラーが表示されます。ユーザーが自分で有効化した場合は、OS レベルの分離なしで続行するには --sandbox を付けずに実行するよう案内するエラーが表示されます。サンドボックスの解決に失敗する一般的な原因:
  • Windows: OS レベルのサンドボックス化は現在 Windows ではサポートされていません。--sandbox が指定された場合、またはサンドボックス強制が 必須 の場合、Windows 上のセッションは必ず失敗します。これには、CLI が IDE (例: Windsurf) 内で ACP サーバーとして実行される場合も含まれます。
  • Linux: サンドボックス化には bubblewrap (bwrap) と socat がインストールされている必要があります。これらがない場合、セッションはインストール手順を表示して必ず失敗します。
  • 権限スコープのエラー: 解決できない無効なパスが権限スコープに含まれている場合。
組織全体でサンドボックス強制モードを 必須 に設定する前に、対象となるすべてのマシンの準備が完了していることを確認してください。Windows を利用しているユーザーがいる場合、Windows で OS レベルのサンドボックス化がサポートされるか、ポリシーが 任意 に緩和されるまで、そのユーザーは CLI を実行できません。

ドメインフィルタリング

サンドボックスのネットワークフィルタリング用に、組織全体のドメイン許可リストと拒否リストを設定します。
  • ドメイン許可リスト — これを設定すると、サンドボックスのネットワークプロキシ経由で到達できるのは、このリストに含まれるドメインのみです。このリストが基準となり、ユーザーがローカルのsandbox configで設定した allowed_domains は完全に置き換えられます。ユーザーが追加のドメインを加えて管理者の制限を回避することはできません。
  • ドメイン拒否リスト — 常にブロックされるドメインです。Enterprise の拒否ドメインは追加式で、ユーザーのローカル denied_domains とマージされるため、結合後のリストはより制限が厳しくなります。
ドメインパターンの構文 (例: *.example.com**.example.com) については、sandbox config referenceを参照してください。 Enterprise とユーザーのドメインリストの相互作用:
ScenarioEnterprise configUser configEffective result
管理者が許可リストを設定allowed_domains: ["github.com"]allowed_domains: ["npmjs.org"]github.com のみが許可されます (Enterprise がユーザーリストを置き換えます)
管理者が拒否リストを設定denied_domains: ["evil.com"]denied_domains: ["risky.io"]evil.comrisky.io の両方がブロックされます (マージされます)
管理者の許可リストがないallowed_domains: []allowed_domains: ["github.com"]ユーザーの許可リストが利用されます
ユーザーのローカル denied_domains は保持されたまま追加式でマージされるため、Enterprise の許可リストに含まれるドメインをユーザーが拒否することもできます。これは意図された動作です。結合後の結果は常により制限が厳しくなる方向に働き、緩くなることはありません。これによってアクセス上の問題が発生する場合は、ユーザーがローカル設定から競合するエントリを削除してください。
サンドボックスの強制とチームの権限拒否ルール (例: Write(/etc)) を組み合わせることで、権限レベルと OS レベルの両方で、エージェントによる機密ディレクトリの変更を防げます。権限拒否ルールは、エージェントがそのアクションを試みること自体を防ぎ、サンドボックスは OS レベルでの第 2 の保護層を提供します。

Windsurfのコマンドパレットに「Install Devin CLI」を表示する

Devin CLI は Windsurf に同梱されています (1.9577.24 以降) が、管理者が明示的に有効にする必要があります。この設定をオンにすると、ユーザーは Windsurf のコマンドパレットから Devin CLI を直接インストールできるようになります。 有効にすると、ユーザーはコマンドパレット (macOS では Cmd+Shift+P、Windows/Linux では Ctrl+Shift+P) を開き、Install Devin CLI を実行して devin バイナリを PATH に追加できます。
この設定は Windsurf Enterprise プランと Devin Enterprise プランで利用でき、デフォルトではオフです。

参考資料

Devin CLIの設定についてさらに詳しくは、設定ドキュメントを参照してください。