AI agent が作ったコードを公開する前に、PR 経路へ security gate を差し込む

最近の vibe coding は、最初の実装だけを見るとかなり速いです。

認証まわりの画面、管理 UI、画像アップロード、Webhook の受け口。以前なら半日かけていた下書きが、agent に task を渡すだけで一気に出てくる。

ただ、ここで怖いのは「AI がコードを書くこと」そのものではありません。怖いのは、動くものが早く出たせいで、review できる単位を作らないまま公開に近づくことです。

自分なら、agent が書いたコードを特別扱いしません。

人間が書いた変更と同じように PR に乗せる。そのうえで、PR 前、PR 中、公開前の 3 箇所に security gate を置きます。

まず、agent の作業を 1 PR で読める大きさにする

最初の gate は、security tool ではなく task sizing です。

agent にこういう依頼を出すと、だいたい危ないです。

ユーザー登録、ログイン、画像アップロード、管理画面、Stripe 連携まで実装して

動くものは出るかもしれません。でも、差分が大きすぎて review する気がなくなる。

自分ならこう分けます。

1. email/password login の UI と server action だけ作る
2. session cookie の設定と middleware だけ作る
3. image upload endpoint だけ作る
4. admin API の permission check だけ作る

粒度は地味ですが、PR で見られます。

AI agent の安全性は、モデルの賢さだけでは決まりません。人間が review できる差分に切れるかどうかでかなり決まります。

PR 前 gate: local diff を軽く疑う

PR を作る前に、まず local diff を見ます。

git diff --stat
git diff --name-only

ここで見るのは、コードの美しさではなく「触ってほしくない場所を触っていないか」です。

たとえば frontend の UI 修正を頼んだのに、なぜか以下が入っていたら止めます。

.env
package-lock.json
server/auth.ts
app/api/admin/*
next.config.js

もちろん正当な理由がある場合もあります。ただ、agent の変更では「ついでに直しておきました」みたいな差分が混ざりやすい。そこを PR 前に落とします。

Copilot CLI の preview 環境なら、local changes に対して /security-review をかける選択肢もあります。

/security-review

ここで期待するのは、完璧な監査ではありません。

secret が混ざっていないか。認可なしの write endpoint が増えていないか。URL fetch や file upload で SSRF / path traversal の匂いがないか。dependency を追加した理由が説明できるか。

そのくらいの粗い確認で十分です。むしろ PR 前 gate を重くしすぎると続きません。

PR 中 gate: GitHub 側の required checks に乗せる

次は PR です。

ここで大事なのは、「AI が作ったから別の review 経路にする」のではなく、普通の PR 経路に必ず乗せることです。

最低限、自分ならこのあたりを required check にします。

- lint
- typecheck
- test
- CodeQL
- secret scanning
- dependency review

GitHub 側でも、third-party coding agent が作ったコードを security validation の対象にする方向へ進んでいます。これはかなり自然な流れだと思います。

agent branch があり、commit があり、PR がある。そこに security validation と human review を差し込む。

「AI に安全性を聞く」より、「AI が作った変更を既存の安全な経路に通す」方が強いです。

AGENTS.md に security policy を書くなら短くする

AGENTS.md や repo instruction に security policy を書くのはありです。

ここで長い security essay を置くと、たぶん読まれません。agent が毎回読むなら、短く、具体的で、差分に効く内容だけにしたい。

たとえばこのくらい。

## Security review policy

- Do not commit secrets, real tokens, or production `.env` values.
- Do not add public write endpoints without auth checks.
- For file upload code, call out size limit and path traversal risk in the PR.
- For URL fetch code, call out SSRF risk in the PR.
- For HTML rendering, prefer framework escaping and avoid raw HTML unless reviewed.
- For new dependencies, explain why the package is needed in the PR description.

ポイントは「良いコードを書け」ではなく、「危ない種類の変更を見落とすな」に寄せることです。

agent は抽象的な品質目標より、具体的な禁止事項や確認項目の方が扱いやすい。

PR template に security 欄を入れる

個人開発でも、PR template は効きます。

大げさなものはいりません。

## Security checklist

- [ ] No secrets or real `.env` values are included
- [ ] New dependencies are explained
- [ ] Public write endpoints have auth checks
- [ ] Upload / URL fetch / webhook paths were manually checked
- [ ] Logs do not include tokens, prompts, or user data

この checklist があるだけで、agent が出した summary をそのまま信じにくくなります。

特に vibe coding では、PR description が妙にきれいにまとまっていることがあります。きれいな summary と安全な差分は別物です。

公開前 gate: 人間が deploy boundary を触る

最後は公開前です。

ここは人間が触ります。AI の summary ではなく、画面、network、server logs を見ます。

全部を見る必要はありません。critical path を 3 から 5 個に絞る。

たとえば小さな web app なら、このくらいです。

1. login / logout
2. file upload
3. public write action
4. external URL fetch
5. admin-only operation

見る観点も固定します。

- 認可なしで実行できないか
- client に server secret が出ていないか
- log に token や user data が出ていないか
- upload size / file type / path が制限されているか
- error message が内部情報を出しすぎていないか

ここまで来ると、もう「AI が書いたから不安」という話ではなくなります。

普通の release gate です。

GitHub Actions の例

最低限の形なら、こんな感じで始められます。

name: pr-check

on:
  pull_request:

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm run typecheck
      - run: npm test

CodeQL も入れるなら、別 workflow にして required check にします。

name: codeql

on:
  pull_request:
  push:
    branches: [main]

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
      packages: read
      actions: read
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: javascript-typescript
      - uses: github/codeql-action/analyze@v3

これで全部が安全になるわけではありません。

でも、agent が作った大きな差分を、何も通さずに main へ近づけるよりはずっといい。

自分が実際に置く gate

いま個人開発の app を agent で組むなら、自分はこの形にします。

PR 前
  - task を 1 PR で読める粒度にする
  - git diff --stat / --name-only を見る
  - local security review を一回かける
  - secrets / auth / upload / URL fetch / dependency を重点確認

PR 中
  - lint / typecheck / test を required check にする
  - CodeQL / secret scanning / dependency review を入れる
  - PR template に security checklist を置く
  - AGENTS.md には短い security policy だけを書く

公開前
  - staging で critical path を 3-5 個だけ手で触る
  - network と logs を見る
  - AI summary ではなく実際の挙動で判断する

AI agent を使うほど、review は気合いではなく経路の設計になります。

実装は速くしていい。でも、公開判断まで雑に速くしない。

自分の中では、ここが vibe coding と production shipping の境目です。

Source notes

• GitHub Changelog: Security validation for third-party coding agents
• GitHub Changelog: Dedicated security review command in Copilot CLI
• GitHub Docs: About Copilot coding agent / cloud agent
• GitHub Changelog: Copilot code review AGENTS.md support
• Claude Code Docs: Hooks