エージェント活用パターン

日本語

English

日本語

English

外観

権限を構造で縛る（Bounding Permissions by Structure） ​

指示は忘れられるが、構造は忘れられない。

問題 ​

命令ファイルに「本番には触るな」と書いても、エージェントは触ることがある。「気をつけて」と念を押しても、危険な操作を実行することがある。原因は反抗ではない。命令は強制ではないからである — 公式も命令ファイルをそう位置づけている（context rather than enforced configuration、具体例節）。命令は読まれる。しかし守られる保証は無い。守らせたいことを、守られる保証の無い手段に載せている ことが、この問題の正体である。

コンテキスト ​

適用する条件:

  • 取り返しのつかない操作がある — 本番・課金・公開・削除
  • エージェントに実行権限を与える — 読むだけでなく、書く・実行する・送信する
  • 無人経路である — 人間がその場で見ていない（→ 無人経路にこそ強いゲート）

適用しないケース:

  • 読み取りしかしない作業。 縛る対象が無い
  • 縛ると仕事ができなくなるとき。 権限を絞りすぎて毎回人間が承認するなら、自動化の利益が消える。これはトレードオフであり、絞れば絞るほど良いわけではない

隣接パターンとの境界:

  • 無人経路にこそ強いゲート — 同パターンは承認・マージ経路、本パターンは実行権限。ただし接合点がある。公式は automation について、使えるツールを人間が選べると明記している（You control which tools an automation can use、具体例節）— これは無人経路における本パターンの適用そのものである
  • 機械ゲートと意味ゲートの分離 — 同パターンは出力を確かめる（事後）、本パターンはそもそもさせない（事前）。時間軸が違う
  • 計算をコードに落とす — 正面から緊張する。あちらはコードを実行させたいが、こちらは実行権限を絞りたい。解くのは、権限パターンの側で範囲を絞って許すことである（下記）
  • ルールを拘束力で階層化する — 同パターンの限界が本パターンの入口である。MUST と書いても、命令は非決定的にしか効かない

解決 ​

権限を構造で縛る2層モデル第1層は可用性であり、ツールをそもそもモデルに見せるかどうかを決める。見えなければそこで終わる。見える場合だけ第2層に進み、許可・拒否・都度確認のいずれかが適用される。拒否ルールは許可ルールより常に優先する。ツール呼び出し要求第1層 可用性モデルに見せるか--available-tools--excluded-tools見えない✕ そもそも使われない交渉の余地が無い見える第2層 許可見せた上で許すか拒否あり --deny-tool許可のみ --allow-tool指定なし（既定）拒否は許可より常に優先する同じツールに両方あっても、勝つのは拒否結果: 常に拒否 ／ 確認なしで実行 ／ 都度人間に確認

なぜ効くのか。指示と構造は、失敗の仕方が違う。指示は「読まれなかった」「解釈がずれた」「他の指示に負けた」で失敗する。構造には、そもそも失敗の経路が無い — 権限を与えていない操作は、意図がどうであれ実行されない。

したがって本パターンの主張は「構造のほうが強い」ではない。**「構造は、モデルの状態に依存しない」**である。命令の遵守はモデル・文脈・長さに左右される — 公式も非決定性を明記している（Non-deterministic behavior、具体例節）。権限は左右されない。エージェントが賢くても愚かでも、混乱していても、権限の外には出られない。信頼の問題を、信頼しなくてよい形に変換することがこのパターンの働きである。

図の要点は、2層が別物であることである。第1層（可用性）は、そもそも見せるかどうかを決める。見せていない道具は使われようがない。第2層（許可）は、見せた上で、許すか・拒むか・訊くかを決める。「使えるが許可が要る」と「そもそも存在しない」は違う — 前者には交渉の余地があり、後者には無い。評価順序も重要である。拒否は許可より常に優先する（Deny rules always take precedence over allow rules、具体例節）。

もう一つ、取り返しのつかなさとの対応がある。全部を縛るのは高くつく。縛るべきは「間違えたときに戻せないもの」に絞る。戻せる操作は事後のゲートで足りる（→ 機械ゲートと意味ゲートの分離）。構造で縛るコストは、可逆性で割り引ける。

