無人経路にこそ強いゲート（Strong Gates for Unattended Paths）

人が見ていない経路ほど、構造で縛る。対話の最大の安全装置は人間がその場にいることであり、それは明文化されないぶん、無人化した瞬間に静かに抜け落ちる。

問題

対話している間、危ないことが起きれば人間がすぐに気づく。気づけるからこそ、ゲートは薄くてよい。 ところが同じエージェントを無人で走らせた瞬間、この前提は消える。誰も画面を見ていない。途中で止める人がいない。そして起動条件そのものが他人の入力になりうる — issue のコメント、外部イベントのペイロード。対話時と同じ薄いゲートを無人経路に持ち込むと、最も監視が薄い経路が、最も強い権限を持つという逆転が起きる。

コンテキスト

適用する条件:

• 自動実行・スケジュール実行・イベント起動の経路
• 人間の承認より先に変更や PR が作られる無人経路
• 起動条件に他人の入力が混ざる経路（issue コメント、外部イベントのペイロード）

適用しないケース:

• 人が一手ごとに見ている対話。 ゲートを厚くしても、人間の判断を二重にするだけで摩擦が増える

隣接パターンとの境界:

• 権限を構造で縛る — 同パターンは実行権限（何を実行できるか）を扱い、本パターンは承認・マージ経路（誰が承認しマージできるか）を扱う。ただし接合点がある — 無人経路では「どのツールを使えるか」も絞り込まれる（具体例節）。同パターンの一適用が本パターンの中に現れる。
• 成果物の差分レビューと段階的採用 — 本パターンが経路の構造を扱い、同パターンは人間側の受け取り方を扱う
• 機械ゲートと意味ゲートの分離 — 同パターンはどの種類のゲート（機械／意味）に載せるかを扱い、本パターンはどの経路にゲートを厚くするかを扱う
• 失敗の制度記憶化 — 無人経路の失敗は命令では止まらない。命令は非決定的であり、見ている人間もいない。止めるのは構造である

解決

監視が薄い経路ほどゲートは強くしなければならないが、直感はしばしば逆を向く — 「対話は面倒だから薄いゲートでよく、無人は自動化なのだから自由に動かせるはず」。しかし監視が薄いほど、被害を止める手立ては構造しか残っていない。

なぜ効くのか。対話における最大の安全装置は、人間がその場にいることである。これは明文化されない — 「対話の安全性は人間の目に依存している」と書いた仕様書は無い。

明文化されていないものは、無人化するときに外れたことに誰も気づかない。無人経路の設計とは、この暗黙の装置が抜けた穴を、明示的な構造で埋める作業である。

もう一つ、無人経路には対話に無い危険が加わる。起動条件が他人の入力になる。 イベントで起動する経路では、issue やコメントの中身がプロンプトの一部になりうる — つまり攻撃者が入力を書ける。

対話ではこれが起きない。入力を書くのは自分だからである。したがって「対話で安全だったから無人でも安全」は成立しない。危険の量が同じまま監視だけ減るのではなく、危険の種類が増えている。

ゲートの種類は上の図のように層になる — 誰が起動できるか、どこに書けるか、何を実行できるか、誰が承認できるか、誰がマージできるか。層を一つ増やすたびに、被害の上限がもう一段締まる。

構造が効くのは、指示は忘れられるが構造は忘れられないからである。「危ないことをするな」は命令であり、非決定的にしか効かない。「このブランチにしか push できない」は構造であり、守るかどうかの問題ではない。

トレードオフ

利点

• 監視が無い経路でも、被害の上限が構造で決まる。 「守るはずだった」という期待ではなく、そもそも越えられない境界として効く。
• 人間の注意力に依存しない。 対話の安全装置（その場にいること）が抜けても、構造がその代わりを務める。

代償

• 摩擦が増える。 承認待ちが発生し、workflow は自動では走らない。無人化の目的は自動化なのに、ゲートはその自動化を止める。この緊張は消えない。
• ゲートを緩める設定が用意されていることが多く、緩めた瞬間に前提が崩れる。 公式も「既定は無効だが、有効化できる」という形で緩和の余地を残している（公式、出典は具体例節）。

GitHub Copilot での具体例

Copilot は単一の製品ではない。本パターンの対応物は主に cloud agent にある。以下はすべて cloud agent の話であり、VS Code や Copilot CLI には広げない。

