> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 権限

> きめ細かな権限ルールで、エージェントに許可する操作を制御します

権限システムでは、エージェントがあなたの承認なしに実行できる操作を制御します。安全な操作は事前に承認し、危険なものはブロックし、機密性の高い操作では常に確認を求めるようにできます。

***

<div id="default-permission-behavior">
  ## デフォルトの権限の動作
</div>

Devin CLI は、機能性と安全性のバランスを取るために、ティア制の権限システムを利用します。デフォルトの動作は、現在の[モード](/ja/cli/essential-commands#modes)によって異なります。

各セルには、そのモードでそのツールが自動的に実行されるか (**Auto**、確認なし) 、承認を待つか (**Prompt**) が示されています:

| Tool type                | Example             | Normal | Accept Edits    | Bypass | Autonomous (sandbox) |
| ------------------------ | ------------------- | ------ | --------------- | ------ | -------------------- |
| 読み取り専用                   | ファイルの読み取り、grep、glob | Auto   | Auto            | Auto   | Auto                 |
| Fetch                    | HTTP リクエスト          | Prompt | Prompt          | Auto   | Auto                 |
| Bash コマンド                | シェルの実行              | Prompt | Prompt          | Auto   | Auto                 |
| `edit`/`write` によるファイル編集 | ファイルの編集/書き込み        | Prompt | Auto (ワークスペース内) | Auto   | Prompt               |

**Normal モード** (デフォルト) では、読み取り専用の操作は自動承認されますが、書き込み操作とシェルコマンドの実行には明示的な承認が必要です。アクションを承認するたびに、1 回だけ許可するか、セッション中は許可するか、またはプロジェクトに対して永続的に許可するかを選択できます。

**Accept Edits モード**では、ワークスペース内のファイル編集は自動承認されますが、シェルコマンドとワークスペース外への書き込みでは引き続き確認が表示されます。

**Bypass モード**では、すべてのツール呼び出しが確認なしで自動承認されます。

**Autonomous モード**では、OS レベルのサンドボックスによってアクセス可能な範囲が制限されるため、シェルコマンドとネットワークリクエストは自動承認されます。一方、`edit`/`write` ツールによる直接のファイル編集は、それらのツールがサンドボックスの外で動作するため、引き続き確認が表示されます。Autonomous は、[OS レベルのサンドボックス](#autonomous-mode)がアクティブな場合にのみ利用できます。

<Warning>
  Bypass モードと Autonomous モードは、組織レベルの権限を**上書きしません**。[チーム設定](/ja/cli/enterprise/team-settings) で構成された管理者適用の deny ルールおよび ask ルールは、ユーザーの権限モードに関係なく有効なままです。詳しくは [Precedence](#precedence) を参照してください。
</Warning>

<div id="autonomous-mode">
  ### Autonomous モード
</div>

Autonomous は、`--sandbox` フラグと組み合わせて使う権限モードです。概念的には、これはおおむね「現在のワークスペースで編集を受け入れる」に、任意のシェルコマンドを実行する機能を加えたもので、どちらの動作も OS レベルのサンドボックス内に制限されます。サンドボックスがアクティブな場合:

* **利用できる権限モードはこれだけです。** サンドボックスのセッションでは、Normal、Accept Edits、Bypass は表示されません。Plan モードは引き続き利用できます。
* **シェルコマンドとFetchは、確認なしで自動承認されます。** サンドボックスによって、それらが読み取り・書き込みできる範囲や、ネットワーク経由で到達できる範囲が制限されるためです。
* **`edit` および `write` ツールによるファイルの直接編集では、引き続き確認が求められます。** これらのツールはサンドボックス内ではなく CLI プロセス内で実行されるため、サンドボックスで制限できません。プロンプトで `Write(...)` スコープを付与すると、以後のシェルコマンドがその場所に書き込めるよう、サンドボックスが動的に拡張されます。
* **セッションの途中で付与されたスコープによって、以後のコマンドに対するサンドボックスの範囲が動的に拡張されます。**

```bash theme={null}
devin --sandbox --permission-mode autonomous
```

OS レベルの分離なしで制限なく実行したい場合は Bypass を利用し、ファイルシステムとネットワークアクセスに OS による制限が適用された無人実行を行いたい場合は `--sandbox` (Autonomous が選択されます) を利用してください。書き込み可能/読み取り可能なルートやドメインフィルタリングの詳細については [サンドボックス設定リファレンス](/ja/cli/reference/configuration/config-file#sandbox) を、Enterprise 向けの制御については [チーム設定 → サンドボックス強制](/ja/cli/enterprise/team-settings#sandbox-enforcement) を参照してください。

***

<div id="how-permissions-work">
  ## 権限 の仕組み
</div>

エージェントがツールを呼び出すと、権限システムは優先順位に従ってルールを確認します。

1. **Deny rules** — 最初に確認されます。一致した場合、その操作はただちにブロックされます。
2. **Ask rules** — 次に確認されます。一致した場合は、常に確認を求められます (allow ルールより優先されます) 。
3. **Allow rules** — 最後に確認されます。一致した場合、その操作は確認なしで実行されます。
4. **Default** — 一致するルールがない場合は、承認を求められます。

<Note>
  deny は ask より先に確認され、ask は allow より先に確認されるため、deny ルールが常に優先されます。同じスコープが deny ルールと ask ルールの両方に一致する場合は、deny が適用されます。
</Note>

***

<div id="configuration">
  ## 設定
</div>

設定ファイルの `permissions` セクションに権限を追加します。

<Note>
  Windows では、ユーザー設定ファイルのパスは `~/.config/devin/config.json` ではなく、`%APPDATA%\devin\config.json` (通常は `C:\Users\<you>\AppData\Roaming\devin\config.json`) です。詳しくは [Configuration File](/ja/cli/reference/configuration/config-file#file-locations) を参照してください。
</Note>

<Tabs>
  <Tab title="プロジェクト設定">
    ```json theme={null}
    // .devin/config.json
    {
      "permissions": {
        "allow": [
          "Read(src/**)",
          "Exec(npm run)"
        ],
        "deny": [
          "Exec(rm)"
        ]
      }
    }
    ```
  </Tab>

  <Tab title="ユーザー設定">
    ```json theme={null}
    // ~/.config/devin/config.json
    {
      "permissions": {
        "allow": [
          "Read(**)",
          "Exec(git)"
        ]
      }
    }
    ```
  </Tab>

  <Tab title="ローカルオーバーライド">
    ```json theme={null}
    // .devin/config.local.json
    {
      "permissions": {
        "allow": [
          "Exec(docker compose)"
        ]
      }
    }
    ```
  </Tab>
</Tabs>

***

<div id="permission-syntax">
  ## 権限の構文
</div>

権限マッチャーには、**スコープベース** (アクセス可能なパス、コマンド、URL を制御) と、**ツールベース** (利用可能なツールを制御) の 2 種類があります。

<div id="scope-based-permissions">
  ### スコープベースの権限
</div>

<AccordionGroup>
  <Accordion title="Read(glob)" icon="eye" defaultOpen>
    ファイルの読み取り権限を制御します。glob パターンはファイルパスにマッチします。

    ```json theme={null}
    "allow": [
      "Read(src/**)",           // src/ 配下のすべてのファイル
      "Read(~/.config/**)",     // ホームディレクトリの設定ファイル
      "Read(/tmp/**)"           // 一時ディレクトリ
    ]
    ```

    ディレクトリパスは、その配下のすべてのファイルに自動的にマッチします。
  </Accordion>

  <Accordion title="Write(glob)" icon="pen">
    ファイルの書き込み/編集権限を制御します。

    ```json theme={null}
    "allow": [
      "Write(src/**)",          // src/ 配下の任意の場所に書き込み可能
      "Write(tests/**)"         // テストファイルに書き込み可能
    ],
    "deny": [
      "Write(*.lock)",          // lock ファイルは変更不可
      "Write(.env*)"            // env ファイルは変更不可
    ]
    ```
  </Accordion>

  <Accordion title="Exec(prefix)" icon="terminal">
    シェルコマンドの実行権限を制御します。指定したプレフィックスで始まるコマンドにマッチします。

    ```json theme={null}
    "allow": [
      "Exec(git)",              // git、git status、git commit...
      "Exec(npm run)",          // npm run test、npm run build...
      "Exec(python)"            // python、python script.py...
    ],
    "deny": [
      "Exec(rm)",               // rm、rm -rf などをブロック
      "Exec(sudo)"              // sudo コマンドをブロック
    ]
    ```

    <Note>
      `Exec(git)` は "git"、"git status"、"git commit -m 'msg'" にはマッチしますが、"gitk" や "github-cli" にはマッチしません。プレフィックスは完全な単語として一致する必要があります。
    </Note>
  </Accordion>

  <Accordion title="Fetch(pattern)" icon="globe">
    URL パターンを使って HTTP fetch 権限を制御します。

    ```json theme={null}
    "allow": [
      "Fetch(https://api.github.com/*)",    // GitHub API
      "Fetch(https://*.example.com/*)",     // example.com のすべてのサブドメイン
      "Fetch(domain:npmjs.org)"             // npmjs.org 上の任意の URL
    ]
    ```

    URL パターンは [WHATWG URL Pattern](https://urlpattern.spec.whatwg.org/) 標準に従います。`domain:` の省略記法は、完全一致するドメイン上の任意のパスにマッチします。
  </Accordion>
</AccordionGroup>

<div id="tool-based-permissions">
  ### ツールベースの権限
</div>

ツール名で一致させることで、ツール全体を制御できます:

```json theme={null}
{
  "permissions": {
    "deny": [
      "edit",       // すべてのファイル編集をブロック
      "exec"        // すべてのコマンド実行をブロック
    ],
    "allow": [
      "read",       // すべてのファイル読み取りを許可
      "grep",       // すべての検索を許可
      "glob"        // すべてのファイル検索を許可
    ]
  }
}
```

**使用可能なツール名:** `read`, `edit`, `grep`, `glob`, `exec`

<div id="mcp-tool-permissions">
  ### MCP ツールの権限
</div>

MCP サーバー上のツールへのアクセスを制御します:

```json theme={null}
{
  "permissions": {
    "allow": [
      "mcp__github__list_issues",     // 特定のサーバー上の特定のツール
      "mcp__github__*",               // GitHubサーバー上のすべてのツール
      "mcp__*"                        // すべてのMCPツール
    ],
    "deny": [
      "mcp__github__delete_repo"      // 特定の危険なツールをブロック
    ]
  }
}
```

| パターン                | 一致対象              |
| ------------------- | ----------------- |
| `mcp__server__tool` | 特定の1つのツール         |
| `mcp__server__*`    | サーバー上のすべてのツール     |
| `mcp__*`            | あらゆる場所のすべてのMCPツール |

***

<div id="path-patterns">
  ## パスパターン
</div>

`Read()` と `Write()` では、以下の glob パターンをサポートしています。

| Pattern | Meaning                |
| ------- | ---------------------- |
| `*`     | 1 つのパスセグメント内の任意の文字     |
| `**`    | パスセグメントをまたぐ任意の文字 (再帰的) |
| `~`     | ホームディレクトリの展開           |

**使用例:**

```json theme={null}
"allow": [
  "Read(**)",                    // すべての場所のすべてのファイル
  "Read(src/**/*.ts)",           // src/ 内のすべての TypeScript ファイル
  "Write(~/projects/myapp/**)"   // 特定のプロジェクトへの書き込み
]
```

<Note>
  システム上のすべてのファイルを対象にしたい場合は、絶対パスのプレフィックス (例: `Read(/**)`) を使用してください。先頭に `/` のない `Read(**)` は現在の作業ディレクトリからの相対パスとして解決されるため、そのディレクトリ配下のファイルにしか一致せず、他の場所にある絶対パス経由のファイルには一致しません。
</Note>

***

<div id="persistence-options">
  ## 永続化オプション
</div>

セッション中にエージェントが許可を求めた場合、その選択をどのように保存するかを選べます。

| オプション              | 保存場所                                                                     | チームで共有されるか |
| ------------------ | ------------------------------------------------------------------------ | ---------- |
| 1回のみ許可             | 保存されない                                                                   | いいえ        |
| セッション中のみ許可         | メモリ内のみ                                                                   | いいえ        |
| プロジェクト全体で許可        | `.devin/config.json`                                                     | はい         |
| プロジェクト全体で許可 (ローカル) | `.devin/config.local.json`                                               | いいえ        |
| グローバルに許可           | `~/.config/devin/config.json` (`%APPDATA%\devin\config.json` on Windows) | いいえ        |

<div id="mcp-server-level-grants">
  ### MCPサーバーレベルの権限付与
</div>

特定のMCPツール (例: Figmaサーバー上の`list_issues`) の許可を求められた場合、権限プロンプトには、より広いサーバーレベルの選択肢も表示されます。

| Option                         | Effect                               |
| ------------------------------ | ------------------------------------ |
| このツールを許可する (このセッション)           | 現在のセッション中、その特定のツールへのアクセスを許可します       |
| このツールを常に許可する                   | その特定のツールへの許可を設定に保存します                |
| このサーバー上のすべてのツールを許可する (このセッション) | このセッション中、そのサーバー上のすべてのツールへのアクセスを許可します |
| このサーバー上のツールを常に許可する             | サーバー全体へのアクセス許可を設定に保存します              |

これにより、信頼できるMCPサーバーに対して、各ツールを個別に承認しなくても、まとめてすばやくアクセスを許可できます。

***

<div id="precedence">
  ## 優先順位
</div>

複数の権限ソースでルールが定義されている場合、以下の優先順位 (高い順) でマージされます。

1. 組織/チームの設定 (Enterprise の場合)
2. セッションレベルの付与 (対話的な承認)
3. プロジェクトのローカル設定 (`.devin/config.local.json`)
4. プロジェクト設定 (`.devin/config.json`)
5. ユーザー設定 (`~/.config/devin/config.json`、Windows では `%APPDATA%\devin\config.json`)

<Warning>
  組織レベルでの拒否設定は、プロジェクト設定やユーザー設定で上書きできません。これにより、Enterprise のポリシーが確実に適用されます。
</Warning>

***

<div id="examples">
  ## 使用例
</div>

<div id="minimal-development-setup">
  ### 最小限の開発構成
</div>

一般的な読み取り専用の操作は許可し、それ以外はすべて確認を求めます：

```json theme={null}
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(git log)"
    ]
  }
}
```

<div id="full-trust-for-a-project">
  ### プロジェクトを全面的に信頼する
</div>

プロジェクト内のほとんどの操作を自動承認します：

```json theme={null}
{
  "permissions": {
    "allow": [
      "Read(**)",
      "Write(src/**)",
      "Write(tests/**)",
      "Exec(npm)",
      "Exec(git)",
      "Exec(node)"
    ],
    "deny": [
      "Exec(rm -rf)",
      "Exec(sudo)",
      "Write(.env*)"
    ]
  }
}
```

<div id="locked-down-enterprise">
  ### 厳格に制限された Enterprise
</div>

安全な特定の操作のみに限定し、書き込み時は常に確認を求める:

```json theme={null}
{
  "permissions": {
    "allow": [
      "Read(src/**)",
      "Exec(git status)",
      "Exec(git diff)",
      "Exec(npm run lint)"
    ],
    "deny": [
      "Exec(rm)",
      "Exec(sudo)",
      "Write(.env*)"
    ],
    "ask": [
      "Write(**)",
      "exec"
    ]
  }
}
```

<Tip>
  この例では、`.env*` への書き込みは無条件で拒否され、それ以外の書き込みはすべて常にユーザーに確認を求めます。また、自動承認されるのは一部の読み取り専用コマンドのみです。deny は ask より先にチェックされるため、`.env*` の拒否は `Write(**)` の ask ルールよりも優先されます。
</Tip>