本パターンには凍結と差分参照も含まれる。一次ソースや確定済みの成果物への書き込みを禁じるのは、独立した仕組みではなく、最小権限の一適用にすぎない。変更してよい範囲だけを書き込み可能にし、それ以外を読み取り専用にしておけば、差分は許可された範囲の外からは生まれようがない。

トレードオフ ​

利点

  • モデルの状態に依存しない。 エージェントの調子や解釈のぶれに関係なく、権限の外にある操作は起こらない
  • 取り返しのつかない操作の被害上限が決まる。 縛った範囲の外では、何が起きても戻せる

代償

  • 絞るほど仕事が止まる。 承認待ちが増え、自動化の利益が薄れる。何でも訊く運用は、自動化する意味を消す
  • 権限の設計は、やらせたいことの理解に依存する。 事前に何が要るか分からない探索的な作業では正しく絞れない — 絞りすぎて毎回止まるか、面倒になって全開にするかの二択になりやすい

GitHub Copilot での具体例 ​

Copilot は単一の製品ではない。本パターンに対応する機構は面によって違う。

Copilot CLI — 2層のツール権限 ​

出典: CLI command reference（取得日: 2026-07-16）公式。

第1層（可用性 — そもそも見せるか）:

| --available-tools=TOOL ... | Only these tools will be available to the model. For multiple tools, use a quoted, comma-separated list. … | | --excluded-tools=TOOL ... | These tools will not be available to the model. For multiple tools, use a quoted, comma-separated list. |

〔訳〕--available-tools はモデルに見せるツールをこれらだけに限定する(複数指定はカンマ区切りの引用符付きリストで行う)。--excluded-tools はモデルに見せないツールを指定する(同様の書式)。

第2層（許可 — 見せた上で許すか）:

| --allow-tool=TOOL ... | Tools the CLI has permission to use. Will not prompt for permission. For multiple tools, use a quoted, comma-separated list. … | | --deny-tool=TOOL ... | Tools the CLI does not have permission to use. Will not prompt for permission. For multiple tools, use a quoted, comma-separated list. |

〔訳〕--allow-tool は CLI が確認なしで使用してよいツールを指定する。--deny-tool は CLI が使用を許可されないツールを指定し、これも確認を求めない。いずれも複数指定はカンマ区切りの引用符付きリストで行う。

評価順序:

Deny rules always take precedence over allow rules, even when --allow-all is set.

〔訳〕拒否ルールは、--allow-all が設定されている場合でも、常に許可ルールより優先する。

混同しない

この一文はツール権限パターンの節にある。別に deniedUrls（設定キー）にも同趣旨の記述があるが、そちらは URL アクセスの話である。両者を混ぜて「Copilot は一律 deny 優先」と一般化しない。ここで書けるのは、ツール権限についての評価順序までである。

権限は Kind(argument) という構文で範囲を絞れる:

The --allow-tool and --deny-tool options accept permission patterns in the format Kind(argument). The argument is optional—omitting it matches all tools of that kind.

〔訳〕--allow-tool と --deny-tool オプションは Kind(argument) という形式の権限パターンを受け取る。引数は省略可能であり、省略するとその種類のすべてのツールにマッチする。