三分類 — 製品の既定・リポジトリ設定由来・既定だが変更可能

出典: Copilot cloud agent のリスクと緩和策（取得日: 2026-07-16）。原文は3種類の由来を書き分けている。「Copilot は安全である」と一括りにしない — このページのタイトル自体が "risks and mitigations" である。

製品の既定（変更できない）公式:

• Limits who can trigger the agent. Only users with write access to the repository can trigger Copilot cloud agent to work. Comments from users without write access are never presented to the agent.
• Limits the branch the agent can push to. Copilot cloud agent only has the ability to push to a single branch. ... In other cases, a new copilot/ branch is created for Copilot, and the agent can only push to that branch. ...
• Limits the agent's credentials. Copilot cloud agent can only perform simple push operations. It cannot directly run git push or other Git commands.
• Requires human review before merging. Draft pull requests created by Copilot cloud agent must be reviewed and merged by a human. Copilot cloud agent cannot mark its pull requests as "Ready for review" and cannot approve or merge a pull request.
• Prevents the user who asked Copilot cloud agent to create a pull request from approving it. This maintains the expected controls in the "Required approvals" rule and branch protection.

〔訳〕起動できる人を制限する — リポジトリへの書き込み権限を持つユーザーのみが Copilot cloud agent を起動でき、書き込み権限のないユーザーのコメントはエージェントに提示されない。push できるブランチを制限する — Copilot cloud agent は単一のブランチにしか push できず、多くの場合 copilot/ ブランチが新規作成され、エージェントはそこにのみ push できる。エージェントの資格情報を制限する — 単純な push 操作のみ実行でき、git push などの Git コマンドを直接実行できない。マージ前の人間によるレビューを必須にする — Copilot cloud agent が作成したドラフト pull request は人間がレビューしマージしなければならず、エージェント自身は "Ready for review" にできず、承認もマージもできない。pull request を依頼したユーザーが承認できないようにする — これにより「必須承認」ルールとブランチ保護の期待される制御が維持される。

リポジトリ設定由来（上乗せされる）公式:

The agent is also subject to any branch protections and required checks for the working repository.

〔訳〕エージェントも、作業対象リポジトリのブランチ保護や必須チェックの対象となる。

既定だが変更可能（緩められる）公式:

By default, workflows are not triggered until Copilot cloud agent's code is reviewed and a user with write access to the repository clicks the Approve and run workflows button. Optionally, you can configure Copilot to allow workflows to run automatically.

〔訳〕既定では、Copilot cloud agent のコードがレビューされ、リポジトリへの書き込み権限を持つユーザーが Approve and run workflows ボタンをクリックするまで workflow は起動しない。ワークフローを自動実行させるよう Copilot を設定することも任意で可能である。

上の各行を、解決節の図の層に当てはめると次のようになる。

層	原文の該当箇所
起動できる人	Only users with write access ... can trigger
書ける場所	only ... push to a single branch（copilot/）
実行できる手段	cannot directly run git push or other Git commands
承認できる人	cannot mark ... "Ready for review" ／ user who asked ... from approving
マージできる人	must be reviewed and merged by a human

Automations — 最も無人な経路

同じ出典の Automations 節は、人がタスクごとに起動しない経路について緩和策を並べている。ここが本パターンの主戦場である 公式:

• Work is attributed to the person who created the automation. Pull requests opened and code pushed by an automation are attributed to the user who created the automation. As when that user creates a pull request themselves, they can't approve it, which preserves the expected "Required approvals" controls.
• 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.
• Events from untrusted users are ignored by default. Automations ignore events triggered by users without write access to the repository by default, with a setting to opt in.
• Workflows still require human approval. An issue or pull request opened by an automation could trigger another automation. ... GitHub Actions workflows don't run on a pull request until a user with write access approves them, which prevents workflows from running automatically as part of such a chain.

〔訳〕作業は automation を作成した人に帰属する — automation が開いた pull request や push したコードは、その automation を作成したユーザーに帰属する。そのユーザー自身が pull request を作成した場合と同様に本人はそれを承認できず、「必須承認」の制御が維持される。automation が使えるツールを制御できる — イベントで起動される automation では、信頼できないユーザーからの入力がプロンプトの一部になりうる。プロンプトインジェクションの影響を抑えるため、automation が使えるツールを正確に選び、タスクに必要な操作しか取れないようにする。信頼できないユーザーからのイベントは既定で無視される — リポジトリへの書き込み権限を持たないユーザーが起こしたイベントは既定で無視され、オプトインの設定がある。ワークフローには依然として人間の承認が必要である — automation が開いた issue や pull request が別の automation を起動しうるが、GitHub Actions のワークフローは書き込み権限を持つユーザーが承認するまで pull request 上で実行されず、そうした連鎖の中でワークフローが自動的に実行されることを防ぐ。