| read | File or directory reads | read, read(.env) | | shell | Shell command execution | shell(git push), shell(git:*), shell | | url | URL access via web-fetch or shell | url(github.com), url(https://*.api.com) | | write | File creation or modification | write, write(src/*.ts) |

〔訳〕read はファイルやディレクトリの読み取り、shell はシェルコマンドの実行、url は web-fetch やシェル経由の URL アクセス、write はファイルの作成・変更を指す種別であり、それぞれ read(.env) や shell(git:*) のような引数付きの例が示されている。

For shell rules, the :* suffix matches the command stem followed by a space, preventing partial matches. For example, shell(git:*) matches git push and git pull but does not match gitea.

〔訳〕shell ルールでは、:* 接尾辞はコマンドの語幹に続けて空白があるものにマッチし、部分一致を防ぐ。例えば shell(git:*) は git push や git pull にマッチするが、gitea にはマッチしない。

shell
# Allow all git commands except git push
copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

この一行が本パターンの核心を体現している — 「git は使ってよいが push はだめ」。指示ではなく構造で書けている。write(src/*.ts) は、「凍結と差分参照」（一次ソースと確定成果物への書き込みを禁じる）をそのまま実装したものである。書いてよい範囲を glob で絞り、それ以外を読み取り専用に留める。

github.com — 命令は非決定的にしか効かない ​

GitHub の code review カスタム命令の docs はこう明記する（出典: Using custom instructions to unlock the power of Copilot code review、取得日: 2026-07-16、公式。この引用は code review のカスタム命令についての記述であり、命令ファイル一般の目安として広げない）:

Non-deterministic behavior: Copilot may not follow every instruction perfectly every time.

〔訳〕非決定的な挙動: Copilot は毎回すべての指示を完璧に守るとは限らない。

「本番には触るな」を命令ファイルに書いても保証にならない理由が、公式の言葉でここに書かれている。だからこそ「取り返しのつかない操作」には、命令ではなく本パターンの権限が要る。

cloud agent — ネットワークとツールの制御 ​

出典: Copilot cloud agent の risks and mitigations（取得日: 2026-07-16）公式。

To mitigate this risk, GitHub restricts Copilot cloud agent's access to the internet.

〔訳〕このリスクを緩和するため、GitHub は Copilot cloud agent のインターネットへのアクセスを制限している。

公式が明記しているのはここまでである。allowlist の詳細・org ポリシー・repo 設定は未確認であり、書かない。

無人で走る automation については、ツールの選択そのものが構造として与えられている:

You control which tools an automation can use. When an automation is triggered by an event, input from untrusted users could become part of the prompt. To limit the impact of prompt injection, you choose exactly which tools an automation can use, so it can only take the actions the task requires.

〔訳〕automation が使えるツールは利用者が制御する。automation がイベントによって起動されるとき、信頼できない利用者からの入力がプロンプトの一部になりうる。プロンプトインジェクションの影響を抑えるため、automation が使えるツールを正確に選び、タスクに必要な行動しか取れないようにする。

人間が見ていない経路ほど、事前に許すツールを絞ることの価値が上がる。「無人経路にこそ強いゲート」が扱う承認・マージの構造に対し、この一文はその内側で本パターンが働いている実例である。

VS Code — 機微なファイルは承認制 ​

出典: AI が生成した編集のレビュー（取得日: 2026-07-16）公式。

To prevent inadvertent edits to sensitive files, such as workspace configuration settings or environment settings, VS Code prompts you to approve edits before they are applied.

〔訳〕ワークスペースの設定や環境設定など機微なファイルへの意図しない編集を防ぐため、VS Code は編集が適用される前に承認を求める。

json
"chat.tools.edits.autoApprove": {
  "**/*": true,
  "**/.vscode/*.json": false,
  "**/.env": false
}

自動承認を既定にしつつ、機微なファイルだけを除外する — 「全部縛る」のではなく、戻せない・見られたくないものだけを狭く縛るという本パターンの設計そのものである。

Claude Code との対比 ​

命令ファイルの位置づけは、Copilot 以外でも同じである。Claude Code の公式はこう書いている 公式（出典: code.claude.com/docs/en/memory、取得日: 2026-07-16）:

Because they're context rather than enforced configuration, how you write instructions affects how reliably Claude follows them. Specific, concise, well-structured instructions work best.

〔訳〕強制される設定ではなくコンテキストであるため、指示の書き方によって Claude がどれだけ確実に従うかが変わる。具体的で簡潔かつ構造化された指示が最もよく機能する。

命令が強制される設定ではなく、コンテキストであるという位置づけは、道具を問わない。これが「なぜ効くか」の中核であり、権限という別の層が要る理由でもある。

別名 ​

呼称出典
最小権限 / Principle of least privilege一次 — 確立したセキュリティ原則。エージェント固有の呼称ではない
権限を構造で縛る / Bounding Permissions by Structure記述 — 本カタログの記述的呼称

最小権限はエージェント以前からある原則であり、本パターンの主張自体は新しくない。新しいのは当てる先である。エージェントは自然言語の指示に従っているように見えるため、権限ではなく指示で制御しようとする誘惑が強い。しかし指示は上記のとおり「コンテキストであって設定ではない」。本パターンは、確立した原則を、この誘惑が起きやすい対象に当て直したものである。

関連 ​