「You control which tools an automation can use」〔訳: automation が使えるツールを制御できる〕は、権限を構造で縛る（実行権限の絞り込み）が本パターンの内側に現れている箇所である。無人経路ほど、実行できる手段そのものを狭める。「Workflows still require human approval」〔訳: ワークフローには依然として人間の承認が必要である〕は連鎖を止める設計でもある — automation が開いた PR が別の automation を起動しうるからである。無人経路は連鎖しうるという論点は、対話には無い。

プロンプトインジェクションへの緩和策も明記されている 公式:

To mitigate this risk, GitHub filters hidden characters before passing user input to Copilot cloud agent: For example, text entered as an HTML comment in an issue or pull request comment is not passed to Copilot cloud agent.

〔訳〕このリスクを緩和するため、GitHub はユーザー入力を Copilot cloud agent に渡す前に隠し文字をフィルタリングする。例えば issue や pull request のコメントに HTML コメントとして入力されたテキストは Copilot cloud agent に渡されない。

ゲートではないが、無人経路の設計要素として監査可能性も明記されている 公式:

Copilot cloud agent's commits are signed, so they appear as "Verified" on GitHub. This provides confidence that the commits were made by Copilot cloud agent and have not been altered.

〔訳〕Copilot cloud agent のコミットは署名されており、GitHub 上で "Verified" と表示される。これにより、そのコミットが Copilot cloud agent によって作られ、改ざんされていないという確信が得られる。

レビュー時の注意 — .github/workflows/

出典: Reviewing Copilot's output（取得日: 2026-07-16）公式:

GitHub Actions workflows can be privileged and have access to sensitive secrets. Inspect the proposed changes in the pull request and ensure that you are comfortable running your workflows on the pull request branch. You should be especially alert to any proposed changes in the .github/workflows/ directory that affect workflow files.

〔訳〕GitHub Actions のワークフローは特権を持つ場合があり、機密情報にアクセスできる場合がある。pull request 内の提案された変更を確認し、その pull request ブランチでワークフローを実行しても問題ないことを確かめること。特に .github/workflows/ ディレクトリ内でワークフローファイルに影響する変更提案には注意を払うべきである。

マージできる人の層に立つ人間へ向けた注意であり、無人経路の出力が次に自動で実行される workflow を含みうることへの警戒である。同ページは差し戻しの手段も書いている 公式:

To request changes from Copilot on its pull request, mention @copilot in a comment, or push commits directly to the branch.

〔訳〕Copilot にその pull request への変更を依頼するには、コメントで @copilot にメンションするか、ブランチへ直接コミットを push する。

別名

呼称	出典
無人経路にこそ強いゲート / Strong Gates for Unattended Paths	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い

個々のゲートには確立した名前がある — branch protection、Required approvals、Approve and run workflows ボタン（いずれも出典は具体例節）。名前が無いのは、人の目の量に応じてゲートの強さを変えるという設計原則そのものである。ただし製品はこの原則を既定として実装している — 上の三分類がその実例である。原則に名前は無いが、原則の実装には名前がある。

関連

• 機械ゲートと意味ゲートの分離 — 同ページは cloud agent の同じ出典（CodeQL・Advisory Database・secret scanning・Copilot code review という second opinion）から「どの種類のゲートに載せるか」を引いている。本パターンは同じ出典から「経路の構造」（誰が起動でき、どこへ push でき、誰がマージできるか）の側を引く。引用が重なるのは構わない — 役割が違う
• 失敗の制度記憶化 — 無人経路で起きる失敗は命令では止まらない。止めるのは構造である
• 権限を構造で縛る — 実行権限が同パターン、承認・マージ経路が本パターン。「どのツールを使えるか」は無人経路のゲートの内側に現れる接合点である（具体例節）
• 成果物の差分レビューと段階的採用 — 経路の構造が本パターン、人間側の受け取り方が同パターン
• まず次に読むなら 権限を構造で縛る — 無人経路のゲートを、権限の構造で実装する番である